SDL_HINT_GRAB_KEYBOARD not working

I’m trying to use SDL_SetHint(SDL_HINT_GRAB_KEYBOARD, “0”) to disable keyboard events. However, i’m still receiving keyboard events. I tried on Windows and Mac, also with 3 different SDL2 versions.

For example, if I compile FFplay (from ffmpeg), pressing ‘q’ will quit. Is this a known issue?

“(Not) grabbing the keyboard” doesn’t mean you don’t get keyboard input at all, it’s about whether keyboard input can also be handled by the desktop environment/window manager.

If your SDL app does grab the keyboard, global keyboard shortcuts/hotkeys won’t work, so you can’t switch to another applications with ALT-TAB or open the start menu with the windows key or turn up/down the speaker volume with volume keys etc.
If it does not grab it (which is the default), these global shortcuts will work, and you’ll still get keyboard events for everything that is not handled by whatever handles those global shortcuts.

Hope that clears it up :slight_smile:

If you want to disable keyboard events, just set some global flag and, wherever you call SDL_PollEvent(), ignore/skip keyboard events if the flag is set.

Thank you Daniel. I misunderstood the functionnality. It’s all clear now. :slight_smile:

I’m having a problem with SDL2, MacOS and Qt. When I create an SDL window, I receive key twice in my Qt textbox. So if I type, the keys are doubled. So I thought that disabling SDL keyboard hook would help. I guess this is another topic.

Why is an option to do this even in SDL? Those global commands are expected functionality, and keeping the system working correctly is more important than whatever your game is doing. If your game is full-screen, and I can’t get out of it with ALT-TAB, and I can’t get out of it by opening the Start menu with with the Windows key or CTRL-ESC… and then there’s a glitch and the game hangs, then I’m trapped and you’ve managed to turn your bug that should only affect this one game into a system crash.

The only reason for any program to ever take over these commands is if it’s a program that controls a computer. (VMs, Remote Desktop, etc.) It has no place in a game development framework, where the only use case is to break things. Please remove this horrifying “feature” from SDL immediately.

DOSBox uses SDL, I think. That is a VM!

What happens when you want to build a VM or remote desktop client with SDL, though?

DOSBox uses SDL, I think. That is a VM!

And I’m very glad that it doesn’t need to care about Windows shortcut keys because it’s a DOS box. I’ve had DOS games in DOSBox hang on me before, and it would severely suck if I wasn’t able to ALT-TAB back to Windows in order to kill DOSBox.

In such an extreme edge case, the developer can figure out how to do that manually when it’s actually needed. It’s still a very bad idea to make it a standard feature on a framework whose target audience is not VMs or remote desktop clients, but game development.

The design principle is known as “the pit of success:” make it easy to do the right thing, even by accident, and hard to do the wrong thing, especially by accident. For a game, disabling system commands is categorically the wrong thing. Therefore, putting it in a gamedev framework – especially with an innocuous name that makes it look like something you might want to do if you want to enable keyboard input, as we see from the post that started this thread – is the wrong thing to do. This feature should be removed.

Mason_Wheeler, I understand your point of you. However, if this feature is disabled by default, do you observe any bad side effects with it? I do see some strange keyboard things with macos and wonder if it might be related to this.

At least on Windows opening the task manager with Ctrl-Alt-Del should still work, I think?
On Linux you might still be able to get to a console with Ctrl-Alt-F1, unless it’s disabled by your distro.

It makes sense that this exists (and that you can enable it with an environment variable) because some people really hate when accidentally pressing the windows key takes focus away from their game.

I’m happy to add a comment to SDL_hints.h saying “use this at your own risk,” but we aren’t removing useful functionality because it can cause problems in failure cases.

1 Like

It makes sense that this exists (and that you can enable it with an environment variable) because some people really hate when accidentally pressing the windows key takes focus away from their game.

Then they shouldn’t be pressing the Windows key. I can’t recall the last time I saw a new game where CTRL, ALT, and SHIFT were in-game controls. There was a big fad for that back in the 90s and early 2000s, but we’ve moved away from it for good reasons.

The problem is, they aren’t using it at their own risk. The risk isn’t to the developers who use this, it’s to their end users.

And it’s not just failure cases that’s the problem; that’s just the worst-case scenario. A modern computer is supposed to be a multitasking device. If a user wants to pause the game and do something else, from checking email to taking a video call to looking up help with the part of the game they’re on in an online strategy guide or a YouTube video, and they can’t do that without shutting down the game first and then restarting and reloading afterwards, the basic functionality of their computer is broken.

Disabling ALT-TAB breaks the user’s computer. This is not useful functionality for SDL’s target audience; it is harmful functionality, and as such it should not exist in SDL.

Players actually demand this.

And if you ungrab the input when the user pauses the game, they can use Alt-Tab to switch to another application - if the game is running in windowed mode, they can even use the mouse to switch.

Then they shouldn’t be pressing the Windows key. I can’t recall the last time I saw a new game where CTRL, ALT, and SHIFT were in-game controls.

At least Shift is very common, and so is Z (or Y or whatever key is on the lower left) so accidentally hitting the Windows key isn’t that unrealistic.

1 Like