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>
When using uhid devices, we might want to check for siblings too. This is
a corner case so that's why it might not work in 100% of the cases.
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>
We might need to check against them too, so parse them and store them.
It is a little bit tricky when there is no report ID. In this case, assume
that the Collection(Application) is a match.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We will be interested in the type of reports, so prepare the storage
by using an external struct to store the reports.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
ratbag_open_hidraw is a special case of ratbag_find_hidraw() when
we do not check for the parent and we do not have a match.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
When using the same context, we do not want to open twice the same
hidraw node if two input node match it.
Store the sysname in the ratbag_device so we can check if it has been
opened previously.
Note that ratbag-command list still shows all input node as working
because we just close them as soon as we opened them.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If we want to remove the duplicate nodes opened when using
ratbag_find_hidraw(), we need to somehow keep track of all opened
ratbag_device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Some mice have a separate hid interface for configuring the advanced
features. It occurs that this is a common enough use case to be handled
directly by libratbag-hidraw instead of having a per-device quirk.
The idea is to allow opening the sibling hidraw devices during .probe()
and to give a matching callback. If the callback succeeds, then the
hidraw node will be used.
With this, one device might be opened several times, this has to be fixed
in a separate commit.
Fixes issue #19
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We want to be able to find sibling hidraw nodes. For that, we need to
open and test several different hidraw nodes. Makes the opening of a
specific hidraw node in its own function.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We were retrieving the hidraw information but did not use them.
Now the debug output "foo is device 'bar'" is only shown when there is
a match.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
libratbag.c does not need to initialize anything hidraw related, so
move out everything to libratbag-hidraw.c.
That means that calling ratbag_close_hidraw() is not a requirement
whithin the drivers to exit properly.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We are touching hidraw internals here, better having the function in
libratbag-hidraw.c.
No functional changes.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Command 0xA2 (Read Sector) takes only a one byte argument for the offset
(entry in the documentation).
Clean up the code and return an error if the page (sector in the doc)
is invalid (to avoid querying the device which would output an
ERR_INVALID_VALUE).
Fixes#15
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>
Might not be the best solution for hidpp10, because it just removes the
duplicates, but this way all of the other drivers can benefit from the
raw debug parameter.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
For supported devices this can get and set the led colors in RGB.
This patch just adds the support in the lib. Later patches will
add it to the driver and expose it in libratbag.
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>
