Sorry, I don't think you're going to love this answer, but there's not a lot X can do about it.

As mentioned in the Ubuntu bug, some games decide to grab the entire keyboard when running full-screen.  This is specified to override everything else and give that client sole, exclusive, use of the keyboard.  I'm not sure why they do it, but I'm guessing it's so they can be sure Alt-Tab doesn't accidentally trigger or something, which would be deliberately disabling hotkeys.

Anyway, if the game developers tell us there are shortcomings in our input model that we need to fix so they can stop grabbing, we'll be happy to take a look.  But for the moment, we're just doing what we're told, which is: grab the keyboard to the absolute exclusion of everyone else.

Thanks for your response.

Considering that pretty much every full-screen game I've played under Linux has suffered from this, I have to believe that it's unintentional on the game developers' part.

The fact is that we're now faced with a mountain of applications out there in the wild that are already suffering from this and will realistically never get fixed to use some alternate keyboard grabbing mechanism (assuming such a thing is even supplied by xorg and is neither obscure nor cumbersome to use). It therefore truly, realistically falls to xorg to decide whether or not to do something to resolve this issue that is resulting in a frustrating experience for many, many xorg end-users.


Without any knowledge of xorg's internals, I can think of two non-mutually-exclusive general design level ideas that might help alleviate the issue:

1. Some kind of xorg configuration option/mechanism could be provided to allow distribution creators, system administrators and/or end-users to choose to exclude the multimedia keys from the global keyboard grabbing mechanism.

2. Grabbing of multimedia keys could be spun out into a separate xorg API call or parameter (or whatever an xorg analog of that might be) that needs to be explicitly called/specified by the developer to signal that they really, really want to grab and handle those keys.


Call this a feature/enhancement request if you'd like (personally, however, I strongly feel that it is much more important than that due to a large impact on end-users) but please don't dismiss it out-of-hand.

Apologies if reopening the bug is a faux-pas. I'm not sure if my reply would be seen if I didn't do so.

Not a keyboard driver bug.  Over to the server, but I think this will just be 
closed.

I remember subscribing to this bug report many years ago. Too bad it's still present. Indeed, it does appear that almost *every* game that grabs input will grab multimedia keys as well. There are very few that make the exception - and I mean very few.

I believe Ben S. stated it correctly in comment #2. It does realistically fall onto Xorg - None of these developers would have wanted to make it happen like this and yet they all end up this way. So the issue lies with the implementation of keyboard grabbing. Isn't there a better way to make media key control apply less in blanket circumstances such as that?

If this isn't in the scope of Xorg's development, hopefully Wayland's design could have this thought in the process. Regardless, it's a pretty nasty bug that wouldn't best be solved by asking all of the developers of every fullscreen app ever to go back and do something. If so many instances are affected, there's something wrong with the implementation.

Hi,

I am a little bit aware about this problem.

It seems think that issue is in how full-screen games are launched inside desktop environments. Initially, when user interacts with their desktop all keyboard event are handled by window manager. When focus is on application's window all keyboard events are dispatched to that application by window manager. This way standard keyboard shorcuts work: window manager just handles all input.

In window mode games are not exceptions: all events are dispatched to them by window manager. But when game goes full screen window manager occasionally looses ability to handle any keyboard events (as far as all input events). This is well known libSDL 1.2 issue which is going to be fixed in 2.0 major release. There are also some workarounds for this issue.

I am also not aware about internals of X server, but I can propose the idea:
Initially all events are anyway captured by X server. So the X server should provide special input API (don't know if there already one exists) which allows any application exclusively lock keyboard shortcuts. This "shortcut lock" should be done so that any other application will not ever receive it until first one unlock it. Also after locking shortcut by one application other applications should not be able to lock it.
This is just bare idea. If such API already exists then its not X issue: all required abilities were provided, it a task of desktop environment to use it.  and we should post bugs to window manager's trackers.


Thanks!

Ben, You may use this workaround: https://bbs.archlinux.org/viewtopic.php?pid=735271#p735271 until issue will be resolved on higher level.

This issue got *much* worse recently, it now affects keyboard layout switching as well, so many applications like tuxpaint became completely unusable.

Example: In Ubuntu 14.04, I run `tuxpaint --fullscreen`. I press Win+Space, the Gnome-defined method to switch my keyboard layout from "us,gr" to "gr,us".
unity-settings-daemon cannot read the layout change because tuxpaint has the keyboard grab.
(It's the same in other distros too, it's not Ubuntu specific)

So I can't type Greek with the tuxpaint Text tool, making tuxpaint completely useless in fullscreen mode.

Until some years ago, Gnome allowed XKB to manage the layout switching, which worked fine even in fullscreen applications.
It no longer allows it, they try to manage it with gnome-settings-daemon etc.

If there's no intention to fix this in Xorg, please mention it here, so that we can show that response to Gnome developers and tell them to let XKB manage the keyboard layouts instead.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/564.