We don't have mice that can do report rates per resolutions, so let's not
commit to that.
This is a DBus API break but also a break in ratbagd, piper will need to
update to fetch the rate/rates from the profile object now.
It's a ratbagctl break as well, ratbagctl info changes slightly and the
resolution is not argument anymore for the rate.
Fixes#645
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have a profiles/resolution/button/led, we can write to it. That is the
default assumption and where we don't have write-access to those, we should
simply not expose them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turns out this driver never got updated for the 'new' DPI list provided by
libratbag and thus broke with bacdab2596 when we
enforced that DPI list.
Set a fixed DPI list based on the hardcoded values we use elsewhere in this
driver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
action->macro is supposed to be allocated once and stay for the
entire life of the button. However, it was outrageously overwritten
when setting the action. Take some actions and keep the macro action
around.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Previously, probe() would call ratbag_init_profiles() which in turn would call
the various function pointers in the driver to fill in profiles, buttons and
leds (the latter while filling in profiles). This made the probe() function
harder to understand than necessary and unreliable because it wasn't always
clear which bits were already set up while some driver function was called and
which ones weren't yet.
This patch switches to a flat probe(). The driver still needs to call
ratbag_init_profiles(), libratbag sets up everything (to default values). Then
the driver can fill in the rest as it wants.
This patch still makes use of the current infrastructure, the drivers
just call the read_profile and read_button functions manually now.
Fixes#370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resolutions were still stored in an array over a linked list like the
buttons/leds/profiles and initializing them from a driver was different than
buttons or leds. This brings the resolutions in line with the buttons and
leds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Any specific capability like 'switchable resolution' requires the basic
'resolution' capabilty to be set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we don't change count, the value of count < MAX_RETRY is always true.
Coverity is a champ, isn't it?
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No reason for the drivers to have their own printf each, just return the
negative errno and let the common code print it.
This now also means that we only return -ENODEV on something that's not really
an error, for anything else we print the strerror.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous API was inconsistent and different to the rest of libratbag's
API. Replace with one where a macro is a separate struct, can be initialized
and then written to the device with a set_macro() call. The device copies the
contents, the macro is otherwise unmodified and can be re-used by the client
if need be.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Most of the capabilities can be inferred from
ratbag_device_init_profiles():
- if a device has more than one profile, we should be able to switch
between its profiles
- likewise, more than one profile means that the buttons can be remapped
- more than one resolution means that we can change the resolution.
We need to add a stub in driver-test for .set_active_profile() now that
RATBAG_DEVICE_CAP_SWITCHABLE_PROFILES is correctly set.
We manually add the macro capability for all drivers that present it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We were limited to MAX_RESOLUTIONS (10). Also, this allows to know
during ratbag_device_init_profiles() if the device supports
switchable resolutions.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Etekcity and Roccat are using raw HID code to send the macros. The Logitech
hid++ 2.0 are too so let's centralize the code in hidraw and simplify
the code per-driver.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This adds udev rules/hwdb that sets RATBAG_DRIVER and RATBAG_SVG
properties to the event devices. We then use this property to select
the correct driver instead of checking the hardcoded list in the
drivers. Having this in a hwdb makes it easier for users to test
if drivers match their mouse with a system installed libratbag.
Each driver now has an "id" which is used to match the driver set
in RATBAG_DRIVER. A SVG can optionally be set as well.
All entries in the hwdb are currently without a name as that
information was not available in the hardcoded lists.
Note that this patch breaks the test-driver.
This reverts commit d5a20efd8b.
The API is horrible. Better having 2 additional functions to get
the usage and usage pageof the report.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Add a match against the usage page and the usage.
If we are not interested in this new match, we can just use 0.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the time is not given in the macro, the device still accepts it and
works properly by setting 10 ms of delay after a key press and 50 ms
between the keys.
Problem is: without this, the RATBAG_MACRO_EVENT_WAIT is not set during
parsing, so we end up having a RATBAG_MACRO_EVENT_NONE between 2 key
events, and the library ends up truncating the macro after the first
RATBAG_MACRO_EVENT_NONE.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If there is any problem while retrieving a macro, the first element in
the report might not match. In such cases, abort.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
When the macro is not on profile 0, we need to set the mouse in the
correct mode first.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
When waiting for a status, the mouse sometimes answers 0x02, which seems
to be EINVAL (though it can be an ACK too). Treat this answer so we do
not end up in some infinite loops.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
we should not require to actually write the profile to actually write the
button in the memory of the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The device can tell whether it is ready or not, so better poll for it
instead of waiting 100ms and hoping for the best.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
There is a slight difference with etekcity:
- there is no need to first set the config macro element we are about to
send (the information are already in the macro report)
- we need to be sure the mouse processed the macro and is ready to handle
a new command. Thus the introduction of roccat_is_ready()
We should see if the etekcity does not require such check too (IIRC it did,
but the timeout were sufficient).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
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>
