| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3192
| 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: | Keyboard Events Do Not Reach Event Handlers |
|---|
| Version: | 1.3.3 |
|---|
| Created By: | andymandias |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.6 |
|---|
| Fix Commit: | 219ae5e455e7943ffb35fdd5edbe13dcc6955423 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | andymandias
16:59 Feb 17, 2015 |
| This bug occasionally occurs when running a FLTK program that shows multiple windows before Fl::run() under Ubuntu 14.04/14.04.1. There is no apparent cause as to when the buggy behavior appears and when it does not. The problem does not seem to occur, or at least ast no where near the same frequency, under Ubuntu 12.04.5. Reported frequency is roughly 1:15 buggy to regular program launches (or 1:125 when wait_for_expose is called for each window).
After launching the program no keyboard events seem to be passed to any windows or widgets. The keyboard events are recognized by X11, and are visible when a system handler is added through Fl::add_system_handler, but never show up elsewhere. An event dispatch added through Fl::event_dispatch was used to try and find the keyboard events before they are handled by any widget/window, but they do not appear.
I have attached a minimal working example created with the help of chris and Albrecht Schlosser. More discussion at: https://groups.google.com/forum/#!topic/fltkgeneral/VDkbYmuj_Is | |
| |
| #2 | AlbrechtS
06:42 Feb 20, 2015 |
| Status report (short form):
Good news: I found out _what_ causes the problem.
Bad news: I don't know _why_ this happens and I don't know how to fix it.
$ grep -n -2 XFilterEvent src/Fl_x.cxx
1339- fl_xim_activate(xid);
1340-
1341: if (fl_xim_ic && XFilterEvent((XEvent *)&xevent, 0))
1342- return(1);
1343-
When the faulty behavior happens, XFilterEvent() in line #1341 of file src/Fl_x.cxx always returns true, no matter what keys you type. We can't ignore this though, hence all input is ignored and doesn't reach fl_handle() at all.
I have no idea why this happens sometimes. My latest test with ~80 launches showed the buggy behavior in # 6, 38, 40, and 78 (4/80). | |
| |
| #3 | AlbrechtS
06:51 Feb 20, 2015 |
| Test instructions: use the provided test program 'loseskeyboard.cxx' (for easier testing I modified test/input.cxx and ran 'make').
Then, use this (bash) commandline to run the program several times (note that I use ./input in the build directory 'test' or for CMake builds 'bin/examples'):
$ x=0; while true; do let x=x+1; read -p "start[$x]> " temp; ./input; done
This gives you a prompt like:
start[1]>
with increasing numbers (counting the launches).
Now type <Enter> and <Esc>. If the program works as expected, the program is launched on <Enter> and closed when typing <Esc>. If it shows the buggy behavior all input is ignored and you must close it with its close button. | |
| |
| #4 | AlbrechtS
07:27 Feb 20, 2015 |
| The attached patch 'disable_xim.patch' adds an option to disable XIM (X Input Methods) when starting an FLTK program by setting the environment variable 'FL_DISABLE_XIM'. There are three different options:
(1) not defined = standard behavior (XIM enabled)
(2) defined as 'SILENT' = disable XIM silently
(3) defined as anything else = disable XIM with warning on stdout
Unfortunately this is not a solution (only a workaround). I didn't see the faulty behavior when FL_DISABLE_XIM was defined. The drawback is obviously that XIM is disabled by this patch if the env var is set.
The 2nd hunk in the patch "fixes" the issue after program startup, if enabled (no matter if XIM is disabled by the environment variable). In the patch given this code is disabled, but you can enable it by changing
#if 0 // TEST
to
#if 1 // TEST
in line ~1349. This is a bad hack (it was my first attempt and the code was copied from elsewhere), so don't use it verbatim for production code. This disables XIM when it detects the first ignored character, but this is NOT a solution, because it would disable the standard behavior when using XIM to input foreign text (e.g. Japanese).
Please test and confirm that the unmodified patch solves the issue for you (Andy, Chris, whoever else may help). TIA.
We do also need more input on which systems are affected by this behavior (Linux, Unix, which distro, which WM, which XIM used, and so on). I tried to make testing simple (copy one program file, apply one patch) in the hope that more people may help to find the cause. Maybe it is a XIM problem in more recent Linux systems, since this was reported so far:
Ubuntu 14.04: affected (Default setup = Unity + ???)
Ubuntu 12.04: not affected (WM etc. unknown)
Fedora 19: affected (Default setup)
All help (tests on different systems) would be appreciated. Also, devs or others who have more insight in XIM or who may be able to test different XIM servers(?) might help with testing to isolate the cause.
One more note: I saw the bug only when run on the local machine - never when I used a remote X server. | |
| |
| #5 | chris
11:36 Feb 20, 2015 |
| I have tried a suggestion found at http://stackoverflow.com/questions/18246848/get-utf-8-input-with-x11-display to use XSetLocaleModifiers with "@im=none".
With that I cannot see a hangup with the test program.
Not sure what this is doing though...
Anyway here's the change:
Index: src/Fl_x.cxx
===================================================================
--- src/Fl_x.cxx (Revision 10586)
+++ src/Fl_x.cxx (Arbeitskopie)
@@ -670,7 +670,7 @@
if (fl_display) return;
setlocale(LC_CTYPE, "");
- XSetLocaleModifiers("");
+ XSetLocaleModifiers("@im=none");
XSetIOErrorHandler(io_error_handler);
XSetErrorHandler(xerror_handler); | |
| |
| #6 | andymandias
14:51 Feb 20, 2015 |
| To be more specific my results were:
Does not appear on: Ubuntu 12.04.5 with Compiz and X11 1.11.3
Appears on: Ubuntu 14.04.1 with Compiz and X11 1.15.1
Both suggested fixes work for me.
In looking at the man page for XSetLocaleModifiers it says:
"The values for input method are not standardized."
and
"An empty value for a category explicitly specifies the implementation-dependent default."
So, from my ignorant perspective, it seems like it might be proper to use
XSetLocaleModifiers("@im=");
instead of
XSetLocaleModifiers("@im=none");
It seems that XSetLocaleModifiers("@im="); is already used at Fl_x.cxx:1329 as well, so maybe it not being used on Fl_x.cxx:673 was an oversight.
I've attached a revision of Chris's patch with "@im=". | |
| |
| #7 | AlbrechtS
14:54 Feb 20, 2015 |
| Fixed in Subversion repository.
Thanks for the pointer and the patch.
I modified it slightly setting "@im=" which is documented to set the implementation-defined default value.
I was pretty sure that we _had_ set such a "@im=..." string somewhere, and indeed it was in the same file. Hence I believe that setting only "@im=" is the best way.
The docs are not very helpful. Particularly it is not clear why it works sometimes, but sometimes it doesn't.
FWIW: the IM behavior is additionally influenced by the environment variable XMODIFIERS. In my remote X sessions this is undefined, whereas in my Ubuntu 14.04 in local X mode I have:
$ echo $XMODIFIERS
@im=ibus
This _has_ _definitely_ caused the issue! Unsetting XMODIFIERS fixes it, as well as the latest svn version.
Please test and report your XMODIFIERS value (for those who have the issue) and report if it is solved by unsetting XMODIFIERS or setting it to "@im=".
Here is some info on IBus from wikipedia:
IBus has already gained community acceptance, and FreeBSD and many Linux distribution such as Fedora and Ubuntu already have IBus in their package repositories. IBus became the new default input method framework in Fedora 11,[4] and replaced SCIM in Ubuntu 9.10.
http://en.wikipedia.org/wiki/Intelligent_Input_Bus | |
| |
| #8 | AlbrechtS
15:02 Feb 20, 2015 |
| Thanks for your comments, Andrew. Your conclusions and patch are exactly the same as mine. Our comments crossed in time, and the fix is already in svn. | |
| |
| #9 | chris
23:48 Feb 20, 2015 |
| Thanks for fixing - glad that worked out.
Reading up the docs, I wonder if the disabling code at line 1329 should not have always been XSetLocaleModifiers(""), which resets to the system defined value (@im=ibus in case of Ubuntu 14.04). | |
| |
| #10 | chris
04:37 Feb 21, 2015 |
| Sorry, was missreading the code - assumed it wanted to reset the locale modifiers in this line.
What I actually mean is, when no xim can be opened or a fallback to xlib occurs, then the locale modifiers should also be reset to system default. Or doesn't it really matter?
Like that:
Index: src/Fl_x.cxx
===================================================================
--- src/Fl_x.cxx (Revision 10587)
+++ src/Fl_x.cxx (Arbeitskopie)
@@ -597,6 +597,7 @@
}
if (xim_styles && xim_styles->count_styles) {
+ XSetLocaleModifiers("@im=");
fl_new_ic();
} else {
if (xim_warning)
@@ -670,7 +671,6 @@
if (fl_display) return;
setlocale(LC_CTYPE, "");
- XSetLocaleModifiers("@im=");
XSetIOErrorHandler(io_error_handler);
XSetErrorHandler(xerror_handler);
@@ -1326,7 +1326,7 @@
xim_im = XOpenIM(fl_display, NULL, NULL, NULL);
if (!xim_im) {
/* XIM server has crashed */
- XSetLocaleModifiers("@im=");
+ XSetLocaleModifiers("");
fl_xim_im = NULL;
fl_init_xim();
} else { | |
| |
| #11 | AlbrechtS
13:50 Feb 23, 2015 |
| Closing now. Thanks to all who contributed to this bug fix.
@Chris: as I read it, the string "@im=" initializes the xlib functions to use the system supplied default input methods. Since everything looks okay now I don't intend to change anything, unless we get new bug reports. Thanks. | |
| |
| #12 | AlbrechtS
11:59 Jan 22, 2020 |
| FTR: document git commit (958d912ffcdb41e977fa4e95819bd4cee836b697).
See also STR #3502 for an update:
https://www.fltk.org/str.php?L3502 | |
| |
| #13 | AlbrechtS
04:03 Feb 10, 2020 |
| Reopening and reverting the fix in commit 958d912ffcdb41e977fa4e95819bd4cee836b697 which was applied in FLTK 1.3.4 and 1.3.5.
This fix was incorrect and caused issues with users setting an X Input Method (see STR #3502 for discussion).
https://www.fltk.org/str.php?L3502
Short info: the fix given in STR 3502 is to use
XSetLocaleModifiers(""); | |
| |
| #14 | AlbrechtS
04:31 Feb 10, 2020 |
| FTR: commit 219ae5e455e7943ffb35fdd5edbe13dcc6955423 reverts the previous commit and applies the fix for STR 3502, leaving this STR in an open (pending) state.
To all that were (and are) involved: Please test in your environment and report whether the issue is still causing problems in your environments and please don't forget to mention your OS and version and as much related info as possible (Window Manager etc.).
I assume that it is possible that the issue was resolved by a new OS version or OS update since it was reported that "Ubuntu 14.04/14.04.1" was affected. I tried hard with the test program 'loseskeyboard.cxx' to replicate the issue on Linux Mint (19.2) which is based on Ubuntu but could not see any hangups.
Here is my request: please report any issues you see with the latest commit in Git branch 'branch-1.3' in your current environment(s) within the next 14 days - otherwise this STR will be closed (again).
Note to testers: a similar patch will be applied to FLTK 1.4 (Git master) shortly. Test results for FLTK 1.4 would be appreciated as well. Thanks. | |
| |
| #15 | AlbrechtS
06:36 Jun 30, 2020 |
| This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR. | |
[ Return to Bugs & Features ]
|
| |
