Jump to content
Flirc Forums

"stuck" keys on mythbuntu 11.04


gfxmonk

Recommended Posts

using the `xev` program on both my media center machine (laptop running mythbuntu 11.04) and my ordinary machine (desktop running vanilla ubuntu 11.10), I can see that:

On the laptop only, sometimes pressing a button normally will cause repeated events to be sent until the next button is pressed (after which *that* button may be stuck on indefinitely). At other times it's fine, but it often seems to get stuck in this mode - i.e once a keypress starts repeating, future key presses probably will too.

With the same flirc, remote & config, running on my desktop, I have not been able to get this to happen. So I'm presuming it's something in the linux even stack somewhere? I'm not too sure where to look to figure out where the problem is. Is there some way to get flirc to dump logs of what events it thinks it's generating, to see if the bug is with flirc or linux?

I noticed a mention here ( http://blog.flirc.tv/?page_id=46 ) of "inter-key delay time to help fix when rapidly pressing causes `stuck key`". "Stuck key" seems to be my problem, but it's unrelated to how fast I press keys (a single press can trigger it). I also couldn't see how to configure or find out more about this delay setting - is it exposed from the command line tool?

If it's useful, my laptop is:

$ uname -a

Linux tjcee 2.6.38-12-generic #51-Ubuntu SMP Wed Sep 28 14:25:20 UTC 2011 i686 i686 i386 GNU/Linux

And my desktop:

$ uname -a

Linux meep 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Link to comment
Share on other sites

This definitely sounds like an OS problem, and the first of I've heard of something like this. Interkey delay is for something a bit different.

I'm sure linux has a GUI for configuring the keyboard. Maybe there is something in there.

When the key get's stuck, could you switch to a terminal and do a:

dmesg | tail

perhaps that would show us something.

Thanks gfxmonk

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

aenima99x: I think that's probably a different problem - sounds like random keypresses, if it happens when you haven't touched the remote. My problem is whichever button I press keeps being pressed over and over until I press a different button.

Aside: have you tried closing the curtains? My wii remote goes a bit mad when it's too bright outside and I have the curtains open.

Link to comment
Share on other sites

Yes, I agree, sounds like two different problems. Certainly create a different thread for that one, but gfxmonk is most likely right, this is probably noise due to ambient light.

@gfxmonk, there isn't really a log because flirc uses the generic HID driver that comes with the OS.

How USB keyboards work is this. When you press a key, the keyboard sends the key, followed by a null. The null says, "I'm not pressing the key anymore". Otherwise, the host thinks you are holding it down. One thing that could be happening is the null is sent too

quickly to the host, and the host misses this. But this really shouldn't be the case since I wait for the host to be ready.

One thing we can try is the interkey_delay. Changing this value will actually also adversely change the delay this termination signal gets sent to the computer.

You can change this with the command line:

flirc interkey_delay 0-7

Try increasing this.

Doing flirc interkey_delay by itself shows the current value set.

Let me know.

-- Jason

Link to comment
Share on other sites

Thanks Jason,

I tried upping the interkey delay to 7 (it was on 6 originally), but couldn't detect any change (I still get stuck keys). Just in case the original 6 was too high, I also tried setting it to 2, but that didn't have a noticeable effect either.

What would happen if it were to send multiple NULLs after each key, as a workaround? Or at least to check whether that's the problem. Is that plausible? Is there anything else I can do to try and prove whether that's the problem or not?

Link to comment
Share on other sites

  • 2 months later...

Thanks Jason,

I tried upping the interkey delay to 7 (it was on 6 originally), but couldn't detect any change (I still get stuck keys). Just in case the original 6 was too high, I also tried setting it to 2, but that didn't have a noticeable effect either.

What would happen if it were to send multiple NULLs after each key, as a workaround? Or at least to check whether that's the problem. Is that plausible? Is there anything else I can do to try and prove whether that's the problem or not?

Sorry, I dropped the ball, wondering how things were going? You still seeing this issue?

Link to comment
Share on other sites

Yep, it's still happening. It seems to be different in boxee itself compared to the normal X desktop. in X, once a key is stuck it will keep firing. In boxee, it seems to only trigger a handful of times. Not sure if that's a difference in the input handling, or if boxee has builtin filtering for accidental repeats.

I've hooked up a button to shut down mythbuntu without having to navigate the desktop, so I no longer have to deal with X much. But it still gets in the way of pausing videos a lot - instead of pausing, it'll often cause "pause" to fire a bunch of times, which actually speeds up the video for a couple of seconds before pausing. So yeah, I'd still love to see if this can be resolved somehow.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...