Comment 18 for bug 405390

I done some more side to side testing with another wireless usb and mouse set I have made by Creative, that works as you would expect.

I think arehnius has a red herring with regards to the lsusb tree output, I get that whenever both my working and non-working (i.e. ortek) are both plugged in, but not when only one of either are plugged in. That doesn't change the fact that the creative always works and the ortek never does.

By 'not work' I can confirm that it is only the main keys, not the meta keys (ctrl+alt+win) which are picked up when catting the /dev/input device for the keyboard. The trackpad works as expected, as do the volume up/down keys which are picked up when catting the /dev/input device for the mouse.

Note that these keys work fine in grub, I can freely edit the boot line and the keyboard behaves as you would hope.

So I compiled the kernel with some more debug options. See attached the kernel output when connecting and disconnecting both the ortek keyboard and a working keyboard (creative). Hopefully they'll be useful to someone who understands these things more.

Interestingly the keypresses are being picked up somewhat. If I do an "echo 1 > /sys/module/hid/parameters/debug" and then watch the kernel output I am seeing identical output for keys on the working keyboard as I am on the ortek e.g.

Dec 10 23:10:37 fructose kernel: [ 1228.799642] drivers/hid/hid-core.c: report 3 (size 5) = 03 00 02 fe 00
Dec 10 23:10:37 fructose kernel: [ 1228.815633] drivers/hid/hid-core.c: report (size 5) (numbered)

So at this point I presume we have enough information to target the relevant developers to investigate- if hid-core is receiving keystrokes but X isn't getting a keypress event then what glue inbetween isn't doing its job?