[Top][All Lists]
[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
- User sessions, system request, Bas Wijnen, 2008/01/18
- Re: User sessions, system request, olafBuddenhagen, 2008/01/30
- Re: User sessions, system request, Jonathan S. Shapiro, 2008/01/30
- Re: User sessions, system request, Bas Wijnen, 2008/01/30
- Re: User sessions, system request, Jonathan S. Shapiro, 2008/01/30
- Re[2]: User sessions, system request,
Valerio Bellizzomi <=
- Re: Re[2]: User sessions, system request, Jonathan S. Shapiro, 2008/01/31
- Re: User sessions, system request, Bas Wijnen, 2008/01/30
- Re: User sessions, system request, Jonathan S. Shapiro, 2008/01/31
- Re: User sessions, system request, Neal H. Walfield, 2008/01/31
- Re: User sessions, system request, Bas Wijnen, 2008/01/31
Re: User sessions, system request, Jonathan S. Shapiro, 2008/01/30