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

[Jason Wessel <jason.wessel@windriver.com>]

On 10/22/2010 09:29 PM, Maxim Levitsky wrote:
> Jason, 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.
>
>   

I would like to clarify where you observed the problem.  Was it only on
the tty console in X or both places?

> 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.
>
>   

With the 3 patches to the input layer in kgdb-next I cannot duplicate
the problem at all.  If I remove the last patch in the series, and use
the tty console, I can definitely see the behavior you mention.  I had
added a change to the sysrq input filter (which is consumes the key
strokes) that also resets the key mask in the tty keyboard driver

Specifically in

+                       /* Clear handled keys from being flagged as a
repeated stroke */
+                       __clear_bit(code, handle->dev->key);


Else drivers that use these bits for autorepeat (like the atkbd driver)
will end up with stuck keys.

> 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.
>
>   

I don't think we need to do that because the input filter should be able
to actually "properly" filter state to all its clients.  As a last
resort of course the HW state could be tracked and updated, but ideally
I'd like to avoid it.

Jason.