On Sat, Mar 18, 2000 at 11:22:45PM +0800, Chan Shih-Ping wrote:

> I have come across two USB keyboards that do not generate 
> the scancode 0x54 (== default SYSRQ_KEY) with Alt-PrtSc (SysRq).
> These are a SGI USB keyboard and the Microsoft USB Natural keyboard.
> Kind of makes it difficult to get MAGIC_SYSRQ to work.

Well, this is a quirk of the XT emulation layer in the i8042 chip and
the AT keyboards. I forgot about it when writing the AT keyboard
emulation for USB. 

> The SGI keyboard is particularly weird as the key with (numbersign,
> asciitilde) generates 0x54!

This is the '103rd euro key'. This key happens to exist on most
keyboards with euro layouts. The closest equivalent on AT keyboards is
the backslash key, although on USB it has a different code.

> (Scancodes generated by Alt-PrtSc are the scancodes for Alt and PrtSc).
> Is this typical of all USB keyboards??

Yes, this happens on all USB keyboards, the keys generate just the codes
they really are.

> I would like to propose that the SYSRQ_KEY be determined on the fly
> by the sysrq_enabled kernel variable. (After all it is currently only
> used as a on/off flag - by leveraging its actual variable one
> can adapt to different weirdo keyboards without a kernel recompile.)
> 
> Scenario:
> In a default setting:
>       
>       echo "84" > /proc/sys/kernel/sysrq
>       # 84 = keycode of SysRq
> With a USB keyboard without scancode 0x54, switch SYSRQ_KEY to PrtSc
>       echo "99" > /proc/sys/kernel/sysrq
>       # 99 = keycode of PrtSc
> Comments? If this is a viable idea I will submit a patch. 

I think it's easier to adapt the USB code to be closer to real AT
keyboard - it's already emulating it. See my following e-mail for the
patch.

-- 
Vojtech Pavlik
SuSE Labs

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to