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>
This is the physical description of the button, so there's a distinct
difference between the two, even when the logical action is the same.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move the struct declarations together (and move ratbag_device to the ratbag
device page), have the defgroup tags at the top of the file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
And the same for set_active_profile -> set_active. This API is more reliable,
the previous incarnation required the client to compare pointer values.
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 mouse supports profiles and we can read them already, it's the mac
software that appears crippled here. And each profile has up to 5 dpi modes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
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>
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>
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>
This might not be part of the final API, but it is rather convenient
to use right now.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Naming scheme is now:
* ratbag - the context
* ratbag_device - the device
* ratbag_profile
* ratbag_button
...
Only leftovers of "libratbag" are the header file name, #defines that are
exported through that header file and anything that has to do with the actual
library iself (e.g. the symbol export file).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Same as libinput. Since we need to open device files we need something that's
authorized to open them. So we punt that to the caller.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't need the evdev fd, it's more flexible to start with a udev device.
This changes ratbag-command to take a /sys path as well, but for not it'll
do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
