Mice behind an ASUS Omni receiver all enumerate with the same usb id
(0b05:1ace), so the regular bus:vid:pid DeviceMatch cannot tell models
apart. Identify the model during probe instead:
- asus-rog-omni-receiver.device is a minimal bootstrap file that only
declares Quirks=OMNI_RECEIVER, so the asus driver gets probed on the
receiver's hidraw nodes
- the probe queries the serial number signature (03 12 12 02) and
matches its prefix against the OmniSignature field of the .device
files, then re-resolves the device data for the identified usb id
- an unknown signature fails the probe with -ENODEV, which also drops
the receiver's keyboard and media control nodes
The Strix Impact III family answers with data two bytes earlier than the
original protocol (code plus params echo instead of code plus pad), so
two quirks cover the new layouts:
- LED_V2: per-zone LED responses with data at offset 4, brightness in
0-100
- SETTINGS_V2: settings and DPI responses with data at offset 4,
rate/debounce/snapping as single bytes
Also write DPI values with two bytes so presets above 12850 dpi work.
Verified on a ROG Strix Impact III Wireless: identification on hidraw4,
all 5 profiles with 8 buttons, 1 LED and DPI presets 400/800/1600/3200,
report rate 1000 Hz, debounce 12 ms, LED brightness 127 (50%). Writes
round-trip and survive a ratbagd restart.
NOTE: this will fail tests as of this commit, as the code is not
formatted yet.
We didn't explicitly specify a minimum Python version before that, so I
used v3.7 here, because it's the minimal version Ruff - a Python linter
I will add in the next commit - supports.
This removes the need of listing every device in meson.build which is a
common enough mistake for new contributors.
And move the validation tests over to test/ so we don't have to list
them in the exclude_files of the install_subdir() command.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a leftover from libratbag-as-a-library and obsolete now that ratbagd
is our only product. Our buildtest now is simply: "does ratbagd build?" and we
certainly shouldn't require a C++ compiler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Previously, we could get a min/max value but there was no guarantee that it
any value in between would actually work on the device. Some devices have a
discrete number of resolutions (e.g. 500, 1000, 2000, 2500), most others have
at least a minimum step size (so 1234 isn't a valid dpi value).
Change the min/max to a discrete list of which resolutions are supported. This
allows a UI to adjust its interface dynamically - e.g. a combobox if there are
only 3 resolutions or a slider if there are a million of them.
This is a DBus API break
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A driver is supposed to know what type an LED is, unknown doesn't help anyone
here. So replace this with a private #define and abort when a driver doesn't
set the type. This also adds a requirement that any driver initializing a LED
must have the read_led() function, otherwise we can't fill it in correctly.
And bump the enum up by one, the first valid value should start at 1 (or some
other non-boolean value).
Related #365Fixes#364
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's a fixed value so it's much easier to set this in the test binaries rather
than requiring the user to set this in the env before running a test manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
