On the M705 I frequently get usb timeouts here if the device has
not been active for a while. Retrying after 10 ms seems to reliably
fix the timeout problem.
We could have just added the 10 ms sleep directly but it does not
seem to be neccesary on wired devices so I chose not to. Setting the
ret value to a face positive number and looping would also work but
we risk an endless loop. In the end I just went for a single retry
as that fixed the problem for me.
When writing a button, the given button should also be stored in the
memory of the device.
Amend the documentation
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>
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 caused a problem since the hidpp10_device would keep a ref to
the ratbag_device - and the hidpp10_device would only get destroyed
when the ratbag_device got a ref count 0.
mechanical patch
the hidraw_fd should only be used in libratbag_hidraw, so better having
it in its own struct so we can extend the hidraw elements without touching
ratbag_device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
# Conflicts:
# src/libratbag-hidraw.c
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 G303 is a wired device and we need to talk to it with 0xff (OK a
#define would be good). This was not a problem for all of the unifying
devices given that the kernel overwrites the device_id for us, but the
corded devices are a different kind, and this one rejects device id != ff.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Don't use a default here, let the compiler tell us when we're not handling a
value expclicitly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code was checking if the previous action assigned to a button
was a macro, not that the action we are assigning will be a macro.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.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>
