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

[Vojtech Pavlik]

On Tue, Jun 01, 2004 at 11:44:44AM +0200, Sau Dan Lee wrote:
> >>>>> "bugme-daemon" == bugme-daemon  <bugme-daemon@xxxxxxxx> writes:
> 
>     bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808
>     bugme-daemon> vojtech@xxxxxxx changed:
> 
>     bugme-daemon>    What    |Removed             |Added
>     bugme-daemon> ----------------------------------------------------
>     bugme-daemon>      Status|NEW                 |REJECTED
>     bugme-daemon>  Resolution|                    |INVALID
> 
>     Vojtech> I'm sorry you can't use the fn+printscreen function on
>     Vojtech> your LifeBook, but such is life. 
> 
> Disappointed.
> 
>     Vojtech> Is using Alt+printscreen such a big difference?
> 
> That means I need to press FOUR keys to use sysrq, because PrintScreen
> is  only  available via  [Fn].   That becomes  [Fn]+Alt+PrintScreen+X,
> where "X" is the sysrq function.  :(
> 
> 
>     Vojtech> On USB keyboards (and many others, too), there is no
>     Vojtech> specific SysRq keycode, and thus the kernel magic-sysrq
>     Vojtech> handler uses the alt-printscreen combination, to make it
>     Vojtech> work on ALL keyboards. This is intentional.
> 
> Isn't  the keyboard  driver  supposed to  iron  out such  differences?

The atkbd.c driver does exactly that. It hides the fact that there is a
special scancode for the PrintScreen key, if you press it together with
some other keys.

There is no special scancode on any other keyboard type for it,
including PS/2 keyboards in their native Set3 mode.

It's a hack by IBM engineers, the PC/XT keyboard had a SysRq key, the
PC/AT keyboard did not, yet some old DOS programs needed it, so they
made the AT keyboard generate the keycode for alt-sysrq when running in
XT compatibility mode.

Unfortunately, the XT compatibility mode stuck, and that's what we're
using now.

> Isn't  it your  philosophy that  the drivers  should know  the devices
> well, and present  a consistent interface to the  upper layers?  Then,
> the correct way to do it is:
> 
>         USB keyboard driver: generate a "sysrq" event in reaction to
>                              Alt-PrintScreen 
>         AT/PS2 keyboard driver: generate a "sysrq" when receiving a
>                                 0x54 keycode
> 
> The  kernel  keyboard  handler  shouldn't  see  or  bother  about  the
> difference.   It is  insane that  the handler  has to  care  about the
> status of the Alt keys.

The kernel works with real keys. There is no real sysrq key. My
definition of sanity is to base your thinking on reality where possible.

>     Vojtech> Further, keycode 99 is KEY_SYSRQ, as defined in input.h,
> 
> Then, why use it for PrintScreen?   With the 'evbug' facility, I see a
> keyboard  event with code  KEY_SYSRQ when  I press  PrintScreen.  Just
> PrintScreen, not  Alt-PrintScreen.  So,  this is a  feature and  not a
> bug?

Ok, it's probably a bad name for it, it should have been named
KEY_PRTSCR, but it wasn't, and it'd only cause breakage now to change
it.

>     Vojtech> and is used for the PrtScr/SysRq key. 
> 
> So, why not have seperate keycodes for the two?
 
Because there is only one key.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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/