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>
given that we create all the buttons and profiles during probe(), there
is no need to re-probe for it every time we access it.
Right now, this works because only ratbag-command uses the library and
is a one shot program.
In the future, we should also read the events to detect changes in the
configuration if the user can use physical buttons to change the profile,
dpi or something else.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We need to store the profile in each ratbag_resolution or we will not be
able to get back to the driver.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
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>
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>
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>
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>
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>
Note that this doesn't do anything yet, it's stubbed out everywhere except for
the button mapping bit where we already had some testing code from uLogitech.
This also adds the ID for the m570 trackball - a device I have available here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Now that we are actually using a verbose option, it does not make sense
to output the debug messages by default.
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>
