Re: sysrq filter and stuck keys [ was Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.]

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Wed, 2010-10-20 at 11:01 -0500, Jason Wessel wrote:
> On 10/13/2010 09:34 PM, Maxim Levitsky wrote:
> >
> > Nope, still same problem.
> > Maybe more keys were released, but still
> > pressing Alt+SysRQ+g second time doesn't break to the debugger.
> >
> >   
> 
> Thanks for trying this out Maxim.
> 
> I have to wonder if part of the problem is the way that raw events can
> propagate directly via the old keyboard interface vs the input layer.  
> I had noticed something somewhat similar with an xorg.conf which
> appeared to be using both the raw keyboard and the input layer for
> input.  I was having all sorts of problems until I changed the xorg.conf
> settings to use the input layer.  I noticed that even pressing the up
> arrow in an xterm was invoking the screen shot mechanism for example.
> 
> Perhaps you can provide some more data to see if this is a similar
> problem or not.

Jardon, I already found the root cause of the problem.
First of all, note that I use xorg's evdev driver.
The in-kernel tty kbd driver is only used for virtual consoles.

The root cause is that in-kernel kbd driver beeing a client of the input
subsystem just doesn't see the sysrq keys because they are filtered,
therefore it can't release them.

The right solution is to somehow hook at the atkbd driver , tell it that
kbd tampered with its hardware, and make it release the keys.

But that is easy to say, not that easy to do...

the in-kernel kbd driver just isn't the right place for the job.

Best regards,
	Maxim Levitsky