Gentoo Linux

Bug #124406
Comment #310

Comment 310 for bug 124406

Revision history for this message

Bryce Harrington (bryce) wrote on 2011-04-28:

#310

Heh, I see my comment about this being a minor annoyance got people in a huff. ;-)

Anyway, as to whether it's a kernel or X problem, it's sort of a bit of both. (The best bugs live in the cracks between two codebases.) X and the kernel communicate key events as signals rather than via threading. And it only handles one signal at a time, so if for some reason the key up signal was fired while another signal was being handled (e.g. from another device in your system) then it can get lost. That's why hitting a key a second time (to fire a new up-key signal) makes things work. The way signals behave is a kernel thing, so this is why it's partly kernel, partly X. Essentially it's a race condition. For deeper information see http://ajaxxx.livejournal.com/62378.html

Really, it sounds like it's an upstream design flaw in X. Ajax appears to be thinking that the whole system should be ripped out and replaced with a threading system. My own experience with threading is that sometimes the cure can be worse than the disease... threading can be quite hard to get right and sometimes has nasty side effects. Needless to say, such a change is not trivial and not something we'd do at the Ubuntu distro level - definitely work that needs done upstream. Maybe Wayland will gain a better system for handling keyboard events, and that's where efforts today should be directed? Don't know.

As an aside, you guys are right that there could conceivably be some rare scenarios where this bug could cause some severe issue like a stuck delete key deleting files or whatnot. Maybe some of you have even experienced something like that. But for the vast majority of cases, the issue will exhibit itself as extraneous characters when you're typing documents and some such - definitely a lot less severe than random GPU lockups or sudden X crashes back to the login screen or your monitor suddenly turning tie died. These latter issues are unfortunately not as uncommon as I'd like, and until they are I tend to judge anything less severe as a "minor annoyance". ;-)

But annoyances are bad. While I don't think this issue is one we're likely to work on in Ubuntu at the distro level, I can give some advice about how to go forward with it, if you're wanting to pursue it yourself. (And FSM bless you!)

Due to the nature of the issue, it's frequency and severity are going to vary from hardware to hardware. Due to timings in hardware interrupts and signal generation, and even interactions with software, you might see it only with a particular combination of keyboard, motherboard, and mouse. Or it might go away after turning off your wireless. Or might go away for 3 Ubuntu releases and then suddenly and quite mysteriously reappear. Most of our typical keyboard debugging tools such as xev are going to be of limited value in investigating it; it may tell you that the release signal didn't show up, but that doesn't explain why. There are kernel debugging interfaces that will show what's going on there, but that gives limited insights as well.

The first thing I would look at is obtaining a reliable repetitive test case. Get together hardware and a set of steps that lets you reliably reproduce the issue on command, or with a sane enough frequency (like steps that let you reproduce >25% of the time). This makes testing less time consuming and also gives you a strong way to determine it's definitely fixed.

Next, it would be smart to ensure someone hasn't already fixed it. That could save you a lot of work. We provide xorg-edgers and kernel ppas to facilitate doing this. See https://launchpad.net/~xorg-edgers/+archive/ppa and http://kernel.ubuntu.com/~kernel-ppa/mainline/.

Finally the hard part, which will require code hacking. Touch base about this with Ajax to find if he has any experimental branches, or if he knows if anyone else is working on the problem, and how you can help. From his blog post, it sounds like the implementation of threaded input handling might be the real way forward, and that could probably benefit from extra testers and/or coders.

Heh, I see my comment about this being a minor annoyance got people in a huff.  ;-)

Anyway, as to whether it's a kernel or X problem, it's sort of a bit of both.  (The best bugs live in the cracks between two codebases.)  X and the kernel communicate key events as signals rather than via threading.  And it only handles one signal at a time, so if for some reason the key up signal was fired while another signal was being handled (e.g. from another device in your system) then it can get lost.  That's why hitting a key a second time (to fire a new up-key signal) makes things work.  The way signals behave is a kernel thing, so this is why it's partly kernel, partly X.  Essentially it's a race condition.  For deeper information see http://ajaxxx.livejournal.com/62378.html

Really, it sounds like it's an upstream design flaw in X.  Ajax appears to be thinking that the whole system should be ripped out and replaced with a threading system.  My own experience with threading is that sometimes the cure can be worse than the disease... threading can be quite hard to get right and sometimes has nasty side effects.  Needless to say, such a change is not trivial and not something we'd do at the Ubuntu distro level - definitely work that needs done upstream.  Maybe Wayland will gain a better system for handling keyboard events, and that's where efforts today should be directed?  Don't know.

As an aside, you guys are right that there could conceivably be some rare scenarios where this bug could cause some severe issue like a stuck delete key deleting files or whatnot.  Maybe some of you have even experienced something like that.  But for the vast majority of cases, the issue will exhibit itself as extraneous characters when you're typing documents and some such - definitely a lot less severe than random GPU lockups or sudden X crashes back to the login screen or your monitor suddenly turning tie died.  These latter issues are unfortunately not as uncommon as I'd like, and until they are I tend to judge anything less severe as a "minor annoyance".  ;-)

But annoyances are bad.  While I don't think this issue is one we're likely to work on in Ubuntu at the distro level, I can give some advice about how to go forward with it, if you're wanting to pursue it yourself.  (And FSM bless you!)

Due to the nature of the issue, it's frequency and severity are going to vary from hardware to hardware.  Due to timings in hardware interrupts and signal generation, and even interactions with software, you might see it only with a particular combination of keyboard, motherboard, and mouse.  Or it might go away after turning off your wireless.  Or might go away for 3 Ubuntu releases and then suddenly and quite mysteriously reappear.  Most of our typical keyboard debugging tools such as xev are going to be of limited value in investigating it; it may tell you that the release signal didn't show up, but that doesn't explain why.  There are kernel debugging interfaces that will show what's going on there, but that gives limited insights as well.

The first thing I would look at is obtaining a reliable repetitive test case.  Get together hardware and a set of steps that lets you reliably reproduce the issue on command, or with a sane enough frequency (like steps that let you reproduce >25% of the time).  This makes testing less time consuming and also gives you a strong way to determine it's definitely fixed.

Next, it would be smart to ensure someone hasn't already fixed it.  That could save you a lot of work.  We provide xorg-edgers and kernel ppas to facilitate doing this.  See https://launchpad.net/~xorg-edgers/+archive/ppa and http://kernel.ubuntu.com/~kernel-ppa/mainline/.

Finally the hard part, which will require code hacking.  Touch base about this with Ajax to find if he has any experimental branches, or if he knows if anyone else is working on the problem, and how you can help.  From his blog post, it sounds like the implementation of threaded input handling might be the real way forward, and that could probably benefit from extra testers and/or coders.