[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

at_keyboard and checkkey()

From: Robert Millan
Subject: at_keyboard and checkkey()
Date: Mon, 21 Sep 2009 22:19:49 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


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

Attachment: at_keyboard_queue.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]