We can't guarantee it's a sysname even though that is what we use for evdev
devices. Future devices may just be some custom-assigned name for a remote
dbus API
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least on HID++ 2.0, the LED types appear to be random and don't match the
protocol specs. Other protocols don't even have those bits, so let's make this
a generic entry.
This is pre-filled for all LEDs but drivers can override it where required.
Fixes#377
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tools/ratbagctl.in:146:92: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:147:92: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:154:91: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:155:91: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:161:118: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:162:118: E126 continuation line over-indented for hanging indent
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
If HIDPP_PAGE_COLOR_LED_EFFECTS fails but the profile returns a nonzero LED
count we crash later in hidpp20drv_read_led() because all the led info is
null.
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>
With the swtich to the commit style the function
hidpp10drv_write_resolution_dpi is doing too much work.
Before commit style the function would:
* get the profile
* get the current resolution
* write the profile (resets it to default dpi)
* set the current (updated) resolution
With the commit style we call the function for every resolution
in every dirty profile we now:
* get the current resolution
* set the current (updated) resolution
Then later:
* write the profile (resets to default dpi)
This patch changes this to only doing one set of the current resolution
when the active profile has been written. This reduces the traffic to the
device and sets the current resolution after the profile write.
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>
For the device I have I do not see a way to get
this information by querying the device.
If the value is set in the .device file it will
override anything that the hidpp10 driver itself
would have found.
1-bit RGB is needed for the Logitech G300, let's rename the main RGB to
indicate how many bits we actually have.
See #335
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since we unconditionally call unlink() on that path later, let's make sure
we actually copy to that file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The initial value of 400 in the enum is chosen so it looks weird when someone
tries to interpret the value as integer. Values of 1, 2, 4, etc. could be
confused with something realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Writing multiple changed profiles was broken as we would exit the
loop after the first profile write. We were returning the number
of bytes written and this was interpreted as an error.
Fix it my returning 0 when we have written the correct number of
bytes to the mouse.
