| | [ Return to Bugs & Features | Roadmap 2.0 | SVN ⇄ GIT ]
STR #2232
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | X11 |
|---|
| Summary: | FLTK1/2 X11 keyboard handling broken if using a soft keyboard |
|---|
| Version: | 2.0-current |
|---|
| Created By: | dkogan |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 2.0-current |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | dkogan
00:32 Aug 05, 2009 |
| I'm seeing a problem with the low-level keyboard handling in both
FLTK1 and FLTK2. If using a program that artificially generates
X11 keystrokes to type any word with non-consecutive, repeated
letters into an FLTK app, FLTK transposes the letters. An example
of such a keystroke-generating application is a soft keyboard,
such as those used on touchscreen phones. A keyboard that uses a
dictionary to type a word-at-a-time types the letters in a quick
succession, triggering this bug. I'm attaching 2 test programs to
demonstrate the issue, one in C and another in Perl. Both use
XTest to type "morning" (assuming a "standard" keyboard). This
works fine when typing into an app not built with FLTK, but FLTK
often produces "mornnig" instead. This is sensitive to timing, so
the bug doesn't occur 100% of the time, but quite often on my
computer.
The cause of the issue is code in FLTK to handle key
repeats. When a key is held down, X sends repeated press and
release events. FLTK fights this by looking into the X event
queue to detect this condition, and to pull out press events to
process them earlier. Thus, the second "n" in "morning" moves up
in the queue to produce the error. In FLTK1, this behavior was
introduced in revision 2937 (this revision has no other
changes). In FLTK2, almost-identical behavior was introduced in
revision 2944.
I must admit I don't understand why FLTK doesn't want to handle
repeated press and release events that X generates. A quick test
with that code pulled out didn't reveal any breakage, but I
didn't try for very long. We can pull out this code permanently
if the issue no longer exists (the code was written in
2003). Otherwise, we can make fake_keyup_test() smarter by
preventing it from triggering if different keys are seen in the
queue in-between the repeating keys. | |
| |
| #2 | matt
15:32 Sep 23, 2009 |
| Interesting. I am sure a specific X11 client has caused this issue. I have no idea why it was important to differentiate a repeat from a press/release/press cycle, but Mike may clear this up.
The code is basically OK and checks the even time as well, but in rare case (in particular, if keyboard input does not come from a human, but is generated by a program), time resolution may not be enough.
I do not see a way to keep the patch and solve the new problem in the same code. Maybe Mike can explain why this was needed (and if we can remove it). | |
| |
| #3 | dkogan
22:10 Sep 24, 2009 |
| I discovered that an identical bug existed in QT until very recently. Maybe this will help shed light on the original reasoning:
http://lists.trolltech.com/qt-interest/2008-10/thread00773-0.html | |
| |
| #4 | dkogan
18:31 Dec 12, 2009 |
| For completeness, i just posted patches (for fltk 1.3 and 2.0) to disable the queue-modifying behavior that causes the above-described bug | |
| |
| #5 | matt
03:34 Dec 13, 2009 |
| It gets worse. So the bogus KeyUp events are a well known bug that was introduced into X11 some twelve years ago. In order to avoid backward compatibility issues, a new function was introduced:
Bool XkbSetDetectableAutorepeat ( display, detectable, supported_rtrn )
Display * display ;
Bool detectable ;
Bool * supported_rtrn ;
Calling this is supposed to switch off the bogus events, so the workaround that we (and many many others) used is not required anymore. Great so far, but now, this particular call used a side effect on many current X Servers. This side effect was recently eliminated, so many for many Unix releases (Ubuntu, Solaris, and others), the above call is broken, causing even more confusion and failed code.
Applying the above patches will break every program that uses FLTK with game style key keyboard handling. Not applying it will break soft keyboard support. *** SIGH ***. | |
| |
| #6 | matt
04:01 Dec 13, 2009 |
| OK, I just committed a fix that will hopefully solve both issues. Please verify that this is functional, so I can close this bug. I don't have an X11 machine, so I can not event verify that the syntax is correct. | |
| |
| #7 | AlbrechtS
05:27 Dec 13, 2009 |
| I can confirm that it's syntactically correct, I just compiled it on ubuntu 9.04. However, I can't test if it solves the problem.
One thing I tested though: in test/editor key repetitions seem to work as they should, so there seems to be no regression for normal key handling at least. | |
| |
| #8 | dkogan
12:19 Dec 13, 2009 |
| Matt, I just tested the updated fltk1.3, and it seems to work with the "type morning" script attached to this bug, so softkeyboard support is fixed. Thanks. I didn't try with any games since I don't know what to look for. Could you also apply a similar change to fltk2? I'm attaching a patch that does this. | |
| |
| #9 | bgbnbigben
23:59 Feb 04, 2011 |
| Tested this under FLTK2 and the bug no longer exists - Matt, it looks like you fixed this a while back.
Since this was your fix, are you happy if this STR is closed? | |
| |
| #10 | bgbnbigben
23:03 Feb 14, 2011 |
| Fixed in Subversion repository.
I'll close this STR on Matt's behalf - Matt, if you see any problems cropping up, feel free to re-open this, but otherwise this has been solved, from my own tests. | |
[ Return to Bugs & Features ]
|
| |
