On the M705 I frequently get usb timeouts here if the device has
not been active for a while. Retrying after 10 ms seems to reliably
fix the timeout problem.
We could have just added the 10 ms sleep directly but it does not
seem to be neccesary on wired devices so I chose not to. Setting the
ret value to a face positive number and looping would also work but
we risk an endless loop. In the end I just went for a single retry
as that fixed the problem for me.
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>
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>
the logical and physical bits were inverted:
- logical is the action of the button
- physical corresponds to the actual button on the mouse (so the 'type')
- there is a duplicate from driver-etekcity to match 2 actions, this should
be factorized in a helper somewhere in a later commit
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Found on the Logitech MX Master. Most of other Logitech device with
physical ratchet disable capability do not show this button to the host
however.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
One giant commit, but I didn't know how to split this up easier. The problem
is a misunderstanding in what the button type is and the code that built on
that misunderstanding, requiring a lot of interdependent parts to be updated
at once.
The button _type_ is the physical description of the button.
The button _action type_ is what will happen when you hit the buttons.
The type is read-only, since we're not dealing with mr potato head here.
The action is adjustible and we now support buttons, keys and special
in-hardware actions (e.g. dpi changes). A few FIXMEs still in place, e.g. we
don't handle modifiers with keys.
For buttons we just take numerical button numbers. i.e. we can map a button to
button 4, which will result in BTN_SIDE, and eventually logical button 8 in X.
For keys we take KEY_FOO, since eventually we want this to come out as that
(could do this for button as well I guess). Modifiers are currently ignored.
For special actions we have a enum of actions we support.
The button type enum is thus reduced a lot, and everything needs to be
switched.
This breaks ratbag-command change-button, will be fixed later since it's
misdesigned as it is anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As seen on the T650.
Reusing most of 0x1b04 here, except this one only gives us control id, task id
and flags.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Problem: when a button is diverted, it stops sending its original button,
which is good, but then reports only on the HID++ long report collection.
That is a little bit embarrassing.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
well, there is no fine grain while outputing the raw events, so that
means that we have always shown the actual answer just before.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
I misread the documentation. The task_id corresponds to what the button
has been physically designed to, and the control_id is the logical
remapping.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The function does not take any argument, so the device ignores it,
but valgrind complains.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The 2.0 GetProtocolVersion request will fail on 1.0 devices but there is no
equivalent for 1.0. The doc even suggests to detect this error to determine
whether a device is a 1.0 device. Thus, make it conditional on whether we
print the error or not (log it as debug message if turned off).
This should be reconsidered when we have everything in place and can think
about refacturing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
0x8 was a random SW number picked, add that consistently and automatically so
it doesn't look like the command names require this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Lokks like the G500 needs a device_idx of 0x00, and the MX Master while on
Bluetooth only answers to report longs
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The Logitech devices talk HID++, and we need a lib to handle that.
The first implemented command is the get protocol version which allows
to know if the device is using hid++ 1.0 or 2.0.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
