Minetest chatroom keyboard acts strange

[Emojigit]

Minetest version

Minetest 5.5.0-dev-88783679c (Linux)
Using Irrlicht 1.9.0mt2
Using LuaJIT 2.1.0-beta3
BUILD_TYPE=Release
RUN_IN_PLACE=1
USE_CURL=1
USE_GETTEXT=1
USE_SOUND=1
USE_FREETYPE=1
STATIC_SHAREDIR="."
STATIC_LOCALEDIR="locale"

OS / Hardware

Operating system: Ubuntu 20.04 LTS
CPU: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz

GPU model: ?
OpenGL version: ?

Summary

Minetest chatroom keyboard acts strange makes me hard to type commands. for example, //unmark becomes //unmmrk, etc.

[Emojigit]

https://discord.com/channels/726004454075138119/726004454532579328/831847337059680256
This is a chatroom record in which the client used that strange version of minetest.

[Emojigit]

[sfan5]

Does this happen on 5.4.1 or with 5.5.0-dev? (please test both)
We also need more information on the environment: Keyboard layout? Any IME?

[Emojigit]

@sfan5

Does this happen on 5.4.1 or with 5.5.0-dev? (please test both)
We also need more information on the environment: Keyboard layout? Any IME?

Keyboard layout: QWERTY
I don't know what is IME
I will compile 5.4.1 soon

[sfan5]

IME -> https://en.wikipedia.org/wiki/Input_method

[Emojigit]

Does this happen on 5.4.1 or with 5.5.0-dev? (please test both)
We also need more information on the environment: Keyboard layout? Any IME?

No problem on 5.4.1 and 5.5.0-dev-88783679c

[Emojigit]

IME -> https://en.wikipedia.org/wiki/Input_method

English

[y5nw]

Regarding the IME issue: after the IME PRs got merged I noticed that the keyboard input might randomly "lock up" with Fcitx5 on ArchLinux (using us-altgr-intl and Pinyin) after some time, at least as of 52c0384. Currently I can reproduce it by holding F10 (i.e. continuously opening and closing the chat console on short intervals). However:

• While I can not enter anything or switch between keyboard layouts/imput methods after the keyboard input got "locked up", when I close the chat console (e.g. by double-clicking elsewhere) I could still move around.
• I could not reproduce this on a Debian VM without any IME (only the us-altgr-intl layout) with a106bfd. AltGr and dead keys worked fine as well.
• I have not tested this with other IMEs yet.
• Edit: Using IBus on the said Debian VM, I could not reproduce the behavior I experienced with Fcitx5. I could not reproduce this on Fcitx4 (on Debian) either.

[Emojigit]

Sometimes keyboard becomes "unavailable" on 5.5.0-dev-88783679c. Not tested on 5.4.1-stable.

[y5nw]

@Emojigit Try this Irrlicht patch and see if you can still reproduce the problem (apparently skipping XFilterEvent when the IME is not used is a bad idea ...). I tested this patch with a few IMEs (including without any IME) on a Debian VM and did not notice anything in particular other than the Bopomofo (IBus) IM somehow filtering out the F10 key event.

diff --git a/source/Irrlicht/CIrrDeviceLinux.cpp b/source/Irrlicht/CIrrDeviceLinux.cpp
index f482ec68e..ec3a52599 100644
--- a/source/Irrlicht/CIrrDeviceLinux.cpp
+++ b/source/Irrlicht/CIrrDeviceLinux.cpp
@@ -829,7 +829,7 @@ bool CIrrDeviceLinux::run()
 		{
 			XEvent event;
 			XNextEvent(XDisplay, &event);
-			if (acceptsIME() && XFilterEvent(&event, None))
+			if (XFilterEvent(&event, None))
 				continue;
 
 			switch (event.type)
@@ -1156,23 +1156,27 @@ bool CIrrDeviceLinux::run()
 				break;
 			} // end switch
 
-		} // end while
-
-		// Update IME information
-		if (XInputContext && GUIEnvironment)
-		{
-			gui::IGUIElement *elem = GUIEnvironment->getFocus();
-			if (elem && elem->acceptsIME())
+			// Update IME information
+			if (XInputContext && GUIEnvironment)
 			{
-				core::rect<s32> r = elem->getAbsolutePosition();
-				XPoint p;
-				p.x = (short)r.UpperLeftCorner.X;
-				p.y = (short)r.LowerRightCorner.Y;
-				XVaNestedList l = XVaCreateNestedList(0, XNSpotLocation, &p, NULL);
-				XSetICValues(XInputContext, XNPreeditAttributes, l, NULL);
-				XFree(l);
+				gui::IGUIElement *elem = GUIEnvironment->getFocus();
+				if (elem && elem->acceptsIME())
+				{
+					core::rect<s32> r = elem->getAbsolutePosition();
+					XPoint p;
+					p.x = (short)r.UpperLeftCorner.X;
+					p.y = (short)r.LowerRightCorner.Y;
+					XSetICFocus(XInputContext);
+					XVaNestedList l = XVaCreateNestedList(0, XNSpotLocation, &p, NULL);
+					XSetICValues(XInputContext, XNPreeditAttributes, l, NULL);
+					XFree(l);
+				} else {
+					XUnsetICFocus(XInputContext);
+				}
 			}
-		}
+
+		} // end while
+
 	}
 #endif //_IRR_COMPILE_WITH_X11_
 

Also, the XMODIFIERS environment variable includes the IM settings. Posting that might help as well (echo $XMODIFIERS)

[sfan5]

+ if (XFilterEvent(&event, None))

Not sure if that's a good idea.
This might need to be if (XFilterEvent(&event, acceptsIME() ? None : XWindow)) to match pre-IME behaviour.

[y5nw]

I thought None implies the window associated with the XEvent? https://www.x.org/releases/current/doc/man/man3/XFilterEvent.3.xhtml
Also, from my interpretation, XSetICFocus and XUnsetICFocus basically sets and unsets the focus to the input context (which, I suppose, is attached to the IME). In any case, I hope it is less ugly than skipping XFilterEvent when the IME is not needed.

[Emojigit]

Also, the XMODIFIERS environment variable includes the IM settings. Posting that might help as well (echo $XMODIFIERS)

$ echo $XMODIFIERS
@im=fcitx

[Emojigit]

Try this Irrlicht patch and see if you can still reproduce the problem (apparently skipping XFilterEvent when the IME is not used is a bad idea ...). I tested this patch with a few IMEs (including without any IME) on a Debian VM and did not notice anything in particular other than the Bopomofo (IBus) IM somehow filtering out the F10 key event.
cludes the IM settings. Posting that might help as well (echo $XMODIFIERS)

$ git apply /tmp/2 -v
Checking patch source/Irrlicht/CIrrDeviceLinux.cpp...
error: while searching for:
		{
			XEvent event;
			XNextEvent(XDisplay, &event);
			if (acceptsIME() && XFilterEvent(&event, None))
				continue;

			switch (event.type)

error: patch failed: source/Irrlicht/CIrrDeviceLinux.cpp:829
error: source/Irrlicht/CIrrDeviceLinux.cpp: patch does not apply

[Emojigit]

I can successfully apply that patch after I use --whitespace=fix

[sfan5]

@Emojigit More importantly, can you confirm that the patch fixes it for you?

I thought None implies the window associated with the XEvent? https://www.x.org/releases/current/doc/man/man3/XFilterEvent.3.xhtml

I think that too, but we determined that this somehow makes a difference when we prepared the IME PR (minetest/irrlicht#23 (comment)).

[y5nw]

I thought None implies the window associated with the XEvent? https://www.x.org/releases/current/doc/man/man3/XFilterEvent.3.xhtml

I think that too, but we determined that this somehow makes a difference when we prepared the IME PR (minetest/irrlicht#23 (comment)).

I think I was a bit messed up a bit earlier, and yes, that does make a difference. However, I am not sure if that is needed because from my local tests the IME was disabled with XUnsetICFocus alone when the input field loses focus.

[sfan5]

I determined the parameter does not make a difference and merged the original fix as:
minetest/irrlicht@21cb990