Let's not pretend we will handle out-of-memory errors correctly, and really,
it's not something we really need to be worried about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Or it leads to interesting errors when adding fields to the table
of supported devices.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
etekcity suppports macros already, the other two don't. hidpp10 doesn't
support any write stuff but let's claim we do anyway.
The driver hook for this isn't ideal, read_button is called during init but
we should set all this up during probe and then use read_button exclusively to
update the button, not set the capabilities as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we goto err early then both dev and drv_data will contain
garbage values. We free one and dereference the other. Let's
null them and add proper checks.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
It is a common pattern to have:
ratbag_resolution_init(...)
profile->resolution.modes[i].xxx = yyy;
ratbag_resolution_set_cap(&profile->resolution.modes[i], zzz)
So instead of dealing with the internal fields of profile/resolution/modes,
just return the resolution that has been initialized.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Currently only the hooks for x/y resolution, the rest is unimplemented. Also
the etekcity driver needs an update here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Long-term we should have probe() and read_profile(), the latter of which
should read each profile and fill in _all_ information.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The devices we're dealing with all have multiple DPIs to configure. This API
will replace the current ratbag_profile_set_resolution_dpi() and friends.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel overwrites the device ID with the correct one for our device, so we
can just use 0x00 for all devices and skip the search for the unifying
receiver hidraw device.
Since we're not talking to the receiver anymore, we can/have to drop the
pairing information queries and the related info. Since we weren't using this
anyway it's not a big loss.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
One giant commit, but I didn't know how to split this up easier. The problem
is a misunderstanding in what the button type is and the code that built on
that misunderstanding, requiring a lot of interdependent parts to be updated
at once.
The button _type_ is the physical description of the button.
The button _action type_ is what will happen when you hit the buttons.
The type is read-only, since we're not dealing with mr potato head here.
The action is adjustible and we now support buttons, keys and special
in-hardware actions (e.g. dpi changes). A few FIXMEs still in place, e.g. we
don't handle modifiers with keys.
For buttons we just take numerical button numbers. i.e. we can map a button to
button 4, which will result in BTN_SIDE, and eventually logical button 8 in X.
For keys we take KEY_FOO, since eventually we want this to come out as that
(could do this for button as well I guess). Modifiers are currently ignored.
For special actions we have a enum of actions we support.
The button type enum is thus reduced a lot, and everything needs to be
switched.
This breaks ratbag-command change-button, will be fixed later since it's
misdesigned as it is anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't know the HID++ 1.0 request to check for the number of buttons or
profiles, this is the next-best thing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Missing return statement caused everything to be freed again. And the device
we initialized was discarded too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we have a separate HID++ 1.0 driver, we can restore this. Except the
fake button mapping.
This reverts commit 874fc3386f.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
