Re: [PATCH] make 'sleep --interruptible 0' interruptible

[Colin Watson]

On Mon, Jan 25, 2010 at 08:55:33AM +0100, Robert Millan wrote:
> On Wed, Jan 20, 2010 at 10:50:25PM +0100, Szymon Janc wrote:
> > Colin Watson wrote:
> > > On the PC architecture, you can't check for Escape without having some
> > > kind of delay.  Only modifier keys can be checked instantaneously.
> > > 
> > > http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/grub2/lucid/annot
> > > ate/head%3A/debian/patches/951_sleep_shift.diff has an alternative patch
> > >  which may be helpful, and links to previous discussions.
> > 
> > Hmm now I see that this trivial case is no so trivial at all. Yet it would 
> > be 
> > nice to have unified sollution for GRUB_HIDDEN_TIMEOUT.
> > 
> > Maybe extra command especially for user interactivity? It would combine 
> > functionality of sleep and keystatus without need to worry about 
> > restrictions 
> > mentioned in previous discussion.
> > I know that this is somewhat redundant but it looks like it would be very 
> > hard 
> > for 'clean' solution.
> 
> We're going to migrate to hardware drivers (at_keyboard / usb_keyboard) in the
> near future.  I guess this resolves the stated problem, so I wouldn't invest a
> lot of effort in finding other solutions to it.

If anything, at_keyboard currently makes the problem worse.

The reason we can tell instantaneously whether a modifier key is held
down is that the BIOS remembers that state and exposes it in a magic
memory location.  For other keys, we just get make and break keycodes
when those keys are pressed and released respectively.  at_keyboard
deals with modifiers by tracking make and break keycodes, but this does
not cope with the case where a modifier key was held down when GRUB
starts.  In the case of a very short timeout, it is much more common for
a modifier key to be already held down when GRUB starts (i.e. user
presses the power button and then leans on Shift until something
happens), rather than the user managing to press the modifier key in
just the right window of time.

I think that, on BIOS systems, at_keyboard should "import" the state of
modifier keys from the BIOS when it starts up, and then track make and
break keycodes from then on.  That would deal with the regression from
the BIOS-based driver, at the cost of reintroducing a small dependency
on the BIOS (but it would just be at startup time and would consist only
of checking a memory location).

Either way, it's still not possible to check for non-modifier keys
without having some kind of delay, since the BIOS hasn't tracked those
keys from system startup for us, so the stated problem still stands.  As
far as I know, this problem is simply insoluble in GRUB on BIOS-based
systems.  (The problem isn't unique to BIOS either.)

-- 
Colin Watson                                       address@hidden