currently the active profile index is fetched for each profile,
this adds unnecessary overhead.
change the behavior to fetch the active profile only once during the driver data initialization.
libratbag has a quite communication-intensive setup routine. This patch
uses short reports when possible. Using short reports will speed up the
setup process and have a lower power consumption, which is relevant for
wireless devices.
We now check the report descriptor for the supported report IDs and
adjust the report type used based on the device capabilities. Because of
that, this patch should work without any issues as the report type will
get overwritten if it not supported.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
New devices define a profile field in the button configuration. This
allows us to map a button to set the target profile as active. Even
though we don't support configuring this right now, some devices, such
as the G915/G815, come pre-configured with this action on th M-Keys.
This patch makes us able to read and write those settings, this way they
don't get lost when we write a profile to the device.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
TBH I don't know why I wrote the original code in the first place, it
clearly doesn't follow the spec.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
currently if any use profile is not valid we fallback to the firmware
profiles. this is quite annoying because the user might have only one
valid profile. this patch will keep valid profiles and only fallback to
firmware profiles on a profile by profile basis.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
when we read the memory from the device we already align the offset so
that it matches the end of the sector. for ex, for a 255 sector size the
offset will be set to 255-16.
when we copy the memory (using memcpy) we just copy the bytes that will
finish filling the buffer, ignoring that the offset was aligned. we need
to copy the full 16 bytes, otherwise it will fail when sector_size does
not align with 16.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Add HIDPP_PAGE_RESET, HIDPP_PAGE_DEVICE_NAME, and
HIDPP_PAGE_WIRELESS_DEVICE_STATUS. These feature names are found in the
"features.xml" of an LogiOptions installation. Probably not very useful
for now.
The MX Anywhere 2 mouse has a problematic special key (index=7). When
trying to get the reporting value of this key, the device returns an
"invalid argument" error. [1]
To avoid giving up all good information about other keys, ignore error
(and the cause) when enumerating special keys.
[1] https://github.com/libratbag/libratbag/issues/558#issuecomment-439732655
I'm pretty sure all callers rely on this command to return either 0 or a
negative errno. There's a quirky occasion where if we get a HID error (a
positive number) during hidpp20_special_keys_buttons_get_reporting, that
number eventually ends up as the 'num_controls' value in
hidpp20_special_key_mouse_get_controls().
Since the only time we care about HID++ errors is during
hidpp20_root_get_protocol_version, let's just always return -EPROTO on HID++
errors.
Fixes#558
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
https://bugs.llvm.org/show_bug.cgi?id=3888
clang analyzer doesn't know how to handle __attribute__(cleanup()).
There are only 2 warnings raised because the analyzer only look at the
current compilation unit for checking the malloc call. So only those
2 are detected by clang and then marked as memory leak.
This also means our current continuous integration doesn't check for
memory leaks.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The bitmask in the 8060 report is for ms between reports. We could do all, but
really we only care about a few resolutions, anything else is too niche to
bother with.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
struct hidpp20_led_sw_ctrl_led_info holds a u8 for the .type field.
Attempting to convert a value which is already a u8 ends up setting
0 and thus discarding the type information.
Fix by removing the extra step.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
