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 [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
