On Thu, Nov 14, 2002 at 03:23:54PM +0100, Sven Neumann wrote: > Hi, Hi Sven,
> [EMAIL PROTECTED] writes:
>
> > It simply reads from the lirc fd and then calls lirc_parse_line() to
> > extract the key that was pressed and then queues up a DIET_KEYPRESS
> > immediately followed by a DIET_KEYRELEASE, with no check in there for
> > a key repeat (i.e. a held key).
>
> that doesn't look right.
No, it doesn't. But that's probably because this is not an easy
problem to solve. Unlike keyboards (which have a hardware
key release event), the LIRC protocol does not provide a "key release"
event that can be used to send key_release events to DirectFB apps.
The only way to determine a key release is by comparing the counter of
the current key press to the previous one. LIRC reports a counter with
the key event that resets to zero when the key is (determined to be)
released.
So in order for DirectFB to determine if a key on the remote was
released, it has to wait for the next key press event from LIRC and
see if the counter is 0 (assuming it was not 0 on the last key press
event). It is only at that time that a key_release event can be
triggered.
This of course means that the last key_release event will always be
delayed (up to several days for instance, if I hold a key down then
release it and then put the remote down for several days) beyond what
it is in reality.
So, if the application developer has to deal with handling keys being
held down at the application layer, how does he possibly do it
properly/easily when events are not being delivered as they happen?
Of course this ultimately is a shortcoming of LIRC but I think that
DirectFB should deal with this shortcoming until better event
reporting comes from LIRC. Pushing this problem up to all of the
application developers just does not make sense. We will all be
implementing the same kinds of ugly hacks as this:
gboolean on_key_press_event (GtkWidget *widget,
GdkEventKey *event,
gpointer user_data)
{
static guint32 last_time;
if (event->time - last_time < 200 || mplaying) {
// discard it
return TRUE;
}
last_time = event->time;
return FALSE;
}
and hooking them into the keypress events of all of the toplevel
widgets of our applications.
> you can't use a global variable here since the driver might be opened
> several times. Instaed you should add the boolean variable to the
> driver data struct.
No, I knew I couldn't but hacking at the wee hours of the morning
caused me to focus entirely too much on how to return the status in
the return value and not even consider returning it in a passed
parameter. It was also, indirectly a question as to what data
structure I should put it in. :-)
b.
--
Brian J. Murrell
msg01065/pgp00000.pgp
Description: PGP signature
