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>
We were limited to MAX_RESOLUTIONS (10). Also, this allows to know
during ratbag_device_init_profiles() if the device supports
switchable resolutions.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Do not interleave some internal ratbag initialisation with the hidpp20
initial reading.
During early init, we are just interested in knowing how many
profiles/resolutions/buttons the device supports, so we should not read
more than required.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The current code might call some other function when the device supports
onboard profiles. We should not query those extra functions given that
the profiles should give us all we need.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Dissociate the reading of the data from the device of the actual storing
of those data in the profiles. This will allow to call
hidpp20drv_read_resolution_dpi_2201() without having profiles to know how
many sensors are in the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
libratbag external API is currently not aware whether a given profile is
enabled or not. Before switching to a disabled profile, we need to enable
it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The button mapping of the hid++ 2.0 devices is close to the one from
HID++ 1.0, but not entirely (1.0 have a size of 3 while and 2.0 a size
of 4).
The parsing was not clean, so reuse a the same logic than hidpp10.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Most should be fine, though I did not tested each key.
HID++ 1.0 and 2.0 use it now, though HID++ 2.0 needs refinments (only a u8
is used though we need a u16)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Or we need to maintain the list of supported capabilities in a different
place, and it gets error prone.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Allows to navigate in the source more easily if they share a common
name.
However, this is still not good because we need to know which feature
number is which.
Though the format is now in sync with write_button.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Still missing the consumer control HID keys, but the rest works (minus
the modifier keys).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
To support profiles assignments, we need to split the various write
button functions.
Start with 1b04.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
profiles_list is not used anymore in hidpp20_onboard_profiles_get_current_profile
let's remove it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We need hidpp20 to handle the list of available features. So we need to be
sure in hidpp20 that we are talking to a hidpp20 device.
Move the version retrieval in hidpp20 where it makes sense.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This struct will be used to store the table features/index and probably
others. It also allows a single entry point to set the device index.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
'base' was wrongly inherited from the hidpp10 implementation, but actually
it makes no sense in this context.
Also, we want to reserve the keyword 'base' for when we introduce
hidpp20_device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
