If our device only has a discrete number of DPIs, pass it on as-is to
libratbag rather than pretending it's a range and then failing to set the
DPIs.
For the actual ranged devices we use libratbag's now-exponential range
mapping rather than passing all possible ones on. This relies on us having the
same steps that libratbag uses, should be safe enough.
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>
libratbag is not a library anymore. Move all the stuff that we need for the
DBus interface (i.e. the enum values) into its own header file so they're
all in one place and we don't have to worry about it anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, probe() would call ratbag_init_profiles() which in turn would call
the various function pointers in the driver to fill in profiles, buttons and
leds (the latter while filling in profiles). This made the probe() function
harder to understand than necessary and unreliable because it wasn't always
clear which bits were already set up while some driver function was called and
which ones weren't yet.
This patch switches to a flat probe(). The driver still needs to call
ratbag_init_profiles(), libratbag sets up everything (to default values). Then
the driver can fill in the rest as it wants.
This patch still makes use of the current infrastructure, the drivers
just call the read_profile and read_button functions manually now.
Fixes#370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resolutions were still stored in an array over a linked list like the
buttons/leds/profiles and initializing them from a driver was different than
buttons or leds. This brings the resolutions in line with the buttons and
leds.
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>
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.
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>
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 a profile is either wrong or not there, we rely on the ROM to get
a correct profile.
Fixes#280
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The driver is supposed to prepare everything in memory and then, at the
end commit on the device.
Bug #280 is still not fixed as we should initialize empty profiles first.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
