BUG: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]

From: Sau Dan Lee
Date: Tue Jun 01 2004 - 03:22:40 EST



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@xxxxxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/