SYSRQ...(part2)

[Mike A. Harris]

On Mon, 24 Jan 2000, willy tarreau wrote:

>> No, I've finally isolated the problem.  My SYSRQ key
>> generates
>> the make and break codes one after the other without
>> waiting for
>> the release.  In other words, when I press SYSRQ, it
>> sends:
>> 
>> 0x54 0xd4
>
>are you really sure 0xd4 is sent before any other
>keyboard event (key press and/or release) ? I mean
>that
>if you press alt + sysrq, and hold them down, do the
>0x54 code repeat alone, doesn't it repeat, or do the
>0x54/0xd4 codes do flip-flop ?

The split second that SYSRQ is pressed, while ALT is held down,
the keyboard sends both codes:

0x54 0xd4

Absolutely nothing prevents this, no matter how hard or soft the
key is pressed or not.  Holding down the SYSRQ key does not
repeat anything at all.  If I press ALT, and then press SYSRQ,
and hold both down I get:

0x38
0x54 0xd4

Continuing to hold both down, nothing else appears.  If I press
other keys, they appear, but nothing else appears from SYSRQ.  It
is very apparent to me that my keyboard's behaviour is relatively
broken.  All I can do is modify the keyboard.c to handle my
keyboard, or use another keyboard at this point.


>> Yes, I am going to have to modify the code which
>> activates SYSRQ.
>> It cannot just be a simple key replacement however
>> because SYSRQ
>> key is the only key with a unique code when ALT is
>> held down...
>
>no, hopefully there are other keys such as shift, caps
>lock, numlock. What about Alt+CapsLock ? this
>combination is never used anywhere. Capslock sends
>0x3a.

Ah, but you don't understand...  SYSRQ is a unique code that only
appears while ALT is held down.  If you press the PRINT_SCREEN
key without ALT held down, the keycode is completely different.
Thus the ONLY way you ever see the 0x54 SYSRQ code is while ALT
is held down.  No other key on the keyboard functions in this
manner that I am aware of.  If you choose any other key on the
keyboard, it will generate SYSRQ *ALL THE TIME* regardless of
ALT.

So changing SYSRQ to 0x3a would effectively disable capslock, and
leave a dangerous key on the keyboard. ALT need not be pressed
because the code generated by capslock is 0x3a regardless of ALT
or not, whereas the SYSRQ key generates 0x54 ONLY when the ALT
key is held down.

Talk about odd hardware features eh?

>also try to use Right Alt (Alt GR) instead of left
>alt.
>Mine generates E0 38 instead of 38 alone, and is fully
>compatible with SysRQ. Perhaps your SYSRQ will stop
>sending release codes with this key pressed.

No, my R-ALT key is the same as yours.  The thing that makes
SYSRQ special is that the physical key itself generates 2
different codes.  When that key is pressed alone without any keys
held down it generates:

0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa

The first 4 are the make code for PRINTSCREEN and the latter 4
are the break codes.  On my keyboard it generates the make and
break codes simultaneously regardless of wether you release the
key or not.

If you hold ALT or RALT down, you do not get that code, rather
you get the SYSRQ code 0x54 0xd4 with both make and break sent
simultaneously - also broken.

Every other key on the keyboard sends a single code regardless of
wether another key is pressed down or not.  This is what makes
SYSRQ unique.

So... since my keyboard is broken and sends the make and break
codes for PRINT_SCREEN and SYSRQ simultaneously, the only way to
fix it is to recode the keyboard handler to work with my
keyboard and its screwed up SYSRQ key, or else to recode it to
use some other combination.  Unfortunately if I choose a single
keycode, I'll have a dangerous live key on my keyboard that
activates SYSRQ without any modifiers being pressed.  As such,
I'll have to hack up some convoluted keystroke that is unlikely
to ever get pressed during usage such as LALT-RSHIFT-ESC-ENTER or
something like that...


>> So, I need some obscure impossible to do
>> accidentally combo like
>> you described above.  I just need to determine how
>> to do it in
>> the kernel source without screwing my kernel up. 
>> ;o)
>
>try it inside vmware on a boot floppy with just your
>kernel, it works really fine, but you'll never see how
>your keyboard behaves until you give it a real run ;-)

Yes, I'll have to get a new VMware licence key, but that is
definitely the way to test my changes.

Thanks for your suggestions,
TTYL

--
Mike A. Harris                                     Linux advocate     
Computer Consultant                                  GNU advocate  
Capslock Consulting                          Open Source advocate

Join the FreeMWare project - the goal to produce a FREE program in
which you can run Windows 95/98/NT, and other operating systems.

                    http://www.freemware.org


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/