Key combinations are no longer recognized and can not be bound in the keybinding dialog anymore, which means inputing a “plus” is not possible without a keypad (Linux, X11/SDL, Neo 2 layout)

[erlehmann]

Minetest version

5.7.0-279-gb1dec37ad

Active renderer

No response

Irrlicht device

X11

Operating system and version

Debian 11.7

CPU model

Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz

GPU model

Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

OpenGL version

1.4

Summary

Using MInetest on X11 with the Neo2 keyboard layout, Minetest does not recognize me inputting a plus sign by holding ISO_Level3_Shift (the key above the left shift key on a QWERTY or QWERTZ keyboard) and the “b” key for a game action. It still works for text input in chat.

This used to work in earlier versions of Minetest, at least back in 5.4.1 it definitely did work.

Steps to reproduce

1. Set your keyboard layout to Neo 2 on X11.
2. Start Minetest.
3. Try to increase render distance by inputting a plus sign (“+”) with ISO_Level3_Shift and the “b” key.
4. Notice that nothing happens except that the focus on the inventory bar moves to the left.
5. Try to bind something to the plus sign (“+”) in the keyboard dialog.
6. Notice that binding to the plus sign is not possible anymore.

Similar bugs

Just to point it out in advance: The following issues are not duplicates of this one.

#12507 - plus key allegedly not working on Mac OS
#13890 - plus is now a different key from numpad plus

[erlehmann]

It seems that the issue here is that ISO_Level3_Shift is not detected as a modifier anymore by the code handling the keybindings – so the binding can be set to ISO_Level3_Shift, but not to the plus character.

This means that users with Neo2 keyboard layout can no longer input a plus sign at all unless they have a numpad (as Numpad plus is correctly detected).

[grorp]

Have you tested with USE_SDL2 as well?

[erlehmann]

@grorp I have no idea. Please explain in more detail what I should test.

[grorp]

I meant compiling Minetest with the SDL Irrlicht device (USE_SDL2 CMake flag) and testing whether the issue still occurs. Some input bugs are magically fixed if you compile with SDL.

[erlehmann]

@grorp I can try. But why is that flag not the default for compiling for GNU/Linux then?

[erlehmann]

@grorp so I did this: cmake . -DRUN_IN_PLACE=TRUE -DUSE_SDL2=TRUE and then compiled Minetest using make -j1 and then got:

[…]
[ 35%] Building CXX object lib/irrlichtmt/source/Irrlicht/CMakeFiles/IRROTHEROBJ.dir/CIrrDeviceSDL.cpp.o
$HOME/share/src/games/minetest/lib/irrlichtmt/source/Irrlicht/CIrrDeviceSDL.cpp: In member function ‘virtual bool irr::CIrrDeviceSDL::run()’:
$HOME/share/src/games/minetest/lib/irrlichtmt/source/Irrlicht/CIrrDeviceSDL.cpp:558:48: error: ‘SDL_MouseWheelEvent’ {aka ‘struct SDL_MouseWheelEvent’} has no member named ‘preciseY’
  558 |    irrevent.MouseInput.Wheel = SDL_event.wheel.preciseY;
      |                                                ^~~~~~~~
make[2]: *** [lib/irrlichtmt/source/Irrlicht/CMakeFiles/IRROTHEROBJ.dir/build.make:82: lib/irrlichtmt/source/Irrlicht/CMakeFiles/IRROTHEROBJ.dir/CIrrDeviceSDL.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:637: lib/irrlichtmt/source/Irrlicht/CMakeFiles/IRROTHEROBJ.dir/all] Fehler 2
make: *** [Makefile:171: all] Fehler 2
# exited 2

[grorp]

But why is that flag not the default for compiling for GNU/Linux then?

It is supposed to become the default soon.

error: ‘SDL_MouseWheelEvent’ {aka ‘struct SDL_MouseWheelEvent’} has no member named ‘preciseY’

Looks like your SDL is outdated, that field was added in 2.0.18 according to
https://wiki.libsdl.org/SDL2/SDL_MouseWheelEvent.

[rollerozxa]

The latest version of SDL2 in Debian oldstable (version 11, bullseye) is 2.0.14, so it's probably a good idea to use that as the minimum supported version of SDL2 and gating anything requring a newer version behind preprocessor directives.

[erlehmann]

Even when commenting out the mousewheel code (which seems to be the only code that uses this newer constant), using SDL2 does not seem fix it. I assume the underlying isssue here is that all keys except the escape key can be bound now, i.e. there is no way to input characters anymore.

I guess this is bad for anyone who has a non-standard keyboard layout or wants to bind stuff to key combinations?

[erlehmann]

I think there exists a bigger conceptual problem here: By changing the detection from “character that is input” to “key that is pressed”, it may have become impossible to bind functionality to key combinations (something that was possible before when characters were input using key combination). Neo2 uses a key combination for the plus sign, therefore this bug occurs.

I think this means that it can not be easily mitigated by just using SDL, as it represents a conceptual shift in keymapping.

Edit: The plus-sign-related regression reported in #13890 may have the same root cause (but is not the same issue as this ore).

[grorp]

@erlehmann is your problem fixed if you revert #13773?

[erlehmann]

@grorp reverting commit d57c936 does fix it in a way: Key combinations are recognized again (i.e. I can input a “+”), but I can not actually input that as a valid combination in the keybinding dialog because ISO_Level3_Shift is detected as a bindable key (but then again I am not sure if I ever tried that again before and + is already configured by default).

[grorp]

Fixed by #13942.