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>
The current code has the profile ref the device, but the device has no back-ref to
the profile. The following code will free the profile from underneath the
client, despite the caller still having a valid ref:
p = ratbag_device_get_profile_by_index(device, 0);
ratbag_profile_ref(p);
ratbag_device_unref(device);
Fix this by not using refs internally. After probe, the device is static
anyway, so the various refs internally aren't needed. Instead, we also ref/unref
the parent struct whenever we ref/unref a struct. Thus, whenevever the device
refcount reaches zero, we know the caller has no ref active.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
