>>>>> "bugme-daemon" == bugme-daemon <[email protected]> writes:
bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808
bugme-daemon> [email protected] 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?
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.
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?
Vojtech> and is used for the PrtScr/SysRq key.
So, why not have seperate keycodes for the two?
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Tue, Jun 01, 2004 at 11:44:44AM +0200, Sau Dan Lee wrote:
> >>>>> "bugme-daemon" == bugme-daemon <[email protected]> writes:
>
> bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808
> bugme-daemon> [email protected] 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
>>>>> "Vojtech" == Vojtech Pavlik <[email protected]> writes:
>> Isn't the keyboard driver supposed to iron out such
>> differences?
Vojtech> The atkbd.c driver does exactly that. It hides the fact
Vojtech> that there is a special scancode for the PrintScreen key,
Vojtech> if you press it together with some other keys.
No, it doesn't do that. I press PrintScreen (without Alt) and it
tells the input system that it is a KEY_SYSRQ.
Vojtech> It's a hack by IBM engineers, the PC/XT keyboard had a
Vojtech> SysRq key, the PC/AT keyboard did not, yet some old DOS
Vojtech> programs needed it, so they made the AT keyboard generate
Vojtech> the keycode for alt-sysrq when running in XT
Vojtech> compatibility mode.
It's a simple SysRq (0x54), not Alt-SysRq (0x38 0x54) in my notebook.
Vojtech> Unfortunately, the XT compatibility mode stuck, and
Vojtech> that's what we're using now.
I know this part of the history, and hence why PrintScreen is emulated
by Alt-KPAsterisk.
Vojtech> The kernel works with real keys. There is no real sysrq
Vojtech> key.
On my notebook, there IS a real SysRq. (The [Fn] part is not visible
to the kernel. So, that's irrelevant.)
Vojtech> Ok, it's probably a bad name for it, it should have been
Vojtech> named KEY_PRTSCR, but it wasn't, and it'd only cause
Vojtech> breakage now to change it.
Deprecate the old one.
Vojtech> and is used for the PrtScr/SysRq key.
>> So, why not have seperate keycodes for the two?
Vojtech> Because there is only one key.
On some keyboards (e.g. my notebook), they're separate. Is that
enough a reason to have 2 different keycodes, then?
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
Vojtech Pavlik wrote:
> 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.
My keyboard has a separate key for SysRq (as much as
'separate' makes sense for laptop keyboards; it's a Fn-
activated key).
If you want to go the route you're going, all laptop keyboards
should have the numeric keypad produce the same emulated
scancodes as some alphanumeric keys. This does sound a little,
uhm, ridiculous to me.
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)