This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch for SDL_evdev_kbd.c (SDL_evdev_kbd.patch, text/plain, 2018-03-24 18:54:59 +0000, 369 bytes)

Reported in version: 2.0.7
Reported for operating system, platform: Linux, ARM

Comments on the original bug report:

On 2018-02-25 02:36:42 +0000, q3dev wrote:

I’m having the same issue that others have reported with no SDL_TEXTEDITING after pressing the Alt key on the Raspberry Pi with the latest Raspbian Stretch.

https://discourse.libsdl.org/t/no-sdl-textediting-after-pressing-alt-key-on-linux/23904

Tested with SDL2-2.0.7 and SDL-ce4bc0462ae5.

Bug report 3803 was originally filed for this, but I wasn’t aware at the time that a specific keypress was triggering the issue, so there wasn’t any way to reliably reproduce the problem.

For testing, the pi user is a member of the “input”, “video”, and “tty” groups. I checked text output with evtest and ioquake3’s keyboard diagnostics (set in_keyboardDebug “1”), and the keypresses are seen by both, but not registered in the game console after pressing either Alt key. Tested with OpenGL ES "rpi" driver. This version of the game uses multiple rpaths to search for SDL libraries, so delete the SDL2-2.0.4 libraries in /usr/local/lib/q3lite or they will be used instead of the SDL2 libraries in the /usr/local/lib system directory.

If needed for testing, the latest game source code is available on GitHub. Thank you!

https://github.com/cdev-tux/q3lite

SDL2 configure options:
./configure --host=arm-raspberry-linux-gnueabihf
--enable-alsa
--disable-alsa-shared
--disable-pulseaudio
--disable-esd
--disable-dummyaudio
--disable-diskaudio
--enable-video-kmsdrm
--enable-video-rpi
--disable-video-x11
--disable-video-dummy
--disable-video-mir
--disable-video-wayland
--disable-video-vivante
--disable-video-vulkan
--disable-video-opengl

SDL2 Configure Summary:
Building Shared Libraries
Building Static Libraries
Enabled modules : atomic audio video render events joystick haptic power filesystem threads timers file loadso cpuinfo assembly
Assembly Math :
Audio drivers : oss alsa
Video drivers : rpi kmsdrm(dynamic) opengl_es1 opengl_es2
Input drivers : linuxev linuxkd
Using libsamplerate : YES
Using libudev : YES
Using dbus : YES
Using ime : YES
Using ibus : YES
Using fcitx : NO

On 2018-02-25 17:44:53 +0000, Sam Lantinga wrote:

Ryan, can you look at this for SDL 2.0.8 today?

On 2018-03-05 01:01:28 +0000, q3dev wrote:

I've been doing more testing to try and figure out what's causing this. Pressing either Ctrl key also stops text input in the game console. The Alt and Ctrl keys are both modifiers, and appear to have normal output when logged by the games built-in keyboard diagnostics:

• Scancode: 0xe6(Right Alt) Sym: 0x400000e6(Right Alt) KMOD_RALT Q:0x88(ALT)
  Scancode: 0xe6(Right Alt) Sym: 0x400000e6(Right Alt) Q:0x88(ALT)

• Scancode: 0xe2(Left Alt) Sym: 0x400000e2(Left Alt) KMOD_LALT Q:0x88(ALT)
  Scancode: 0xe2(Left Alt) Sym: 0x400000e2(Left Alt) Q:0x88(ALT)

• Scancode: 0xe4(Right Ctrl) Sym: 0x400000e4(Right Ctrl) KMOD_RCTRL Q:0x89(CTRL)
  Scancode: 0xe4(Right Ctrl) Sym: 0x400000e4(Right Ctrl) Q:0x89(CTRL)

• Scancode: 0xe0(Left Ctrl) Sym: 0x400000e0(Left Ctrl) KMOD_LCTRL Q:0x89(CTRL)
  Scancode: 0xe0(Left Ctrl) Sym: 0x400000e0(Left Ctrl) Q:0x89(CTRL)

The shift key is also a modifier but it doesn't affect the text input in the console. Maybe there's different handling of these keys when SDL2 is configured with --disable-video-x11? Thank you for your help with this.

On 2018-03-11 22:14:52 +0000, q3dev wrote:

There's a difference in keydown events being returned by 2.0.4 and 2.0.8.

Here's the left Alt keydown/keyup events returned by 2.0.4:

• Scancode: 0xe2(Left Alt) Sym: 0x400000e2(Left Alt) MOD: 0x0000 Q:0x88(ALT)
  Scancode: 0xe2(Left Alt) Sym: 0x400000e2(Left Alt) MOD: 0x0000 Q:0x88(ALT)

Here's the left Alt keydown/keyup events returned by 2.0.8:

• Scancode: 0xe2(Left Alt) Sym: 0x400000e2(Left Alt) MOD: 0x0100 KMOD_LALT Q:0x88(ALT)
  Scancode: 0xe2(Left Alt) Sym: 0x400000e2(Left Alt) MOD: 0x0000 Q:0x88(ALT)

The keydown modifier value is different. The changeset where things stopped working had some code that changed the modifier value. https://hg.libsdl.org/SDL/rev/0f79dd727ed6#l1.795

After pressing either Alt or Ctrl key on 2.0.8, the SDL_TEXTINPUT stops. Any help that you can offer would be appreciated. Thank you.

On 2018-03-24 18:54:59 +0000, q3dev wrote:

Created attachment 3195
Patch for SDL_evdev_kbd.c

On 2018-03-24 18:55:54 +0000, q3dev wrote:

I believe I found the issue in /src/core/linux/SDL_evdev_kbd.c. I placed a number of printf statements in function SDL_EVDEV_kbd_keycode and found that pressing either Alt or Ctrl key changes the value of the shift_final variable. There's nothing to reset the kbd->shift_state so the shift_final variable stays set for all subsequent key presses. Resetting the kbd->shift_state = 0 at the end of the function appears to fix the problem. Please see the attached patch file. Thank you.

On 2018-03-24 20:08:01 +0000, Ryan C. Gordon wrote:

(In reply to q3dev from comment # 5)

I believe I found the issue in /src/core/linux/SDL_evdev_kbd.c. I placed a
number of printf statements in function SDL_EVDEV_kbd_keycode and found that
pressing either Alt or Ctrl key changes the value of the shift_final
variable. There's nothing to reset the kbd->shift_state so the shift_final
variable stays set for all subsequent key presses. Resetting the
kbd->shift_state = 0 at the end of the function appears to fix the problem.
Please see the attached patch file. Thank you.

shift_state should be reset in k_shift(), which is called indirectly by this line in that same function:

    (*k_handler[type])(kbd, keysym & 0xff, !down);

Resetting it unconditionally is probably not correct; it's possible k_shift isn't handling keyup events correctly. I'll trace in there and see what's up.

--ryan.

On 2018-05-06 15:45:44 +0000, q3dev wrote:

I just wanted to check back and see if you’ve had time to look at this. I have a user with the same issue on a different Linux platform. Any help that you could offer would be greatly appreciated. Thank you for your help with this.

On 2018-05-16 10:24:09 +0000, M Miz wrote:

I'm having the same issue. I have noticed the problem is not present when launching without a windowing environment. (Stretch Lite or Stretch rebooted into non-windowed environment). I don't know if that helps find the cause.

On 2018-06-14 07:52:15 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/7f3c9bffada4