2.6.31-rc6 (yeah, I know...): weird tty / X.org state currently

2.6.31-rc6 (yeah, I know...): weird tty / X.org state currently

[Andreas Mohr]

Hello all,

forgive me for posting about such an ancient version,
but I'm facing very weird control key state issues here
(or would they be related to the recent tty layer issues?)
that I deem to be worth posting about.

Yesterday I had a full lockup of my keyboard in X.org.
(note that this might be related to very ugly block layer lockups,
in worst-case scenarios even mouse cursor stuck up to a whole _minute_
in case of heavier traffic on this el-cheapo PATA SSD).

[ # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set ]

And somehow I have a hunch that these unusual and very large latencies
may have played a role in suddenly having the keyboard lock up completely
in X.org.
Nothing helped, neither changing display device configuration (this
did help in other environments!), nor fiddling with KDE accessibility
abominations, nor fiddling with keyboard / mouse settings in KDE
systemsettings.
X.org keyboard stayed stuck solidly, only going down to other ttys worked
just fine.

But the kicker happened when I restarted kdm to restore my keyboard!
While this worked, in the new session I observed _very_ strange
behaviour:

In konsole, normal letters and control key combinations (Ctrl-l vs. l)
worked absolutely fine, but typing such normal things as Alt-Left or Alt-F2 or
Alt-F4 went down to ttys(!!). IOW, the kernel's control key status was stuck
but not stuck.
Once in a text tty, the control key status was sane _as well_, IOW no
Ctrl-l behaviour when simply typing an l.

Possibly the kernel's control key state got stuck in a weird state,
perhaps due to some input layer race conditions or so.

Or is it X.org's input handling which is responsible for Ctrl-Alt-F1
etc. combos? I wouldn't think so...

Ah wait, probably it's not any control key state mismatch, but there's
probably simply a "any graphical tty additionally has a Ctrl-key
requirement to lock against tty changes" flag which is BROKEN (disabled)
in the case of my currently running(!) GUI tty session.
(go fetch any bug analysis while they're hot! ;)

Aspire One netbook, u9.04, 2.6.31-rc6 (not upgradeable at this instant).

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
943/940GML Express Integrated Graphics Controller (rev 03)

ii  xserver-xorg-input-evdev                   1:2.1.1-1ubuntu4		X.Org X server -- evdev input driver
ii  xserver-xorg-input-kbd                     1:1.3.1-2ubuntu1		X.Org X server -- keyboard input driver
ii  xserver-xorg-input-mouse                   1:1.4.0-1 X.Org		X server -- mouse input driver
ii  xserver-xorg-input-synaptics               0.99.3-2ubuntu4		Synaptics TouchPad driver for X.Org/XFree86 server
ii  xserver-xorg                               1:7.4~5ubuntu18		the X.Org X server

Thanks,

Andreas Mohr

Re: 2.6.31-rc6 (yeah, I know...): weird tty / X.org state currently

[Dmitry Torokhov]

On Thursday 10 September 2009 03:31:26 am Andreas Mohr wrote:
> Possibly the kernel's control key state got stuck in a weird state,
> perhaps due to some input layer race conditions or so.
>
> Or is it X.org's input handling which is responsible for Ctrl-Alt-F1
> etc. combos? I wouldn't think so...

X is solely responsible for handling input when active. It switches
console in RAW mode which bypasses kernel processing) and does it's
own thing. This includes switching VTs upon Ctrl-ALt-Fx.

-- 
Dmitry

Re: 2.6.31-rc6 (yeah, I know...): weird tty / X.org state currently

[Andreas Mohr]

Hi,

On Thu, Sep 10, 2009 at 09:25:00AM -0700, Dmitry Torokhov wrote:
> On Thursday 10 September 2009 03:31:26 am Andreas Mohr wrote:
> > Possibly the kernel's control key state got stuck in a weird state,
> > perhaps due to some input layer race conditions or so.
> >
> > Or is it X.org's input handling which is responsible for Ctrl-Alt-F1
> > etc. combos? I wouldn't think so...
> 
> X is solely responsible for handling input when active. It switches
> console in RAW mode which bypasses kernel processing) and does it's
> own thing. This includes switching VTs upon Ctrl-ALt-Fx.

OK, but what's puzzling is that there's no indication whatsoever that
there's any broken Ctrl activity (neither in konsole nor in a tty),
yet the tty gets switched readily as soon as only Alt-Fx gets pressed in
X.org. 

IOW (unless that's wrong) you're saying that it's X.org which has
a broken Ctrl key state (but solely when doing the Alt-Fx switch,
_not_ when doing Ctrl-L or regular letter input), not the kernel.

If so, would this problem warrant notifying X.org upstream,
or is it likely to be fixed in newer X.org releases?

Andreas Mohr

Re: 2.6.31-rc6 (yeah, I know...): weird tty / X.org state currently

[Dmitry Torokhov]

On Thursday 10 September 2009 09:42:32 am Andreas Mohr wrote:
> Hi,
>
> On Thu, Sep 10, 2009 at 09:25:00AM -0700, Dmitry Torokhov wrote:
> > On Thursday 10 September 2009 03:31:26 am Andreas Mohr wrote:
> > > Possibly the kernel's control key state got stuck in a weird state,
> > > perhaps due to some input layer race conditions or so.
> > >
> > > Or is it X.org's input handling which is responsible for Ctrl-Alt-F1
> > > etc. combos? I wouldn't think so...
> >
> > X is solely responsible for handling input when active. It switches
> > console in RAW mode which bypasses kernel processing) and does it's
> > own thing. This includes switching VTs upon Ctrl-ALt-Fx.
>
> OK, but what's puzzling is that there's no indication whatsoever that
> there's any broken Ctrl activity (neither in konsole nor in a tty),
> yet the tty gets switched readily as soon as only Alt-Fx gets pressed in
> X.org.
>
> IOW (unless that's wrong) you're saying that it's X.org which has
> a broken Ctrl key state (but solely when doing the Alt-Fx switch,
> _not_ when doing Ctrl-L or regular letter input), not the kernel.
>
> If so, would this problem warrant notifying X.org upstream,
> or is it likely to be fixed in newer X.org releases?

I don't follow X development unfortunately but I think it is a good
idea to ask there.

-- 
Dmitry