Bug Description

When I'm playing games in fullscreen mode, I cannot change the volume (laptop, HP tx2115nr with Jaunty) using my notebook keys. It's not possible to use my Play/Pause/Stop hotkeys (right side of my screen).

Keys that are defined in gnome should always be catched and never reach the application under focus.
This seems to me a metacity/compiz bug.

Reasoning:
- we loose functionality in SDL games if the keys aren't being catched at a lower level of the stack
- certain fullscreen players leave fullscreen on any keypress (like flash)
- possible overlaps of application based shortcuts are bugs: they make the usage of the gnome-keybindings inconsistent and dangerous. (imagine alt+tab being binded to something destructive)

I don't see how this could be a gnome-settings-daemon issue. gnome-settings-daemon has a passive grab on the volume keys, and it will get temporary focus during a keypress so that the keypresses are routed to g-s-d. If a fullscreen game has an active grab on the keyboard or pointer, then there is no way in the X protocol to break this and no way for g-s-d to get the keypresses

Actually, in all games (running natively). The games took control of the
keyboard, so it's not possible to change volume, mute sound, use
multimedia keys to stop/play musics.

Games using Wine doesn't have this problem. They don't capture
completely the keyboard (it's even possible to rotate compiz cube).

Em Sex, 2010-05-07 às 14:39 +0000, Matthew Paul Thomas escreveu:
> Oops, sorry, I missed the part where this bug was in Jaunty.
>
> Leonardo, can you give some examples of games where Ubuntu has the
> problem? Does it have the same problem in later Ubuntu versions?
>

So it is a limitation of X.org? I think that we have 2 types of
fullscreen apps here:

- "Fake" fullscreen: Wine apps, Firefox, Totem. They don't grab the
keyboard. Basically, they hide the window decoration and fill the screen
with the window.

- "True" fullscreen: Games. They grab the keyboard control, so Gnome
can't do anything. If an app like this crashes, you can't even call
System Monitor to kill it (like ctrl + alt + del in Windows).

Would be nice if the Games had the same behaviour than the other
programs.

Em Sex, 2010-05-07 às 15:18 +0000, Chris Coulson escreveu:
> I don't see how this could be a gnome-settings-daemon issue. gnome-
> settings-daemon has a passive grab on the volume keys, and it will get
> temporary focus during a keypress so that the keypresses are routed to
> g-s-d. If a fullscreen game has an active grab on the keyboard or
> pointer, then there is no way in the X protocol to break this and no way
> for g-s-d to get the keypresses
>

It's not just annoying (especially when playing loud *shooting* games) it's even kinda security lack, imagine an unwanted program (viruslike) steals the keyboard an forces you to shutdown your PC in order to regain control...

I confirm this bug. Really annoying.
The solution should be as close to the hardware as possible, so no aplication have ability to lock it.

For example , when I push volume up button in my laptop
- information of pressing the key is processen in very deep level, and volume changes
- no aplication, is informed about pressing any key at all.
- informing apropriate system component about volume change, needed for example to notify-osd window about volume change.

Example is very simple and maybe not very correct, but the point is:
- processing such keys in deep level of system.

This would solve bug #344978 as well, and help avoid other similar bugs .

Basicly volume control buttons should work like ( or almost like ) completely analog hardware potentiometer connected directly to laptop speakers. In such configuration there is no problems and no place for bugs any at all.

In many full-screen applications, multimedia keyboard keys (e.g. volume up/down, mute, etc.) seem to get locked by the application and not passed through to the desktop manager. This makes it impossible to, for example, adjust or mute the system volume while playing a full-screen game.

This issue still exists in Xubuntu 11.10 (and presumably Ubuntu 11.10). Unfortunately, gizmod is no longer an easy solution because it was dropped from the Ubuntu 11.10 repositories due to the fact that it no longer compiles out of the box with the latest version of the Boost libraries.

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.

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.

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.

This is still a bug in 12.04 and it will presumably remain an issue for the foreseeable future. Has there been any indication about a potential fix for this, or is this an architectural issue? Will this potentially be solved by Wayland?

I would think that the rise of gaming on the Linux desktop (through the Ubuntu Software Center, the Humble Indie Bundles, and the coming launch of Steam for Ubuntu) would make this a bigger issue in the near future.

There is a workaround for this. I used to use this on Debian with a small set of packages.

Using acpid and amixer one can set an acpid rule to react at volume keys at a deeper level than the default sound daemon.
Use acpi_listen to discover your key codes and write a script like this (for example when pressing volume up):
amixer set Master 5+
This is more ALSA related, but pulseaudio will adjust its volume as well.

This is extremely annoying when a fullscreen application crashes. Your average user who doesn't know about the Ctrl+Alt+PrntScrn+K and Ctrl+Alt+F1 tricks will assume that the operating system crashed which is about the most significant usability issue you could possibly have.

And even for the experienced user, you either have to Ctrl+Alt+PrntScrn+K back to the login screen and have all your applications terminate, or you have to go to a fullscreen shell, terminate the process, exit the shell, and return to X. All just because some user application entered an infinite loop. Bad, bad, bad design.

I believe we should have some global shortcut, like Ctrl + Alt + Del on
Windows, that calls a task manager to allow the user to kill the
problematic process.

2012/10/8 Matt Pharoah <email address hidden>

> This is extremely annoying when a fullscreen application crashes. Your
> average user who doesn't know about the Ctrl+Alt+PrntScrn+K and
> Ctrl+Alt+F1 tricks will assume that the operating system crashed which
> is about the most significant usability issue you could possibly have.
>
> And even for the experienced user, you either have to
> Ctrl+Alt+PrntScrn+K back to the login screen and have all your
> applications terminate, or you have to go to a fullscreen shell,
> terminate the process, exit the shell, and return to X. All just because
> some user application entered an infinite loop. Bad, bad, bad design.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/388547
>
> Title:
> Volume keys don't work inside a full-screen game
>
> Status in One Hundred Paper Cuts:
> Confirmed
> Status in X.Org X server:
> Unknown
> Status in “gnome-settings-daemon” package in Ubuntu:
> Confirmed
>
> Bug description:
> When I'm playing games in fullscreen mode, I cannot change the volume
> (laptop, HP tx2115nr with Jaunty) using my notebook keys. It's not
> possible to use my Play/Pause/Stop hotkeys (right side of my screen).
>
> I would like to change my volume without have to exit the game.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/hundredpapercuts/+bug/388547/+subscriptions
>

Leonardo: That's a good idea, but it would never work due to the fact that the entire issue here is that Ubuntu allows apps to take control of the entire keyboard.

No special key combinations or multimedia keys are serviced by the window manager when full-screen games are running, so the only key combinations that work are those serviced by the OS and maybe the session manager.

The real fix is to mimic the behavior of other OSes in not allowing full-screen applications to completely override the window manager's keyboard handler. Unfortunately this is an X.Org issue, and they're probably never going to fix it because they just don't understand why they should have to.

Ubuntu will never be taken seriously as a desktop gaming platform until this is resolved. Maybe Valve will fix it for them as part of trying to make Ubuntu into a Steam platform :)

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.

Same issue in 12.04 Ubuntu.
I would like to see steam games continue to prosper and release more to run on Linux but this is a major issue to my enjoyment of the games!
So before I start a game I should have to remember what the appropriate volume level is before starting the game and waiting for the menu to load.

Volume controls work in ever application I know of in windowed mode.
And doesn't work in steam games full screen.