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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
