l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: User sessions, system request


From: Valerio Bellizzomi
Subject: Re[2]: User sessions, system request
Date: Wed, 30 Jan 2008 21:41:43 +0100

On 30/01/2008, at 14.42, Jonathan S. Shapiro wrote:

>On Wed, 2008-01-30 at 18:30 +0100, Bas Wijnen wrote:
>> Right.  But my keyboard driver is working around all cleverness of
>> keyboards anyway.  It sends exactly one event for each make or break
>> that happens.  Fake shifts are removed, prefixes are interpreted (and
>> merged with the actual events), key repeat is ignored.
>
>This will break a small number of programs, but they turn out to be
>depressingly important programs.
>
>> However, by requiring users to first press Alt before they are able to
>> press SysReq, the application can get some information that it
shouldn't
>> have.  That's why I want it to be a single key, not a combination.
>
>Understood. Interposing a state machine in the way that I suggested
>would also resolve this.
>
>> > Even if ALT is required, there is a fairly "simple" solution: inject
a
>> > low-level keyboard driver that captures key code sequences from the
>> > keyboard.
>> 
>> This won't work: I want programs to instantly see any key that is
>> pressed, if they're allowed to see it.  If you want to capture it,
you'd
>> need to delay sending of the Alt make code until another key is
pressed,
>> or until it is released, or until some arbitrary time has expired(?).
>
>This is not an issue. The state machine only runs for one full keypress.
>ALT-SysReq is a single keypress. The application cannot tell if the
>individual code points have been delayed.
>
>If you are converting everything into canonical code points, you are
>already running the state machine that you need.
>
>>   I
>> don't think this is acceptable.  Say I want to use Alt as one of the
>> controls in a game.  This delay would make it unplayable.  Break is
>> unuable for this anyway, because it doesn't generate an event when it
is
>> released.
>
>Agreed. That is a good reason to use "bare" SysRq rather than ALT-SysRq
>as your system attention key. The *purpose* of SysRq was to serve as the
>system attention key.

The purpose of SysRq key alone, was exactly to serve as the system
attention key in order to get a trusted login prompt. Originally ALT was
not required, SysRq generates a trap.

val
        





reply via email to

[Prev in Thread] Current Thread [Next in Thread]