Messages in this thread | | | Subject | BUG: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6] | From | Sau Dan Lee <> | Date | 01 Jun 2004 10:21:16 +0200 |
| |
Andries> Sau Dan Lee wrote:
>> Actually, I have a side issue with input/i8042 related things: >> The keyboard on my laptop worked slightly different: On 2.4.*, >> SysRq is activated using a [Fn] key-combo, which agrees with >> the keycap labels on the laptop keyboard. After upgrading to >> 2.6, that key-combo no longer works. Instead, I must use >> Alt-PrintScreen as the key for SysRq. (And unfortunately, >> PrintScreen is a [Fn] combo on the laptop, thus requiring press >> 3 keys at the same time for SysRq, and a fourth key to use the >> various SysRq features. Very inconvenient.) Is this again due >> to some dirty translation processes down in the input layer? >> Is the input layer always assuming that Alt-PrintScreen == >> SysRq? This is not always true. Can the input layer be so >> configured that it never tries to interpret the scancodes, but >> pass them to the upper layers?
Andries> So, what scancodes do you get in 2.4? And in 2.6? (Use Andries> scancode -s.)
Here they are:
On Linux 2.4.*: PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa SysRq: 0x54 0xd4
On Linux 2.6.*: PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa SysRq: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
No wonder: "showkey -s" in 2.6.* is deceiving: it shows what an emulated keyboard generates, not the *real* scancodes. Fortunately, the SERIO_USERDEV patch is very very helpful here.
Using the SERIO_USERDEV patch from Tuukka Toivonen and me, the correct scancodes are displayed:
On Linux 2.6.*: od -t x1 /dev/misc/isa0060/serio0 PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa SysRq: 0x54 0xd4
So, obviously, it is the fault of the Linux 2.6.* keyboard driver.
The story continues:
I've studied the 2.6 keyboard driver atkbd.c and found the bug: The keyboard driver is UNABLE to distinguish SysRq and PrintScreen!!! I've checked this with the help of the 'evbug' module. The driver reports both keys to be KEY_SYSRQ, which is obviously wrong.
I've got a patch for this bug already. See Bugzilla #2808.
Relatedly, drivers/char/keyboard.c assumes that SysRq cannot be activated unless the Alt key(s) is/are pressed (and not yet released). I'm going to fix this. But since this not a module, I need to reboot to test it. So, please be patient.
See http://bugzilla.kernel.org/show_bug.cgi?id=2808 for more info.
-- Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |