Hi Benjamin,
thanks.
The answer is different in the first case and 7 seconds after (I assume
you toggled the setting there) -> frame 16 and 33 in the first log.
I'd say the first log would be:
- 1. -> SET_IDLE (you can ignore it)
- 3. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 4. -> 02 04 02 00 00
- 5. -> SET CONFIGURATION Status (ignore this as well I think)
- 6. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 7. -> 02 06 00 00 00
- 9. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 10. -> 02 05 01 00 00
- 12. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 13. -> 02 02 01 00 00
- 16. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 14. -> 02 03 01 00 00
The second sequence (frames 18 to 34) provides the same output except
for the last answer 02 03 00 00 00.
Yes, that was my analysis as well. Thanks for confirming this.
The "no data" part seems weird, but there is a chance if you output a
report with 02 03 00 00 00 or 02 03 01 00 00, this toggles the behavior.
Yes, I was wondering about exactly that, maybe I need to read up on
the limitations of USBPcap to find out why apparently no outgoing data
is reported. But I will try sending it as you suggest.
If you start working in kernel space, start with a small hid driver and
in .probe() try accessing the device with the event sequences you got.
If you start working with hidraw, there is an example in the kernel
tree: samples/hidraw/hid-example.c.
Thanks for these hints! I realized I already did work on HID stuff
once when I amended a userspace program for a USB FM transmitter that
registered as HID device. I will try your suggestions.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
