New commits:
http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=1256b2e30e24231fc7d04b3395f8c05d6e17fefa
commit 1256b2e30e24231fc7d04b3395f8c05d6e17fefa
Author: Jon Pomrenke <[email protected]>
Date: Tue Jan 17 20:36:54 2012 +0200
vt_flush_thread flushing first key press
The first key press after DirectFB initialization is always discarded.
The behavior is new in 1.4-0 and I believe comes from the following
changeset:
commit e0be70ec8aedde56f23d216530746a93e7746ff6
Author: Ville Syrjala <[email protected]>
Date: Tue May 12 04:16:57 2009 +0300
vt/keyboard: Flush console input when not used
To keep the kernel happy the console buffer must be kept from filling
up. If the buffer is sufficiently full the kernel stop sleeping and
instead wakes up every tick to do something. This problem occurs when
the keyboard driver is not used and the linuxinput driver does not grab
the devices. Add a new thread whose job is to keep flushing the buffer
when the keyboard driver is not there to consume the data.
I have traced the issue to vt.c::vt_flush_thread() calling select().
keyboard.c::driver_open_device() sets dfb_vt->flush to false but
vt_flush_thread() will not exit until the first key press. As
vt_flush_thread() exits, it makes one final call to tcflush() and discards
the unread input.
Here is a brief excerpt of my console output, demonstrating that the first
input is a key release, rather than a key press.
(*) Direct/Thread: Started 'VT Flusher' (831) [DEFAULT OTHER/OTHER 0/0]
<2093056>...
(*) Direct/Thread: Started 'Keyboard Input' (832) [INPUT OTHER/OTHER 0/0]
<2093056>...
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
waiting for event
got key_id= 63043key released
waiting for event
got key_id= 63043key pressed
waiting for event
got key_id= 63043key released
systems/fbdev/vt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
_______________________________________________
directfb-cvs mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-cvs
