Once we have the profile, we can call set_active and be done with it. No need
to check if another profile is currently active.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Except for "list", all commands need a device argument. Open it ahead of time
to reduce the boilerplate in each function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only stubs, and the usage() output isn't correct anymore. But we need to fix
this anyway, the combination of arguments will be too complex to handle them
in such a simple approach.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Doesn't do much, but it reduces some of the argc checking in the callers,
especially since we always expect the device as last argument
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This driver is basically a duplicate of the Etekcity.
After the copy-paste, I renamed all the the "etekcity"
by "roccat" and then rev-engineered the various constants.
Still a WIP, but it is getting usable.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The doctext needs fixes and the API might not be final.
This however works and allow to read the macro.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
It felt weird reading:
Profile 2
Resolutions:
3: 1000dpi @ 500Hz (active)
3: 1600dpi @ 500Hz
3: 2400dpi @ 500Hz
3: 3200dpi @ 500Hz
3: 4000dpi @ 500Hz
3: 8000dpi @ 500Hz
We could index the profiles to 1 too, but that would introduce slightly
more code change.
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>
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>
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>
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>
