Spec says the profile count is stored in byte 3 of
CMD_ONBOARD_PROFILES_GET_PROFILES_DESCR, so use this to allocate the proper
number of profiles.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This reverts the version number but ratbagd is nowhere near stable (because
libratbag itself isn't stable yet) and the dbus API can change at any time.
I'm not committing to keeping the current dbus API around for backwards
compatibility reasons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This just exports the button index so far and makes sure we can write clients
that deal with button objects instead of making stuff up to test for buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Doing just a first release of libratbag with its current features and
problems. This will help other tools to properly link against anything
libratbag >= 0.2
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Returning the object path makes it harder for the client to identify which
object is the active one. A simple index into the devices array is easier to
handle.
Note: another approach was to have an IsActive property on the profile
directly. This would require updating all properties when the active profile
is changed, it's simpler to just have one index.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
sd_bus_encode_many() escaps elements starting with a digit so our 0 profile
has an object path of /.../_30. This is quite confusing during debugging.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Missing from 960ee73da9.
In case a hid++ 1.0 device has only 1 profile enabled under LGS, libratbag
exports only 1 profile, and thus the profile and button keys capabilities
are missing.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
