Re: [PATCH] Detect key modifier status in 'sleep --interruptible'

[Robert Millan <rmh@aybabtu.com>]

On Wed, Aug 26, 2009 at 09:26:06PM +0100, Colin Watson wrote:
> > 
> > I'm still not convinced that we want the sleep bits.  They seem too ad-hoc,
> > and I'd like to hear what others think first.
> > 
> > But if I understood correctly, you plan on using keystatus command only?
> 
> If GRUB_HIDDEN_TIMEOUT is set to a non-zero value, I would use sleep
> rather than keystatus, I think. (At least, if I decided I wanted to
> support that configuration; I'm not quite sure yet.) In that case I'd
> want the sleep to be interruptible by pressing Shift for consistency
> with the zero-delay case.
> 
> However, since this is essentially an artifact of our configuration and
> doesn't introduce any new configuration file words, I could keep this
> part as an Ubuntu-specific patch with relatively little trouble.

Please do for now.  I'd rather not rush when discussing this part.

> > > +static int
> > > +grub_console_getkeystatus (void)
> > > +{
> > > +  grub_uint8_t status = bios_data_area->keyboard_flag_lower;
> > > +  int mods = 0;
> > > +
> > > +  if (status & 0x03)
> > > +    mods |= GRUB_TERM_STATUS_SHIFT;
> > > +  if (status & 0x04)
> > > +    mods |= GRUB_TERM_STATUS_CTRL;
> > > +  if (status & 0x08)
> > > +    mods |= GRUB_TERM_STATUS_ALT;
> > > +
> > > +  return mods;
> > > +}
> > 
> > This should be macroified (but for the time being, I have no problem with
> > our internal representation matching the one in BIOS Data Area, hence no
> > translation would be needed on i386-pc).
> 
> Vladimir objected to the inconsistency between distinguishing left and
> right Shift but not left and right Control or Alt, which is why our
> internal representation does not currently match. I agree it's clearer
> to macroify things.

Looks fine now, thanks.

> OK, and doing so helped me notice that I'd left a Get_Idle request in
> there by mistake from debugging. Updated patch follows. There are a few
> changes unrelated to the main body of the patch as a result; do you want
> these split out?

No need, this looks good.  Please commit.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."