The button mapping of the hid++ 2.0 devices is close to the one from
HID++ 1.0, but not entirely (1.0 have a size of 3 while and 2.0 a size
of 4).
The parsing was not clean, so reuse a the same logic than hidpp10.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Still missing the consumer control HID keys, but the rest works (minus
the modifier keys).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Not completely full features, but works to set the DPI, report rate and
buttons assignments (no macros yet).
The current code reads first the current values, changes that needs to be
changed and writes back the data. Long term, we want to build the data
directly from the profiles and just write them.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
profiles_list is not used anymore in hidpp20_onboard_profiles_get_current_profile
let's remove it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It looks like we can not use a section > 0xff and that the first
parameter corresponds to the type of the available memory (rom or flash).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We need hidpp20 to handle the list of available features. So we need to be
sure in hidpp20 that we are talking to a hidpp20 device.
Move the version retrieval in hidpp20 where it makes sense.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This struct will be used to store the table features/index and probably
others. It also allows a single entry point to set the device index.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This patch adds nothing but some debug outputs and prepares the code
to support the recent gaming mice from Logitech.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
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>
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>
The Logitech devices talk HID++, and we need a lib to handle that.
The first implemented command is the get protocol version which allows
to know if the device is using hid++ 1.0 or 2.0.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
