-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Everybody,
Jamie Guinan wrote:
See if "evdev" is loaded, then try reading the various /dev/input/event* nodes.
Yes, evdev is loaded and I see some /dev/input/event* nodes. The unique ones for this device (that show up when I plug in the device) are event3 and event4. Also, I see mouse1 and ts1.
I have a USB keyboard here. Oh neat, under 2.6.19, they even give you a path that matches the device ids,
# od -x /dev/input/by-id/usb-1241_1203-event-kbd (tap tap tap...) 0000000 92a9 460e 0000 0000 36dc 000b 0000 0000 0000020 0001 001c 0000 0000 92a9 460e 0000 0000 0000040 36e0 000b 0000 0000 0000 0000 0000 0000 ...
In /dev/input/by-id, I see: usb-Cypress_Cypress_PS.2_Keyboard-event-{kbd,mouse} usb-Cypress_Cypress_PS.2_Keyboard-mouse
I tried your "od -x" trick on each of these to no avail. I pointed the barcode scanner at some arbitrary barcodes, and it beeped and turned off the red light, but nothing appeared on my screen as a result of the "od -x".
Are there other possibilities to consider?
At this point I'd start putting printk's and turning on DEBUGs in the kernel source. For starters, drivers/usb/input/hid-core.c:hid_input_report() drivers/usb/input/hid-input.c:hidinput_configure_usage() I typically do something like this, $ make $ make modules_install INSTALL_MOD_PATH=$(pwd)/tmp (don't go installing under /lib just yet) $ rmmod foo $ insmod ./tmp/..../foo.ko [ unplug, replug, dmesg, tail messages, rinse, repeat ] -Jamie