eventX different after USB keyboard is reconnected

[GoogleCodeExporter]

Here are the steps to reproduce:

1. start logkeys with USB keyboard connected to computer
2. disconnect USB keyboard
3. reconnect USB keyboard
4. logkeys stops logging
5. stop logkeys
6. restart logkeys
7. logkeys runs, but does not log any keystrokes

I did some detective work to find out why this is.

The problem is in the code to detect the input device. After reconnecting the 
USB keyboard, the event numbers in /proc/bus/input/devices are no longer in 
sequential order, but for the input device detection to work they must be 
sequential. This is why the wrong event number is selected for reading keyboard 
events.

Attached below is a copy of my /proc/bus/input/devices file after reconnecting 
the USB keyboard. As you can see, the 6th item has event3, not event5, as the 
input device detection code assumes.

I'm working on a new input device detection routine, which will work when USB 
keyboards are reconnected. If you are interested, I would be happy to send it 
to you when finished.

--
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
U: Uniq=
H: Handlers=kbd event0 
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1
U: Uniq=
H: Handlers=kbd event1 
B: EV=3
B: KEY=10000000000000 0

I: Bus=0017 Vendor=0001 Product=0001 Version=0100
N: Name="Macintosh mouse button emulation"
P: Phys=
S: Sysfs=/devices/virtual/input/input2
U: Uniq=
H: Handlers=mouse0 event2 
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3

I: Bus=0003 Vendor=046d Product=c054 Version=0111
N: Name="Logitech USB Optical Mouse"
P: Phys=usb-0000:00:1a.2-2/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.2/usb5/5-2/5-2:1.0/input/input5
U: Uniq=
H: Handlers=mouse1 event5 
B: EV=17
B: KEY=ff0000 0 0 0 0
B: REL=143
B: MSC=10

I: Bus=0001 Vendor=10ec Product=0888 Version=0001
N: Name="HDA Digital PCBeep"
P: Phys=card0/codec#0/beep0
S: Sysfs=/devices/pci0000:00/0000:00:1b.0/input/input6
U: Uniq=
H: Handlers=kbd event6 
B: EV=40001
B: SND=6

I: Bus=0003 Vendor=04f2 Product=0760 Version=0111
N: Name="Chicony USB Keyboard"
P: Phys=usb-0000:00:1a.2-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.0/input/input15
U: Uniq=
H: Handlers=kbd event3 
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=04f2 Product=0760 Version=0111
N: Name="Chicony USB Keyboard"
P: Phys=usb-0000:00:1a.2-1/input1
S: Sysfs=/devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.1/input/input16
U: Uniq=
H: Handlers=kbd event4 
B: EV=13
B: KEY=2000000 387ad801d001 1e000000000000 0
B: MSC=10

Original issue reported on code.google.com by msvil...@gmail.com on 15 Aug 2010 at 5:48

[GoogleCodeExporter]

Very good investigative work!

Spawning just one more grep process, the workaround could be as easy as:

grep -E 'Name|Handlers' /proc/bus/input/devices | grep -EA1 '[Kk]eyboard' | 
grep -Eo 'event[0-9]+'

However, I would be very interested in your solution. :)

Original comment by kernc...@gmail.com on 15 Aug 2010 at 6:20

• Changed title: eventX different after USB keyboard is reconnected
• Changed state: Accepted

[GoogleCodeExporter]

Disregard that last part.
I am more than interested. :D

Original comment by kernc...@gmail.com on 15 Aug 2010 at 6:23

[GoogleCodeExporter]

Hello!

The attached file contains the code for a new device detection routine, which I 
just finished writing.

Here is how it works:
- opens the file /proc/bus/input/devices
- scans for rows that begin with 'N' (name rows)
- checks if the name row contains text that indicates it's a keyboard (contains 
"keyboard", "kbd", "hid", etc.)
- then scans for rows that begin with 'H' (handler rows)
- extracts the event number from the handler row

It has some features to try to make it robust. For example, if a keyboard 
device is found but there is no handler row, then the code just continues 
looking for the next keyboard device.

Also the code should be easy to modify to locate all keyboard devices (e.g. 
return a std::vector<std::string> containing all input devices found). Right 
now it stops when it finds the first one.

Finally, please note that I have only spent about 30 minutes testing this 
routine. It seems to work properly on my machine, but bugs may turn up. :-)

Best regards,
Markus.

Original comment by msvil...@gmail.com on 15 Aug 2010 at 6:47

Attachments:

• device_detect.cpp

[GoogleCodeExporter]

Oops :-) I just noticed that my determine_input_device() function is missing 
the following line at the very end:

    return std::string();

If no keyboard devices are found, and a return statement is not there, then we 
will get undefined behaviour.

Regards,
Markus.

Original comment by msvil...@gmail.com on 15 Aug 2010 at 6:52

[GoogleCodeExporter]

Device detection now parses 'Handlers' line and results in a vector since r74.

Original comment by kernc...@gmail.com on 19 Aug 2010 at 5:58

• Changed state: Fixed