Unfortunately there is no simple solution who gives you the full trace of data stream. But there are some tools who can help you when you try to write your own keyboard driver for example.
lsusb
Initially identify your devices using lsusb command. Simply run lsusb. Here you can take vid:pid identificator pair for further tests. Also lsusb command can help you to see all descriptors except report with command:
lsusb -v -d 0x046d:0xc221
My lsusb output:
dltech@dltech-IC780M-A2:~/src/usb_device3$ lsusb
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 002: ID 1c4f:0034 SiGma Micro XM102K Optical Wheel Mouse
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 004: ID 1a2c:2d23 China Resource Semico Co., Ltd Keyboard
Bus 005 Device 024: ID 046d:c221 Logitech, Inc. G11/G15 Keyboard / Keyboard
Bus 005 Device 023: ID 0483:3748 STMicroelectronics ST-LINK/V2
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
dltech@dltech-IC780M-A2:~/src/usb_device3$ sudo lsusb -v -d 0x046d:0xc221
005:029:000:Interrupt transfer timed out
No more interfaces to dump
Firstly here is a report descriptor, then it shows obtained reports, which signalings a button push. In order to check my fw properly, I compare descriptor and report data with similar ones from keyboard of my PC. After a few edits of the code, I got similar results for my keyboard as factory one. It is important not to modify too much standard report format, cause typical one, suggested as example in standard is BIOS compatible. Also you can add extra custom configurations who can be chosen by OS driver.
evtest
That utility work with the kernel. So it shows device data already translated by kernel driver. In order to use it, run it as root and find your device in the list. Secondly run test for your keyboard using command:
And if in previous case we seen a standard keyboard report package with 0x04='a' key keyboard code. In evtest dump at the same moment we can see an event with 'a' key push.
Now, when I proven that my keyboard is recognized by both test programs (usbhid-dump and evtest) I can be sure in my controller firmware variant. Although at first test it passed test of usbhid but was partially working in evtest. The problem was in LEDs, linux driver ignores keyboard without numlock and capslock LEDs. In fine, when I added fake LEDs to my firmware, my custom keyboard work properly.
Of coure, keyboard firmware is a simple extention of gamepad firmware. You can find both in the same repo.
pike in the eye?
ОтветитьУдалитьBLS into ass
Удалить