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>
This patch adds nothing but some debug outputs and prepares the code
to support the recent gaming mice from Logitech.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This adds udev rules/hwdb that sets RATBAG_DRIVER and RATBAG_SVG
properties to the event devices. We then use this property to select
the correct driver instead of checking the hardcoded list in the
drivers. Having this in a hwdb makes it easier for users to test
if drivers match their mouse with a system installed libratbag.
Each driver now has an "id" which is used to match the driver set
in RATBAG_DRIVER. A SVG can optionally be set as well.
All entries in the hwdb are currently without a name as that
information was not available in the hardcoded lists.
Note that this patch breaks the test-driver.
This reverts commit d5a20efd8b.
The API is horrible. Better having 2 additional functions to get
the usage and usage pageof the report.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Add a match against the usage page and the usage.
If we are not interested in this new match, we can just use 0.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Some mice have a separate hid interface for configuring the advanced
features. It occurs that this is a common enough use case to be handled
directly by libratbag-hidraw instead of having a per-device quirk.
The idea is to allow opening the sibling hidraw devices during .probe()
and to give a matching callback. If the callback succeeds, then the
hidraw node will be used.
With this, one device might be opened several times, this has to be fixed
in a separate commit.
Fixes issue #19
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The G303 is a wired device and we need to talk to it with 0xff (OK a
#define would be good). This was not a problem for all of the unifying
devices given that the kernel overwrites the device_id for us, but the
corded devices are a different kind, and this one rejects device id != ff.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Don't use a default here, let the compiler tell us when we're not handling a
value expclicitly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's not pretend we will handle out-of-memory errors correctly, and really,
it's not something we really need to be worried about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Or it leads to interesting errors when adding fields to the table
of supported devices.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
etekcity suppports macros already, the other two don't. hidpp10 doesn't
support any write stuff but let's claim we do anyway.
The driver hook for this isn't ideal, read_button is called during init but
we should set all this up during probe and then use read_button exclusively to
update the button, not set the capabilities as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It is a common pattern to have:
ratbag_resolution_init(...)
profile->resolution.modes[i].xxx = yyy;
ratbag_resolution_set_cap(&profile->resolution.modes[i], zzz)
So instead of dealing with the internal fields of profile/resolution/modes,
just return the resolution that has been initialized.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Currently only the hooks for x/y resolution, the rest is unimplemented. Also
the etekcity driver needs an update here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Long-term we should have probe() and read_profile(), the latter of which
should read each profile and fill in _all_ information.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When we read the profiles, we need to know the capabilities of the device.
If the device has not been enumerated, then we are screwed.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
