Bug 76461
Summary: | USB HID modifier keys dropped when encoded in key array | ||
---|---|---|---|
Product: | Drivers | Reporter: | Bryan C. Mills (bmills) |
Component: | Input Devices | Assignee: | drivers_input-devices |
Status: | NEW --- | ||
Severity: | normal | CC: | adam, benjamin.tissoires |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 3.13.7-1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
evemu-record output for "+ctrl, +alt, -alt, -ctrl"
usbhid-dump -e all |
Description
Bryan C. Mills
2014-05-19 02:43:21 UTC
Created attachment 136761 [details]
usbhid-dump -e all
usbhid-dump with descriptor
It took me a while to realise that the device is sending two times the modifiers in the same report: - the first byte is the reportID - the second byte contains an array of modifiers, which are null in your case (control, alt, shift, GUI, for left and right) - the third byte is a constant - the last five bytes are the actual array of keys. The following occurs: - DC 00 00 E4 00 00 00 00 is translated to: input_event(input, KEY, KEY_LEFTCTRL, 0) input_event(input, KEY, KEY_LEFTALT, 0) ... input_event(input, KEY, KEY_LEFTCTRL, 1) - DC 00 00 E4 00 00 E2 00 is translated to: input_event(input, KEY, KEY_LEFTCTRL, 0) input_event(input, KEY, KEY_LEFTALT, 0) ... input_event(input, KEY, KEY_LEFTALT, 1) (KEY_LEFTCTRL 1 is ignored because the array already set it) - DC 00 00 E4 00 00 00 00 is translated to: input_event(input, KEY, KEY_LEFTCTRL, 0) input_event(input, KEY, KEY_LEFTALT, 0) ... input_event(input, KEY, KEY_LEFTALT, 0) - DC 00 00 00 00 00 00 00 is translated to: input_event(input, KEY, KEY_LEFTCTRL, 0) input_event(input, KEY, KEY_LEFTALT, 0) ... input_event(input, KEY, KEY_LEFTCTRL, 0) So there is a conflict between the modifiers at the beginning of the report and the actual keys in the array. I can see two solutions to fix that: 1. change hid-input.c to send the key down no matter was the previous state 2. fix the report descriptor of the device, and set the first byte as constant. Both solutions are working, but I am not sure which one to pick actually. The second one should be preferable, but we need more tests with the device to be sure that the first useful byte is actually always 00. The report descriptor is actually accurate - when programmed for mod+key combinations all on one pedal, the footswitch encodes the mod bits in the second byte and the remaining keys in the 5-byte array. If you like, I can reprogram the pedal and send traces exhibiting this behavior. (Unfortunately, it doesn't correctly union the mod bits, but that's clearly a defect of the manufacturer and not a bug in the kernel.) So amending the descriptor would actually break some functionality of the switch, albeit functionality that I'm not using and don't really care about. (There may be other users who do care about that, though.) That being the case, I think option (1) (send the key-down regardless of state) is preferable. |