ratbag_profile_init_buttons() already loops over the given number of
buttons.
Remove the extra for loop and save some CPU (and possibly USB depending on
the driver) cycles.
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>
If action is NULL, that's a problem.
If etekcity_button_action_to_raw() returns 0, we should not try to write
0x00 in the profile. The proper command for "none" is 0x06. 0x00 is thus
an error.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This sets a button to RATBAG_BUTTON_ACTION_TYPE_NONE when we want
to disable a button completely.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The buttons are given as plain numbers, not sure if we should
use BTN_LEFT, BTN_RIGHT, etc instead.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Now that the profiles and buttons have to be created once by the probe()
function, we need to clean them up when the device is unref-ed.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This adds two button types: pinkie and pinkie2 when there are buttons
on the right side of the mouse.
OK, I could have called them left-handed-thumb.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
this index is the position of the button in the report, so it's misleading
to keep it as "index". The actual index is the button->index.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Found on the Logitech MX Master. Most of other Logitech device with
physical ratchet disable capability do not show this button to the host
however.
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>
The drivers are responsible for initializing the buttons during probe(), then
we just return the one we found
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make the driver responsible for creating them on startup, then just return the
one we already have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is something better handled by mapping the various button types into a
specific string on the client-side.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
HID++ 1.0 doesn't have an index of functions available, so we pretty much
have to bang every request against the device, full of hope and optimism.
Reality demands that some of them fail and we handle that, but we don't need
to worry the user by screaming errors.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The OS X tool for Logitech's gaming mouse did not allow button-profiles on the
G500s, but DPI modes could be configured. This is an issue with the software,
not the device itself since the device supports muliple profiles. So the
original assumption that there are devices that have profiles for DPIs but not
buttons is likely wrong, the devices we looked at so far all have profiles
with a set of DPI modes in it, one of which is currently active.
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>
and relocate the raw value 0 of RATBAG_BUTTON_TYPE_NONE to be below 0x06.
The windows application sets 0x06 when disabling a button.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
Profiles are... interesting
https://github.com/cvuchener/g500/blob/master/doc/profile.md is pretty
detailed on the information, but there's some oddities.
The profile configured on my mouse is on page 5, not sure if that's the OS X
logitech tool though (which doesn't do profile configuration btw). Pages 3 and
3 are valid too, the rest looks to be garbage.
There's probably some magic string to detect a profile (cvuchener says maybe
FF 00 00 80), so more profiles may be lying around elsewhere in memory...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
