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>
To be able to query which modes are available.
Exposed via ratbagctl as
./build/ratbagctl.devel led 0 capabilities event4
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>
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>
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>
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>
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>
allocate was actually both initializing and allocating through initialize.
Things started to get complicated.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The hwdb was a quick and easy way to add entries for new devices but we need
more and more info about the various types of devices. It's better to move
this to a proper database.
Side-effect: this also gives us an easy way to point to the list of devices
supported and makes checking for e.g. missing svgs easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bunch of errors while processing the dictionary of enabled profiles.
Got everything working out quite well on the G900 and G403, so I guess
others should behave properly.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Any specific capability like 'switchable resolution' requires the basic
'resolution' capabilty to be set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the profile is not active, we do not know which resolution is currently
used. Instead of having ratbagd complaining, just set the default as
active.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Shouldn't change the behavior, but this allows adding the other effects
found in the documentation.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We are using a uint in the end, so better have proper order in the
multiplications/divisions than using doubles.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
When using the G502 without RGB LEDs, the feature 8070 is not here.
And this segfaults :)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The onboard profile do not store the current value but the default.
To retrieve the current value, we need to access the switchable resolution
feature.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the macro has not been retrieved, it's more likely that the button
is not bound to anything.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Once we start probing devices for multiple drivers we shouldn't just print
error messages for every failed driver. In the hidpp20 case an error would be
printed for any hidpp10 logitech device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No need for two separate cleanup blocks, they're doing the same thing anyway.
Just make the function more robust to uninitalized fields and we're good to
go.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
hidpp10 devices have their own driver, let's not initialize them here and just
fail. If a hidpp10 device is assigned the hidpp20 driver this is a bug.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No reason for the drivers to have their own printf each, just return the
negative errno and let the common code print it.
This now also means that we only return -ENODEV on something that's not really
an error, for anything else we print the strerror.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous API was inconsistent and different to the rest of libratbag's
API. Replace with one where a macro is a separate struct, can be initialized
and then written to the device with a set_macro() call. The device copies the
contents, the macro is otherwise unmodified and can be re-used by the client
if need be.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We do not have any driver using it, and we are not sure this will even
be required. Before releasing a version with this, remove it. We
can always re-add this later if the need appears.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Most of the capabilities can be inferred from
ratbag_device_init_profiles():
- if a device has more than one profile, we should be able to switch
between its profiles
- likewise, more than one profile means that the buttons can be remapped
- more than one resolution means that we can change the resolution.
We need to add a stub in driver-test for .set_active_profile() now that
RATBAG_DEVICE_CAP_SWITCHABLE_PROFILES is correctly set.
We manually add the macro capability for all drivers that present it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
