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 3611 - Keyboard input "spills" out to the background console, even when grabbed
Summary: Keyboard input "spills" out to the background console, even when grabbed
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 2.0.5
Hardware: ARM Linux
: P2 normal
Assignee: Manuel Alfayate Corchete
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.16
Depends on:
Blocks:
 
Reported: 2017-03-20 13:01 UTC by midwan
Modified: 2021-01-30 16:26 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description midwan 2017-03-20 13:01:37 UTC 
Hi people,

I'm running SDL2 on a Pi 3 for an Amiga emulator I'm currently maintaining. I had to compile SDL2 from source to include support for running full screen applications from the console, otherwise we need to be under X11 (and that's a bit of an overhead for this project).

I've been trying to find out why all keyboard input for my SDL2 application, spills out to the background console. Here's what I mean:

- Boot in the Linux console.
- Launch an SDL2 application (in my case, it's an Amiga emulator for the Raspberry Pi, but I saw the same behavior on a few other SDL2 applications also)
- Press keys on the keyboard (some are handled by the application, some may not be)
- When you exit the application, all the keys pressed are shown in the console, like you were pressing those keys there.

I'm not sure if this is a known issue or if there's a known workaround, as so far I haven't been able to fix it or find a way around it.

I've tried using SDL_SetHint(SDL_HINT_GRAB_KEYBOARD, "1") right after I initialize SDL_Init().
I've also tried initializing the SDL Window with the SDL_WINDOW_INPUT_GRABBED flag set.

No difference unfortunately, I still get the same behavior.

Using SDL1.2 on the same application, does not show the same problem.

Does anyone have a clue on what to look for?
Comment 1 midwan 2017-05-20 12:56:44 UTC 
Any progress with this?

As a bug, it can manifest into a quite an ugly situation: Imagine someone typing something nasty withing the SDL2 application (like "sudo rm -F /boot"), it will get spilled to the console and executed if they hit Enter.
Comment 2 Sam Lantinga 2017-08-11 19:00:54 UTC 
Can you try the latest snapshot?
http://www.libsdl.org/tmp/SDL-2.0.zip

This should have been fixed in this commit:
https://hg.libsdl.org/SDL/rev/fe9c7d01a093
Comment 3 midwan 2017-08-11 20:19:25 UTC 
Of course, I need a few days before I can run a test and I'll report back.
Thanks!
Comment 4 q3dev 2018-03-01 22:15:30 UTC 
I'm having the same issue with keypresses leaking back to the x11 desktop when SDL2 is compiled with --disable-video-x11. 

Tested on Raspberry Pi 3 with SDL2-2.0.8 and latest Raspbian Stretch.  Thank you!

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 5 midwan 2019-01-26 20:14:45 UTC 
It's been a while, but I'm afraid I need to come back to this one.

When running an SDL2 app from the console, it seems to work normally now (using the latest SDL2 from Mercurial).

However, if I run the same app as a service, then this bug manifests itself again - I get keyboard input "split" in the console behind.
Comment 6 midwan 2020-12-20 11:06:00 UTC 
This still is an issue, at least for some users, even with the latest 2.0.12.
We've had a related bug report about it today: https://github.com/midwan/amiberry/issues/748

It seems to be triggered only when running from the console (with no X11 loaded!), using KMSDRM for example.

Do we have any progress update on it?
Comment 7 Sam Lantinga 2020-12-20 20:16:46 UTC 
I don't have a test setup for this. Manuel, can you look at this when you have time after 2.0.14 release?

Thanks!
Comment 8 Manuel Alfayate Corchete 2021-01-30 15:09:58 UTC 
This issue has no direct relationship with the KMSDRM backend, I believe, but affects the backend indirectly.

I am not seeing it happen unless I launch an SDL2 program via SSH. Running the program on a local TTY, there is no key leakage to the console.


The code that mutes the keyboard is exactly this one:

https://hg.libsdl.org/SDL/file/c9d9e7ec5bf6/src/core/linux/SDL_evdev_kbd.c#l393

...But that "trick" only works for local TTYs.
I don't know much more about TTY keyboard, what's done there should be enough to prevent leakage.
I don't know in what other situations this could be happening, other than trying to launch the program over SSH.
Comment 9 Cameron Gutman 2021-01-30 16:26:10 UTC 
What we probably want is EVIOCGRAB on the keyboard fd. We can make that the default behavior or plumb it through the new SetWindowKeyboardGrab() stuff I added recently.