Thanks Jason,
I checked dmesg, but there was nothing interesting - no new messages appeared when the keys got stuck. Here are the last messages anyway:
[ 11.927379] USB Video Class driver (v1.0.0)
[ 11.964379] type=1400 audit(1322894267.482:6): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=672 comm="apparmor_parser"
[ 11.982704] eeepc_laptop: TYPE (2000000) not reported by BIOS, enabling anyway
[ 11.990796] type=1400 audit(1322894267.510:7): apparmor="STATUS" operation="profile_load" name="/usr/sbin/mysqld" pid=674 comm="apparmor_parser"
[ 11.999295] type=1400 audit(1322894267.514:8): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=672 comm="apparmor_parser"
[ 12.000018] type=1400 audit(1322894267.514:9): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=672 comm="apparmor_parser"
[ 12.000544] eeepc_laptop: PANELPOWER (4000000) not reported by BIOS, enabling anyway
[ 12.000561] eeepc_laptop: Get control methods supported: 0x6101713
[ 12.007745] type=1400 audit(1322894267.522:10): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/ntpd" pid=680 comm="apparmor_parser"
[ 12.032092] input: Asus EeePC extra buttons as /devices/platform/eeepc/input/input7
[ 12.040146] type=1400 audit(1322894267.554:11): apparmor="STATUS" operation="profile_load" name="/usr/sbin/tcpdump" pid=681 comm="apparmor_parser"
[ 12.124342] input: flirc.tv flirc as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input8
[ 12.124764] generic-usb 0003:20A0:0001.0001: input,hidraw0: USB HID v1.01 Keyboard [flirc.tv flirc] on usb-0000:00:1d.0-2/input0
[ 12.136574] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input9
[ 12.143313] input: Microsoft Microsoft IntelliMouse® Optical as /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/input/input10
[ 12.144608] generic-usb 0003:045E:0039.0002: input,hidraw1: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse® Optical] on usb-0000:00:1d.1-2/input0
[ 12.144830] usbcore: registered new interface driver usbhid
[ 12.144839] usbhid: USB HID core driver
[ 12.147269] [drm] Initialized drm 1.1.0 20060810
I went to the keyboard options and disabled key repeat, and tested that this works with the keyboard - no matter how long I hold down a key, it would not repeat it. This was interesting for two reasons:
- Boxee ignores or subverts this setting, and triggers repeated events anyway when I hold a keyboard key down ( a pity, as otherwise this would be a somewhat useful workaround)
- with key repeat disabled and using any app other than boxee, I can see that no matter how many times I press the same key in a row, it only registers once. Pressing a different key will trigger that key the first time, and then no longer. So if I were to type on my remote keys equivalent to "aaaaaabbcba" it would only register "abcba".
From this, I am pretty convinced that either flirc isn't sending the key-up event, or linux isn't seeing it - linux thinks the key is held down until I press a different key. Which at least narrows it down to not being an issue of sending repeated key-down events, as best I can tell.
Is there any way to get flirc to dump some logs of what is going on? I am comfortable with recompiling software, if that helps.