the logical and physical bits were inverted:
- logical is the action of the button
- physical corresponds to the actual button on the mouse (so the 'type')
- there is a duplicate from driver-etekcity to match 2 actions, this should
be factorized in a helper somewhere in a later commit
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
Not that we can configure much, but 0x1b00 sends 5 buttons, which is
the reality, so trying to include it too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
As seen on the T650.
Reusing most of 0x1b04 here, except this one only gives us control id, task id
and flags.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the button is not redirected, we need to rely on the control_id,
not the task_id to get the logical action of the button.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Problem: when a button is diverted, it stops sending its original button,
which is good, but then reports only on the HID++ long report collection.
That is a little bit embarrassing.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
And remove the spurious comments that have been introduced in
f759cbdcef ("drivers: do not declare defines that are used only once").
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This driver is really a driver for HID++ 2.0 devices, not just for devices on
the unifying receiver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
