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.
If we could not start the process, there is a high chance we are running
the tests against a different ratbagd implementation so there is no point.
Also, an exception will get raised later during the tear down of the
module saying that "'NoneType' object has no attribute 'terminate'".
This is less than ideal to notify that the process has not been started.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the other commands try to access a node, there will be an other error
("Unable to find device X"). So there is no points in having this as a
global check.
For the .devel and .test versions, we are guaranteed to have the
test_device at least, so no worries on this side too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
