Designates a device that can be queried for the current configuration. Some
devices lack this ability so we rely on the caller to upload a known
configuration to the device before we can really proceed.
Set by default, devices without that capability should be the exception, not
the norm.
This patch just adds the capability, actual handling for this needs to be
added when we add the first device without this capability.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the G9 the response to a 0x63 is a short report. The G9 does
not have individual resolutions for X and Y and thus only needs
to report a single value.
The set version of 0x63 should probably also be updated. However,
while my testing of such a change worked better than with long
reports there are still strange side effects of setting resolution,
like turning off all the LED's. LGS also seems to do a full profile
read/write instead of using 0x63 when changing the resolution.
The G303 shares the same profile than the G402/G502. The only difference
is an extension at the end of the profile, but they are compatible.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Mostly inherited from our zalloc() implementation. But really,
if you have no memory left, should you be trying to talk to receivers?
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are 10 buttons defined in the profile but only 9 physical
buttons. LGS also only allows to configure 9 of them. Button 5
is the "dead" button in the list.
Get_Profile_Info gives valuable information to know if we are compatible
with a given device. Use it and bail out if we are not able to support
the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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>
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>
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>
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>