Re: [patch] Re: Magic Alt-SysRq change in 2.6.18-rc1

Dmitry Torokhov
2006-07-13T18:48:16Z

On 7/12/06, Paulo Marques <pmarques@grupopie.com> wrote:
> >
> > We also need to check if emulate_raw() needs to be adjusted...
>
> I looked at that very quickly, to be honest, but couldn't understand it
> entirely. This code:
>
> 1087 if (keycode == KEY_SYSRQ && sysrq_alt) {
> 1088 put_queue(vc, 0x54 | up_flag);
> 1089 return 0;
> 1090 }
>
> seems to be supposed to cancel the Alt "press" by sending a Alt
> "release" to handle the sequence press alt -> press sysrq without
> affecting the application. However, this is just a guess. I couldn't
> find out what that magic 0x54 meant or why this would be enough wether
> we pressed the left or the right alt...
>

Real AT keyboards (that's what we are trying to emulate here) send
0x54 scancode (and 0xB4 break code) if PrintScreen/SysRq key is
pressed while holding Alt (left or right). Otherwise it sends e0 2a e0
37. That's it.

> Then there are other things that I don't understand there: I don't see
> any code to filter out the keys we press ('T','P', etc.) while using
> SysRq magic if we are in raw mode. emulate_raw will happily call
> put_queue on them before we have a chance to bail out.
>
> Maybe we should just stop calling emulate_raw while sysrq_active is
> active. This way, after we press Alt + SysRq, every keypress would be
> processed as a magic sysrq and not handled by any other code until we
> release both keys.

We never supressed sysrq scancodes from reaching userspace if keyboard
is in raw mode (2.4 works the same). Plus you won't be able to supress
it for keyboards working in hadware raw mode (kbd_rawcode is called
even before we get to detecting SysRq state). Also users getting
keyboard events from alternative interfaces (such as evdev) won't be
affected anyway so I think we shoudl leave it as is.

--
Dmitry