at_keyboard and checkkey()

[Robert Millan]

Hi,

at_keyboard's checkkey() implementation is buggy.  It will flush the
controller's input buffer, but checkkey()'s semantics require that it's
not flushed.  This results in some keys being lost when using at_keyboard.

A proper fix that adjusts to this API is complicated.  I implemented one [1],
only to realize afterwards that maybe this mess isn't really necessary.

A quick check at grub_checkkey() users reveals that none of them care about
the actual key, even if grub_checkkey returns it.  They just want to know
whether there's a key available for read at all.  If we removed this
constraint from the checkkey() semantics, perhaps at_keyboard can get a
checkkey() with less hassle.

However, when at_keyboard reads an event, it needs to determine whether it's
a MAKE (key hit) or BREAK (key unhit) event.  Which AFAICT can't be done
without reading KEYBOARD_REG_DATA.  But maybe I'm missing something.

Any bright ideas?

[1] See attachment.  This made me implement queues as well, perhaps some of
    this can be reused.

-- 
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."

at_keyboard_queue.diff
Description: Text Data