0007778: Keyboard input stops working after fullscreen/window toggle (F11)

(0028079)
Urist McKracken (reporter)
2014-08-01 07:23
edited on: 2014-08-01 10:58

OS Version is Ubuntu 14.04 LTS, not 12.04. Sorry about that. Bug occurs on initial start screen too, and can be triggered by switching from fullscreen to window repeatedly.

Manager's Note: OS Version corrected.

(0029640)
ptb_ptb (reporter)
2014-08-26 06:39

Do all keys stop working, or just some?

I have a bug for DF in Windows where nearly all keys stop working, sometimes, after ALT+TAB.

The Space key and ESC key still work in my case.

(0029645)
lethosor (manager)
2014-08-26 07:10

ptb_ptb, does 0006455 explain your problem?

(0029801)
Urist McKracken (reporter)
2014-08-30 09:06

In my case, all keys stop working. Doesn't look like a stuck modifier key, as no modifiers are used when the bug occurs.

(0031302)
bjh21 (reporter)
2014-12-09 14:52
edited on: 2014-12-09 14:53

I've encountered what I think is the same problem (similarly on Ubuntu 14.04, usually after switching out of full-screen mode). I've found a workaround, namely a way to inject keypresses into Dwarf Fortress that it actually listens to:

Install the "xdotool" package.

In a terminal, run "xwininfo" and click on the Dwarf Fortress window to get its window id (in my case, 0x4200003), the run:

xdotool key --window 0x4200003 Escape
xdotool key --window 0x4200003 Down
xdotool key --window 0x4200003 Return

replacing "0x4200003" with the window id you found. Obviously you can change the sequence of keys to suit the state the game got stuck in.

(0031309)
kicking jay (reporter)
2014-12-09 20:22

Reported this in a duplicate a while back.

http://www.bay12games.com/dwarves/mantisbt/view.php?id=8565 [^]

(0031336)
bjh21 (reporter)
2014-12-15 16:03

With the help of an X protocol tracer (http://www.chiark.greenend.org.uk/~sgtatham/xtruss/ [^]), the X Input Method protocol specification (http://www.x.org/releases/X11R7.7/doc/libX11/XIM/xim.html [^]), and several mugs of tea, I think I've found the cause.

When there's an X Input Method server (IMS) present, as there usually is on Ubuntu, Dwarf Fortress (DF) sends all its keyboard events to the IMS using the XIM protocol. In normal operation, when DF receives a KeyPress event from the X server, it passes it to the IMS in an XIM_FORWARD_EVENT message. The IMS (assuming it's not interested in this event) passes it back in another XIM_FORWARD_EVENT message, this time with the "synchronous" flag set. The "synchronous" flag tells DF that it now needs to send an XIM_SYNC_REPLY message, which it duly does.

When things go wrong, DF sends the XIM_FORWARD_EVENT message as usual, but fails to read the reply message and hence never sends the XIM_SYNC_REPLY message. Instead, it just carries on sending XIM_FORWARD_EVENT messages. It looks like the IMS refuses to deal with these, presumably because it's still waiting for XIM_SYNC_REPLY. This means that the keypresses never get forwarded back to DF, and it sits there unresponsive.

I've found that I can reproduce the bug simply by pressing F11 a few times in rapid succession (about five times in a second is usually enough).

I doubt that DF deliberately interfaces with input methods itself, so presumably this bug is somewhere in the depths of SDL or whatever library is implementing the XIM protocol.

For the record, on my Ubuntu 14.04 LTS system, the version of the SDL packages is "1.2.15-8ubuntu1.1".

(0031337)
bjh21 (reporter)
2014-12-15 16:09
edited on: 2014-12-16 03:24

Confirming that the problem relates to XIM, if I kill the "ibus-daemon" process (which is the input method server) before starting DF, I can hammer F11 to my heart's content and DF continues to respond to the keyboard. Note that killing "ibus-daemon" while DF is running is a Very Bad Idea: it causes DF to segfault.

(0031340)
bjh21 (reporter)
2014-12-16 05:21

I've just tested on an Ubuntu 14.10 64-bit live image and after installing lots of 32-bit libraries I was able to get DF to run and it exhibited basically the same behaviour as on 32-bit 14.04: it tangled up the XIM exchange on rapid presses of F11, but could be recovered with the aid of "xdotool". I forgot to try killing ibus-daemon, but I have no reason to suspect this would behave any differently from 14.04 LTS.

(0036671)
MaXMC (reporter)
2017-07-23 01:32

I have the same problem on Ubuntu 17.04.

It seems I triggered it by pressing F11 then Alt+Tab and then F11 again.

The game answers to mouse input from DFHack though.

(0040781)
Susan (reporter)
2020-11-01 08:07

seems to still be an issue as of 47.04 on ubuntu 20.04. killing ibus-daemon seems to still work as a workaround too.

(0041120)
Susan (reporter)
2021-07-26 14:03

still happening as of DF 47.05 on ubuntu 21.04.

(0041130)
lethosor (manager)
2021-08-11 12:10

I can't reproduce this on Ubuntu 21.04 with X11+GNOME - are you using a different window manager or desktop environment?

(0041233)
Susan (reporter)
2022-03-13 18:42

@lethosor: terribly sorry, only just saw this message! it was wayland+gnome rather than x11; unfortunately i don't have the ability to test on linux right now as my main computer has been in need of repair for some time.

Issue History
Date Modified	Username	Field	Change
2014-08-01 03:51	Urist McKracken	New Issue
2014-08-01 05:22	Dwarfu	Relationship added	related to 0005260
2014-08-01 07:23	Urist McKracken	Note Added: 0028079
2014-08-01 10:57	Dwarfu	OS Version	12.04 LTS => 14.04 LTS
2014-08-01 10:58	Dwarfu	Note Edited: 0028079	View Revisions
2014-08-26 06:39	ptb_ptb	Note Added: 0029640
2014-08-26 07:10	lethosor	Note Added: 0029645
2014-08-30 09:06	Urist McKracken	Note Added: 0029801
2014-12-09 14:52	bjh21	Note Added: 0031302
2014-12-09 14:53	bjh21	Note Edited: 0031302	View Revisions
2014-12-09 20:22	kicking jay	Note Added: 0031309
2014-12-11 14:21	lethosor	Relationship added	has duplicate 0008565
2014-12-15 16:03	bjh21	Note Added: 0031336
2014-12-15 16:04	bjh21	Issue Monitored: bjh21
2014-12-15 16:09	bjh21	Note Added: 0031337
2014-12-15 20:17	lethosor	Assigned To	=> lethosor
2014-12-15 20:17	lethosor	Status	new => acknowledged
2014-12-16 03:24	bjh21	Note Edited: 0031337	View Revisions
2014-12-16 05:21	bjh21	Note Added: 0031340
2015-10-28 20:32	chuzzum	Issue Monitored: chuzzum
2017-07-23 01:32	MaXMC	Note Added: 0036671
2020-11-01 08:07	Susan	Note Added: 0040781
2021-07-26 14:03	Susan	Note Added: 0041120
2021-08-11 12:10	lethosor	Note Added: 0041130
2022-03-13 18:42	Susan	Note Added: 0041233
2022-03-13 18:42	Susan	Issue Monitored: Susan

Notes
(0028079) Urist McKracken (reporter) 2014-08-01 07:23 edited on: 2014-08-01 10:58	OS Version is Ubuntu 14.04 LTS, not 12.04. Sorry about that. Bug occurs on initial start screen too, and can be triggered by switching from fullscreen to window repeatedly. Manager's Note: OS Version corrected.

(0029640) ptb_ptb (reporter) 2014-08-26 06:39	Do all keys stop working, or just some? I have a bug for DF in Windows where nearly all keys stop working, sometimes, after ALT+TAB. The Space key and ESC key still work in my case.

(0029645) lethosor (manager) 2014-08-26 07:10	ptb_ptb, does 0006455 explain your problem?

(0029801) Urist McKracken (reporter) 2014-08-30 09:06	In my case, all keys stop working. Doesn't look like a stuck modifier key, as no modifiers are used when the bug occurs.

(0031302) bjh21 (reporter) 2014-12-09 14:52 edited on: 2014-12-09 14:53	I've encountered what I think is the same problem (similarly on Ubuntu 14.04, usually after switching out of full-screen mode). I've found a workaround, namely a way to inject keypresses into Dwarf Fortress that it actually listens to: Install the "xdotool" package. In a terminal, run "xwininfo" and click on the Dwarf Fortress window to get its window id (in my case, 0x4200003), the run: xdotool key --window 0x4200003 Escape xdotool key --window 0x4200003 Down xdotool key --window 0x4200003 Return replacing "0x4200003" with the window id you found. Obviously you can change the sequence of keys to suit the state the game got stuck in.

(0031309) kicking jay (reporter) 2014-12-09 20:22	Reported this in a duplicate a while back. http://www.bay12games.com/dwarves/mantisbt/view.php?id=8565 [^]

(0031336) bjh21 (reporter) 2014-12-15 16:03	With the help of an X protocol tracer (http://www.chiark.greenend.org.uk/~sgtatham/xtruss/ [^]), the X Input Method protocol specification (http://www.x.org/releases/X11R7.7/doc/libX11/XIM/xim.html [^]), and several mugs of tea, I think I've found the cause. When there's an X Input Method server (IMS) present, as there usually is on Ubuntu, Dwarf Fortress (DF) sends all its keyboard events to the IMS using the XIM protocol. In normal operation, when DF receives a KeyPress event from the X server, it passes it to the IMS in an XIM_FORWARD_EVENT message. The IMS (assuming it's not interested in this event) passes it back in another XIM_FORWARD_EVENT message, this time with the "synchronous" flag set. The "synchronous" flag tells DF that it now needs to send an XIM_SYNC_REPLY message, which it duly does. When things go wrong, DF sends the XIM_FORWARD_EVENT message as usual, but fails to read the reply message and hence never sends the XIM_SYNC_REPLY message. Instead, it just carries on sending XIM_FORWARD_EVENT messages. It looks like the IMS refuses to deal with these, presumably because it's still waiting for XIM_SYNC_REPLY. This means that the keypresses never get forwarded back to DF, and it sits there unresponsive. I've found that I can reproduce the bug simply by pressing F11 a few times in rapid succession (about five times in a second is usually enough). I doubt that DF deliberately interfaces with input methods itself, so presumably this bug is somewhere in the depths of SDL or whatever library is implementing the XIM protocol. For the record, on my Ubuntu 14.04 LTS system, the version of the SDL packages is "1.2.15-8ubuntu1.1".

(0031337) bjh21 (reporter) 2014-12-15 16:09 edited on: 2014-12-16 03:24	Confirming that the problem relates to XIM, if I kill the "ibus-daemon" process (which is the input method server) before starting DF, I can hammer F11 to my heart's content and DF continues to respond to the keyboard. Note that killing "ibus-daemon" while DF is running is a Very Bad Idea: it causes DF to segfault.

(0031340) bjh21 (reporter) 2014-12-16 05:21	I've just tested on an Ubuntu 14.10 64-bit live image and after installing lots of 32-bit libraries I was able to get DF to run and it exhibited basically the same behaviour as on 32-bit 14.04: it tangled up the XIM exchange on rapid presses of F11, but could be recovered with the aid of "xdotool". I forgot to try killing ibus-daemon, but I have no reason to suspect this would behave any differently from 14.04 LTS.

(0036671) MaXMC (reporter) 2017-07-23 01:32	I have the same problem on Ubuntu 17.04. It seems I triggered it by pressing F11 then Alt+Tab and then F11 again. The game answers to mouse input from DFHack though.

(0040781) Susan (reporter) 2020-11-01 08:07	seems to still be an issue as of 47.04 on ubuntu 20.04. killing ibus-daemon seems to still work as a workaround too.

(0041120) Susan (reporter) 2021-07-26 14:03	still happening as of DF 47.05 on ubuntu 21.04.

(0041130) lethosor (manager) 2021-08-11 12:10	I can't reproduce this on Ubuntu 21.04 with X11+GNOME - are you using a different window manager or desktop environment?

(0041233) Susan (reporter) 2022-03-13 18:42	@lethosor: terribly sorry, only just saw this message! it was wayland+gnome rather than x11; unfortunately i don't have the ability to test on linux right now as my main computer has been in need of repair for some time.