Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > 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.
As DirectFB input drivers have an own thread we could just do a select or poll with a timeout to deliver the release event. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
