When a touchpad event occurs while the device is being queried (e.g.
for features), then do_io (for do_read) would fail because the report
was not of the correct type (0x20 vs 0x11 for example). To fix this,
make do_read retry reads (within the allowed timeout).
Previously the expected report type was hidden in the msg parameter,
make this expected report type more explicit now in a new parameter.
Fixes the warning messages below:
$ ltunify unpair 2
Unexpected disconnection type 0000
Device 0x02 Touchpad successfully unpaired
$ ltunify pair
Please turn your wireless device off and on to start pairing.
Found new device, id=0x02 Touchpad
Dev conn notif is expected to be short, got 0x20 instead
Dev conn notif is expected to be short, got 0x20 instead
Dev conn notif is expected to be short, got 0x20 instead
Dev conn notif is expected to be short, got 0x20 instead
Dev conn notif is expected to be short, got 0x20 instead
Use basename instead of memcmp with some calculations. Move the hiddraw device
matching outside a block in preparation for adding multiple match conditions.
In case a message does not get a response (user pulled out the receiver,
thunder hit the device, coke has fallen on a keyboard, etc.), do not wait
`for(;;)`. (2 seconds because accessing registers may be slow)
Warning: I am sleepy so there may be bugs or ugly code. It is tested and works
on a K800 keyboard though (and of course it should abort when trying on my M525
mouse).
This changes the behavior of validate_args to return the number of command
arguments. The timeout value for "pair" is also validated and the version
number printed.
The memcpy bug is actually a real one-by-off. Since the msg_long struct is
contained in a union of hidpp_message, this does not lead to
write-past-boundaries (but it may read more than intended).
Some fields of version could be uninitialised (when the register query failed).
Explicitly clear the values to make clang happy.
