Dear Maintainer,

all input textfields in the game stops working instantly or in a few minutes after start.

Hi,

thanks for your report. Unfortunately I can't reproduce your issue here.
I can type names of new save games into a text field even if several
minutes have passed. I can also modify the path to sound files for example.

I need your help to narrow this problem down. Can you describe a way to
reproduce your issue reliably?

Does it make any difference if you run the game in fullscreen or
windowed mode? If you run the game in windowed mode, what happens if you
open another application like an editor? Can you still type in text there?

Do you use a custom kernel? If yes, please try running the game with the
current kernel in sid.

Do you experience other problems besides the non-functional input text
fields?

The more information the better.

Regards,

Markus

Hi Markus,

I run freeorion via optirun from the bumblebee package, because freeorion doesn't run with the regular graphics card.

No difference between fullscreen and windowed. Bug occurs in both cases.
Freeorion has no effect of the usability of the system. bug is only in the game.

Everything else in the game works fine.

I don't know, how custom my kernel is. i tried freeorion with older kernels, but the bug is still there. i try a newer kernel shortly.




Marius

i forgot to mention, that the deb-package released from the freeorion dev
team on sorceforge doesn't have this bug (but another bug). so i don't
think, its a kernel or bumblebee problem.

severity 719496 normal
tags 719496 unreproducible moreinfo
thanks

That's an interesting statement. The sourceforge version uses the same
developer code from revision 6281 but packaging and dependencies are
different. Important shared libraries are included and the game is not
linked against Debian's system libraries. So your issue might be a
result of compiling the game against different library versions.

However it could also be something completely different. I only
mentioned your kernel version because the version doesn't look like a
stock kernel and custom kernels like the one from liquorix can cause
random errors and they are sometimes the root cause for weird failures.

I lower the severity to normal because I can't reproduce the issue
myself and I need more feedback from other users if they experience the
same bug on their systems.

I will ping you from time to time, when a newer version of FreeOrion is
released, and ask you to check whether the problem still persists. If
you can find out more about this issue, please feel free to report back
to this bug report.

Regards,

Markus

I have the exact same problem here.  Nothing special to do, I cannot
modify a textfield in-game.  I am on amd64 as well, and I'm launching
freeorion normally, from terminal or wm menu.

I'm running the game on Gnome 3 with Nouveau drivers and a Geforce 9600
GT card using amd64 as well. Everything seems to work fine.

Maybe this bug is related to the OIS Input plugin and the libois-1.3.0
library FreeOrion depends on. This plugin handles mouse and keyboard
input in-game.

By the way what kind of desktop environment do you both use?

Although this file wasn't intended to be editable, you can try to modify
OISInput.cfg in /usr/share/games/freeorion

# Define X11 settings
x11_mouse_grab=false
x11_mouse_hide=true
x11_keyboard_grab=false
XAutoRepeatOn=true

Play with false and true, perhaps this might help you. Just to make sure
that I understand you correctly:

You can use your mouse in-game and click on every icon, menu etc. but
you can't type something into the input fields but the mouse works fine?

Then try setting

x11_keyboard_grab=true

However usually it shouldn't be necessary to modify this file.

More feedback welcome

Regards,

Markus

I use Xfce, Nouveau and a Geforce GT 425M on amd64. Everything else in the
game including mouse keeps working.

Modifying x11_keyboard_grab to true doesn't help, but i started freeorion
in xmonad today and it runs without the bug. probably its a problem with
xfwm4.




Am 12.08.2013, 23:03 Uhr, schrieb Markus Koschany <apo@gambaru.de>:

Thank you for providing additional information for this bug report. I
think we are getting closer to the root cause of this issue. I have
installed freeorion on a pure sid system with Openbox and I still can't
reproduce this bug thus I will try with Xfce again tomorrow.

It appears that it depends on how the desktop environment controls
keyboard input for applications. I believe in Xfce the package
xfce4-settings provides a daemon, xfsettingsd, that controls keyboard
and mouse settings during a user session.

You could try the following:

1. Try to disable or kill your xfsettingsd. What happens if you play
FreeOrion?

2. You can also remove or move OISInput.cfg in
/usr/share/games/freeorion. The game should fall back to default values.
What happens?

3. Please attach you freeorion.log and ogre.log to this bug report. You
can find these log files in your home directory under ~/.freeorion/
Perhaps we can find some hints about the problem in your log files.

Thanks,

Markus

I am myself using openbox with razor-qt, so the issue may not be that
simple.

Setting x11_keyboard_grab to true does correct the problem here.

Nothing happens after killing xfsettingsd while bug occurs.

Deleting OISInput.cfg helped. Freeorion seems to work now, but the mouse
jumps sometimes.

tags 719496 - moreinfo
thanks

I have tried to reproduce this bug with razor-qt and xfce but haven't
succeeded yet. I believe it has nothing to do with window managers but
with the way those desktop environments handle mouse and keyboard input.
However I think there is enough information to work on a solution.

Given all the information so far, the way forward seems to be:

1.
Install OISInput.cfg either to /etc/freeorion or ~/.freeorion and let
users adjust those settings as they see fit.

2.
Disable / comment out all configuration options in OISInput.cfg by
default and let the desktop environment handle mouse and keyboard input.

That should solve your issues and you can still tweak those settings.

I hope this helps

Markus

Hi Yann and Marius,

I'm in contact with the developers of FreeOrion and they asked me to relay
a question to you.

Quote from http://www.freeorion.org/forum/viewtopic.php?f=25&t=7719

You can switch with ALT-Tab between different windows and FreeOrion and sometimes you
can't type because this locks your keyboard input. Can you confirm that pressing
ALT again in this case allows you to type again?

Another idea:

Can you try reproducing this bug and showing us the output of xtrace?

xtrace freeorion > xtrace.log

Perhaps another application interferes with FreeOrion and this might be a way to track
down the issue.

Thanks in advance.

Regards,

Markus

using alt-tab to switch out and back to freeorion forces a similar bug
where backspace keeps working. in default case of real bug, backspace
doesn't work either. clicking alt solves this bug, but not the real bug,
which occurs a few minutes or seconds later and is not solvable with
clicking alt.

i reinstalled freeorion and freeorion-data. while xtrace freeorion i do
* wait a few minutes and don't switch windows.
* click on singleplayer to get a input textfield and try typing, which
doesn't work.
* quiting freeorion.

Hi Markus,

With the workaround I do have Al-TAB issues:

If I try hit Alt-TAB, nothing seems to happen; on second Alt-TAB press
the border of the fullscreen window flashes and I can then use desktop
shortcuts (Here Win-F1 to switch desktop, or simply Alt-TAB).  Eg
Win-F1 is completely ignored unless I hit Alt-TAB first, Alt alone is
not sufficient.  When I get back to the desktop where FreeOrion is
running, I can switch away immediately, as long as I did not click the
game first, after which I'm back into the "locked" mode.

Is that what you meant, or did you mean without the workaround ?

Hi Yann,

On 30.08.2013 23:27, Yann Dirson wrote:
[...]

I meant without the workaround but I think it doesn't matter anyway.

From my point of view it is clear that some users can experience a
keyboard lock with the default values in OISInput.cfg, although they are
sane and work perfectly for myself.

Upstream will not change the default values but they might change the
location of OISInput.cfg to the user's home directory, so that you can
simply adjust the values to suit your needs.

Perhaps in a future release they might even consider to use another
input handling method and replace OIS with something similar but that's
speculation.

Regards,

Markus

I can confirm this bug ( I'm using Xfce).

I tried to change the x11_keyboard_grab to true in OISInput.cfg and that
allowed me to input text in freeorion, but then the keyboard didn't work
with any other app outside freeorion: xterms, editors, firefox, ... When I
close freeorion, the keyboard works again.

I am available to do more extensive tests if you want.

Thanks for your offer. If you find out what option or program causes
this behaviour on Xfce and interferes with Freeorion, respectively OIS,
please let me know.

Regards,

Markus

El Sun, Oct 06, 2013 at 12:58:12PM +0200, Markus Koschany dice:

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.php/topic,5851.0.html

I've got a way to go around it, applying one of the pending pull
requests from
https://github.com/wgois/Object-oriented-Input-System--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-oriented-Input-System--OIS-/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
v(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 texts are working fine. The
OISInput.cfg sets 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

I'm going to post this in the FO forum thread, to see what they think
about it.

Any comments are welcome.

On 24.11.2013 18:05, Javier Cantero wrote:[...]

Hello Javier,

thank you very much for your investigations into this bug report.

I think we are dealing here with two separate bugs. The first one is the wrong location of
OISInput.cfg. This file should be located in the user's home directory. I intend to fix this
issue with the next upstream release of FreeOrion.

The second one is related to Debian's libois-1.3.0 package. I can't really fix it in FreeOrion,
so I have cloned this bug report and reassigned it to libois accordingly.
Your patch is very welcome. Now it's up to the libois-1.3.0 maintainers to apply it. Please
feel free to send further comments directly to this new cloned bug report.

Relevant links for the OIS maintainers:

https://github.com/wgois/Object-oriented-Input-System--OIS-/pull/3

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


Thanks again, that you also added these informations to my thread at FreeOrion's forum.
Hopefully this will fix the issue for all those users who use the embedded version of OIS
in FreeOrion some day.

Regards,

Markus

Hello,

Javier Cantero found out more about this issue and reported his findings
to FreeOrion's upstream forum.

So that this won't get lost, I'm quoting here his original remarks

http://www.freeorion.org/forum/viewtopic.php?f=25&t=7719&start=15#p64812

"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:

xtrace of FreeOrion over Xfce 4.10 (using libois 1.3.0 from debian jessie)
https://gist.github.com/javiercantero/7752527

xtrace of FreeOrion over Xfce 4.10 (using patched libois)

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

xtrace of FreeOrion over plain X, without Desktop Environment (using
libois 1.3.0)

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

xtrace of FreeOrion over plain X, without Desktop Environment (using
patched libois)

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

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.

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
(https://gist.github.com/javiercantero/7753445) finds the sequence
KeyRelease(Kn) -> KeyPress(Kn), and "eats" the KeyPress event, because
that is its job: convert a secuence of repeated keystrokes KeyPress(Ki)
-> 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 KeyEvent(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."

Since libOIS upstream is apparently dead, and the projects that use it (mostly
games[1] using Ogre3D libraries like freeorion) are gradually abandoning this
library (including Ogre3D), clearly the bug will never be resolved.

So I want to sumarize my last discoveries about the bug itself. First,
the bug is caused by a weird interaction with xscreensaver. The behaviour of
xscreensaver in some way causes the appearance of the unexpected KeyRelease
events that leads to the libOIS misbehaviour already explained. More details
here: http://www.freeorion.org/forum/viewtopic.php?p=70165#p70165

My suspects of the root of the problem are detailed here:
http://www.freeorion.org/forum/viewtopic.php?p=71435#p71435 Long explanation
short: I think the bug could be in X.Org Server event queue handling code, but
that code is too complex (and prone to errors) to be worth check it without a
good reason (and there is no good reason if upstream and dowstream are not going
to apply any patches).

So I recommend to anyone affected by this bug to talk to the developers of the
application to move away from libOIS to another library with actual suport (like
SDL). It's going to be a better solution in the long term.


[1] By the way, it's a bit strange that libOIS is under the umbrella of Debian
Multimedia Maintainers instead of Debian Games Team due to its nature and
users.