OISInput.cfg: input text fields don't work

Problems and solutions for installing or running FreeOrion, including discussion of bugs if needed before posting a bug report on GitHub. For problems building from source, post in Compile.

Moderator: Oberlus

Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#16 Post by Geoff the Medio »

Maybe have a look / add some debuggin in GetModKeys in OISInput.cpp to see if the wrong ALT state is being passed in by OIS, or if it's something GG is doing wrong with regard to missing the KEYRELEASE events so thinking the key is still pressed...?

Or maybe there's a way to add calls to OISInput::keyReleased that resolve the issue whenever the FreeOrion window loses focus?

Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

Re: OISInput.cfg: input text fields don't work

#17 Post by Apo »

Dilvish wrote:Reading over the debian bug report log I noticed it looked like only one of the people with this problem said that mousegrab=true fixed it for them.
This is still easily repeatable for me today, I can open up options, go to the directories page, confirm I can type, alt-tab out, click back in, and then I cannot type (or rather, it doesn't accept my input, I think it is reading it all as 'alt-a', 'alt-b', etc) until I hit the ALT key again (has to be the same one I used to alt-tab), and then everything is fine. The alt-lock does not get initiated just by hitting the alt-key a first time, it seems to only start by alt-tab. Apo, please check if this might be their problem, if pressing ALT again allows them to type.
adrian_broher wrote:Reading the debian bug about the inconsistent time this problem occurs I would like to know if some notification mechanism snitches away the focus of the window. Maybe that is something your user should test with some x11 event tracing. xtrace or xev maybe show us the relevant hint.
I have relayed your questions to both users. http://bugs.debian.org/719496

If you intend to ask further questions, it might be more efficient to ask those users directly. You can contact them by writing an e-mail to both of them and keeping the bug report in CC. ([email protected]).

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: OISInput.cfg: input text fields don't work

#18 Post by Dilvish »

Hmmm, I see the user replied, and was able to verify the alt-tab problem as a distinct issue from his more significant problem. I'm not familiar enough with the xtrace log to get anything useful from it at this time, perhaps someone else here can.

On the alt-tab issue, it appears it's a known problem with OIS, which they seem to have only fixed for windows. It seems that our OIS version has had some linux build support files stripped out so I can't even modify it and build it in Linux if I uninstall my standard ois library. I suppose I could just swap in the linux files from sourceforge though, or just try implementing it all via OISInput.cpp, but it also looks like the ability to force a re-read of key states which the Windows fix relied on is not available for the LinuxKeyboard (though perhaps I could just force a reinitialization of it after an alt-tab).

What I did with our current setup is just have the GiGiOgrePlugin_OIS (via OISInput.cpp) nullify any alt mods before passing on keypress events to GG/Ogre, which seems to work fine since FO currently doesn't use the alt key for anything I know of (though I suppose I'm not entirely sure if some non-english keyboard settings might rely on it for certain characters). Attached is a little patch for that if we want to consider using it .

To reiterate/clarify, the attached patch is a hack-ish potential fix for the alt-tab problem, not for the main problem reported here. However, it does suggest that to help debug the main problem here we could perhaps compile a special version of FO for this user to test, that adds some keypress logging at essentially the same spot as this patch, to see just what key presses, if any, are getting through to FO in his situation.

also potentially of interest -- some other folks dealing with this and other problems with standard OIS, looking at using SDL with possibly an OIS wrapper.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

Re: OISInput.cfg: input text fields don't work

#19 Post by Apo »

I see there has been no final decision how to handle this bug. What about making the first step and moving OISInput.cfg to the user's home directory where he or she can edit the file? That should solve at least one part of the problem.

Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

Re: OISInput.cfg: input text fields don't work

#20 Post by Apo »

Hello,

I'm attaching a simple patch to use OISInput.cfg from the user's home directory instead of the data directory. I will apply this patch with the next revision of FreeOrion for Debian because of the reasons I already described in this thread. I think $HOME/.freeorion is the correct place to modify those settings.

Thanks for considering the patch.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#21 Post by Geoff the Medio »

Since that file isn't going to be in the Windows user FreeOrion directory, I wouldn't want to apply that patch as is. The file can be in a different location on Linux if the packaging is set up to put it where expected, but the patch would need adjustment accordingly...

Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

Re: OISInput.cfg: input text fields don't work

#22 Post by Apo »

Wouldn't it suffice if you put conditionals around this one line of code and keep it as it is on Windows and only change it to GetUserDir() on Linux? This way it should satisfy everyone.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#23 Post by Geoff the Medio »

Apo wrote:Wouldn't it suffice if you put conditionals around this one line of code and keep it as it is on Windows and only change it to GetUserDir() on Linux?
Probably, yes.

jcantero
Krill Swarm
Posts: 12
Joined: Sun Nov 24, 2013 5:08 pm

Re: OISInput.cfg: input text fields don't work

#24 Post by jcantero »

Hello, I'm one with this error in his setup (I'm using Xfce).

I've sent a message with my research to the Debian bug, but I think you may be also interested. So here it is:

Definitely it's a libOIS related issue. There are several messages in the libois forums with the same symptoms, for example this:
http://www.wreckedgames.com/forum/index ... 851.0.html

I've got a way to go around it, applying one of the pending pull requests from https://github.com/wgois/Object-oriente ... OIS-/pulls. But before that, let me say that the libOIS version packaged in Debian testing and the version in the FreeOrion sources are not exactly the same. The debian version is based in the 1.3.0 stable (with some additional fixes), but FO uses the actual HEAD of SourceForge (r40 in http://sourceforge.net/p/wgois/code/40/log/ or master branch of GitHub.

So the first thing I made was to patch libois-1.3.0 package with the changes of the FreeOrion version. Since the most of them are W32 stuff, and the non-linux related source files are removed from debian source package, I only had to patch this:

https://gist.github.com/javiercantero/7628876

With this patch the behaviour of FO didn't change, but at least we have the same source base to compare. Then I tried to merge this pull request:

https://github.com/wgois/Object-oriente ... IS-/pull/3

The change is trivial, it only deletes the XNextEvent() call next to XPeekEvent() in _isKeyRepeat() method of LinuxKeyboard class. You can get the patch from the pull request, or cloning the k1ll's repository (x11_key_repeat_fix branch). But for simplicity, I also put the exact patch I applied here:

https://gist.github.com/javiercantero/7629235

With this small change FreeOrion input text fields are working fine. The OISInput.cfg is set to x11_keyboard_grab=false (and x11_mouse_grab=false). I can change the window focus, and the keyboard comes with me. When I return to FO, the keyboard also returns, and everything seems fine. Except Alt-TAB. If I do an Alt-TAB switch and return to FO, the keyboard doesn't return.

Although this patch works, even me can see that this is a dirty hack, hard to say why it works, or what it fixes. At least I can't. That is why I'm going to test another two patches to see what it does. Specifically the OIS version of worldforge project has some promising changes I'd like to test: https://github.com/worldforge/ois

Any comments are welcome.

(PS: I'm not english speaker, so this text can contain some horrendous language mistakes, please forgive me for all of them)

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#25 Post by Geoff the Medio »

jcantero wrote:That is why I'm going to test another two patches to see what it does.
Please report back whatever OIS modifications you find work best.

jcantero
Krill Swarm
Posts: 12
Joined: Sun Nov 24, 2013 5:08 pm

Re: OISInput.cfg: input text fields don't work

#26 Post by jcantero »

Neither of two patches I've been testing fix the bug by itself. The only way I get the keyboard fixed is applying the k1ll's patch (deleting the XNextEvent() call in _isKeyRepeat()). Sorry, but that's all I got.

For the record, the tested patches are a) the changes made by the worldforge project (I only tested those applied to linux, see https://github.com/worldforge/ois for the complete patched version), and b) another non-merged pull request called "Improve LinuxKeyboard to handle dead keys" (https://github.com/wgois/Object-oriente ... IS-/pull/1). I was hoping that the worldforge patch al least get to work the Alt+TAB, but it didn't. Curiously the only key that works when the focus returned from an Alt+TAB is backspace. So I was able to delete characters of the input text field but not to add new ones. Maybe the people that don't have problems with the keyboard (don't use Xfce) can try the patch to see if Alt+TAB works better in their systems...

jcantero
Krill Swarm
Posts: 12
Joined: Sun Nov 24, 2013 5:08 pm

Re: OISInput.cfg: input text fields don't work

#27 Post by jcantero »

I don't know if you are interested in this (being a libois and not a FO related bug) but I've done some X event traces of FreeOrion with xtrace, and now I understand what is going on. The traces are here:
The bug triggers when the X Server (or whatever is tweaking with these events) starts to send an additional KeyRelease event before the KeyPress event. So
KeyPress(K1) -> KeyRelease(K1) -> KeyPress(K2) -> KeyRelease(K2) -> KeyPress(K3) -> KeyRelease(K3) -> ...
becomes at certain moment
KeyRelease(K4) -> KeyPress(K4) -> KeyRelease(K4) -> KeyRelease(K5) -> KeyPress(K5) -> KeyRelease(K5) -> KeyRelease(K6) -> KeyPress(K6) -> KeyRelease(K6) -> ...
The _isKeyRepeat() function finds the sequence KeyRelease(Kn) -> KeyPress(Kn), and "eats" the KeyPress event, because that is its job: convert a secuence of repeated keystrokes KeyPress(Kn) -> KeyRelease(Kn) -> KeyPress(Kn) -> KeyRelease(Kn) -> ... -> KeyPress(Kn) -> KeyRelease(Kn) to a unique KeyPress(Kn) -> KeyRelease(Kn), and that is done filtering the KeyRelease(Ki) events with a KeyPress(Ki) after it (with only 2 units of time of delay).

So the proposed patch prevents that the _isKeyRepeat() function removes the KeyPress events, but also destroys the purpose of _isKeyRepeat(). With the patch applied (2nd trace) the "ghosts" KeyReleases still are there, but now the KeyPress events are processed by the right code of libois, instead of being lost.

The third and 4th traces proves that this weird behaviour with the keyboard events doesn't happen if Xfce DE is not launched. With a setup of X and a simple window manager (OpenBox), the keyboard traces are as intended (KeyPress -> KeyRelease -> KeyPress -> KeyRelease -> ...).

Now I'm trying to reproduce the wrong behaviour of the keyboard events from another program launched within Xfce. I've written a simple Xlib example that reads the keyboard events: xreadkeys.c. But the showed events and xtraces of xreadkeys are completely normal. If Xfce is triggering something inside FreeOrion that messes up the keyboard events, I don't see what or how it can be. The only thing I know is it's not inmediate, there is a delay to the instant it happens.

(EDIT: minor fixes)
Last edited by jcantero on Fri Jul 11, 2014 3:14 pm, edited 1 time in total.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: OISInput.cfg: input text fields don't work

#28 Post by Dilvish »

that is interesting, thanks for keeping us updated.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

jcantero
Krill Swarm
Posts: 12
Joined: Sun Nov 24, 2013 5:08 pm

Re: OISInput.cfg: input text fields don't work

#29 Post by jcantero »

Sorry for reopening this topic.

I have good news and bad news. The good news are I have been able to trace the problem to where I think is its root. The bad news is that I am not able to find a way to fix it.

What I've found: the program that causes the unexpected KeyRelease events is xscreensaver. Not any screensaver, but specifically xscreensaver. That explains why the users of certain desktop environments like XFce (my case), LXDE, etc have the problem but not the users of GNOME (they have their own gnome-screensaver) or KDE (same). That also explains why the bug didn't show when I tried a simple window manager (OpenBox) with a clean X session: in my configuration, xscreensaver was launched at the start of the XFce session. When I try to replace the XFce window manager by OpenBox maintaining the rest of the environment, the bug persisted, and only when I came to stop xscreensaver Freeorion keyboard events returned to normal.

The thing is xscreensaver do some craaaazy stuff to know when the user is away from keyboard. This is a comment from the developer himself:

Code: Select all

/*
...
 * If we don't have the XIdle, MIT-SCREEN-SAVER, or SGI SCREEN_SAVER
 * extensions, then we do the XAutoLock trick: notice every window that
 * gets created, and wait 30 seconds or so until its creating process has
 * settled down, and then select KeyPress events on those windows which
 * already select for KeyPress events. It's important that we not select
 * KeyPress on windows which don't select them, because that would
 * interfere with event propagation. This will break if any program
 * changes its event mask to contain KeyRelease or PointerMotion more than
 * 30 seconds after creating the window, but such programs do not seem to
 * occur in nature (I've never seen it happen in all these years.)
 *
 * The reason that we can't select KeyPresses on windows that don't have
 * them already is that, when dispatching a KeyPress event, X finds the
 * lowest (leafmost) window in the hierarchy on which *any* client selects
 * for KeyPress, and sends the event to that window. This means that if a
 * client had a window with subwindows, and expected to receive KeyPress
 * events on the parent window instead of the subwindows, then that client
 * would malfunction if some other client selected KeyPress events on the
 * subwindows. It is an incredible misdesign that one client can make
 * another client malfunction in this way.
...
 */
If you review the timers.c code (not recommended), you can see that the method is based on listening the KeyPress events of all opened windows in the X server, and that's achieved monitoring the windows tree permanently. And when xscreensaver tries to do that on FO is when things go wrong in libOIS events.

This is what I found, and I'd like to confirm it. If someone could test this, I'd appreciate it. The only thing to do is install xscreensaver (if you don't want, see next paragraph), launch FreeOrion without grabbing the keyboard (x11_keyboard_grab must be false in OISInput.cfg), open a dialog where you can write (for example "Load Game"), wait until the keyboard stops working (~20-30 sec.), stop xscreensaver (the recommended method is "xscreensaver-command -exit" in the command line) and see if FreeOrion input is working now.

Alternatively, if you don't want to mess with your DE (GNOME, KDE, ...) by installing xscreensaver , you can simulate its behaviour with this little program I wrote: keyb-eavesdrop.c. "gcc -lX11 keyb-eavesdrop.c -o keyb-eavesdrop" is enough to compile it. The main difference is that ./keyb-eavesdrop is able to stop immediately FreeOrion's input (xscreensaver takes a while because the function that causes the bug, notice_events() ,is launched by a timer every 30 seconds). You can resume the input by killing key-eavesdrop, or stopping it with the ESC key (ESC key works even from FreeOrion's stalled input itself). There is not better proof of the cause of the bug than this.

What I don't know (yet): why of how the XSelectInput( display, window, SubstructureNotifyMask | events ); is causing the Release events to appear in libOIS (and only in libOIS). I have some guesses, but not conclusive results.

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: OISInput.cfg: input text fields don't work

#30 Post by mrSpaceman »

Hello! :)

I have a copy of FOv0.4.3+ [SVN 7301] built and running on Ubuntu 14.4. I also have the text field problem, which seems to be the Alt-TAB issue. If I Alt-TAB out of FO, I can only type text if I have pressed Alt once FO has focus. Annoying! :evil:

I don't think it's xscreensaver, because it's not installed on my system. :?

I'm willing to spend some time on this to work out the problem. Watch this space. :wink:

Post Reply