Messages in this thread | | | Date | Tue, 1 Jun 2004 11:55:18 +0200 | From | Vojtech Pavlik <> | Subject | Re: BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6] |
| |
On Tue, Jun 01, 2004 at 11:44:44AM +0200, Sau Dan Lee wrote: > >>>>> "bugme-daemon" == bugme-daemon <bugme-daemon@osdl.org> writes: > > bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808 > bugme-daemon> vojtech@suse.cz 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |