We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4094

Summary: No SDL_TEXTEDITING after pressing Alt key on Raspberry Pi Linux
Product: SDL Reporter: q3dev <ioq3>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: markomizdrak, sezeroz
Version: 2.0.7   
Hardware: ARM   
OS: Linux   
Attachments: Patch for SDL_evdev_kbd.c

Description q3dev 2018-02-25 02:36:42 UTC 
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
Comment 1 Sam Lantinga 2018-02-25 17:44:53 UTC 
Ryan, can you look at this for SDL 2.0.8 today?
Comment 2 q3dev 2018-03-05 01:01:28 UTC 
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.
Comment 3 q3dev 2018-03-11 22:14:52 UTC 
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.
Comment 4 q3dev 2018-03-24 18:54:59 UTC 
Created attachment 3195 [details]
Patch for SDL_evdev_kbd.c
Comment 5 q3dev 2018-03-24 18:55:54 UTC 
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.
Comment 6 Ryan C. Gordon 2018-03-24 20:08:01 UTC 
(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.
Comment 7 q3dev 2018-05-06 15:45:44 UTC 
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.
Comment 8 M Miz 2018-05-16 10:24:09 UTC 
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.
Comment 9 Sam Lantinga 2018-06-14 07:52:15 UTC 
Fixed, thanks!
https://hg.libsdl.org/SDL/rev/7f3c9bffada4