Volume keys don't work inside a full-screen game

Bug #388547 reported by Leonardo Torok
206
This bug affects 42 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Confirmed
Low
Unassigned
X.Org X server
New
Unknown
gnome-settings-daemon (Ubuntu)
Confirmed
Low
Unassigned

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.

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote :

I think the solution to this bug, would also take care of https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/344978

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)

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I don't think Notify-OSD is the cause for this. The problem for that bug report is a Flash player problem. This problem has been around for a while, too:

http://brainstorm.ubuntu.com/idea/7916/

Since I can't find another report on this issue (surprisingly), I'm confirming it.

Changed in hundredpapercuts:
status: New → Confirmed
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

This is a regression. In Ubuntu 9.04, I could change the volume while playing (for example) Briquolo or Hedgewars. In 10.04, I can't. I don't remember whether I could in 9.10.

summary: - fullscreen games + volume control
+ Volume keys don't work inside a full-screen game (regression)
summary: - Volume keys don't work inside a full-screen game (regression)
+ Volume keys don't work inside a full-screen game
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

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?

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

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

Revision history for this message
Leonardo Torok (leotorok) wrote : Re: [Bug 388547] Re: fullscreen games + volume control

In 9.10 it wasn't possible too.

Em Sex, 2010-05-07 às 14:35 +0000, Matthew Paul Thomas escreveu:
> This is a regression. In Ubuntu 9.04, I could change the volume while
> playing (for example) Briquolo or Hedgewars. In 10.04, I can't. I don't
> remember whether I could in 9.10.
>
> ** Also affects: gnome-settings-daemon (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Summary changed:
>
> - fullscreen games + volume control
> + Volume keys don't work inside a full-screen game (regression)
>
> ** Summary changed:
>
> - Volume keys don't work inside a full-screen game (regression)
> + Volume keys don't work inside a full-screen game
>

Revision history for this message
Leonardo Torok (leotorok) wrote : Re: [Bug 388547] Re: Volume keys don't work inside a full-screen game

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?
>

Revision history for this message
Leonardo Torok (leotorok) wrote :

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
>

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
Revision history for this message
Arkashkin (arkashkin) wrote :

I have the same problem on Ubuntu 10.04... It is very annoying, when a game is running I can't lower it's sound...

Revision history for this message
Sheridan Hutchinson (sheridan-shezza) wrote :

My view is that in terms of usability, this is very poor.

People who game in windows expect their keys on their keyboard to work all the time, not just inside specific use-cases.

What are our options for a solution?

Revision history for this message
Justin J Stark (fromlaunchpad-justinjstark) wrote :

If anyone has a workaround for this, please post it here. I tried using xkeybinds but it also does not work when a full screen game hijacks the keyboard input.

Revision history for this message
Ben Shadwick (benshadwick) wrote :

This affects me as well in Ubuntu 10.10 x64 while playing the Linux versions of several of the games in the Humble Indie Bundles.

Revision history for this message
Justin J Stark (fromlaunchpad-justinjstark) wrote :

One workaround is to use gizmod as described in the following ubuntu forum thread.

http://ubuntuforums.org/showthread.php?t=1585664

Revision history for this message
Atheist1993 (atheist1993) wrote :

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...

Revision history for this message
c49 (c49) wrote :

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.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Ben Shadwick (benshadwick) wrote :

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.

Observed in Ubuntu & Xubuntu 10.04/10.10/11.04/11.10. See related URL for long-standing Ubuntu bug report.

Revision history for this message
Ben Shadwick (benshadwick) wrote :

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.

Revision history for this message
In , Daniel Stone (daniels) wrote :

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.

Revision history for this message
In , Ben Shadwick (benshadwick) wrote :

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.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

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

Revision history for this message
Fabio Andrade (fburla-deactivatedaccount) wrote :

I also have this problem. Keyboard/laptop volume controls won't work while running a full screen game.

This is a basic feature we have in Windows, and fixing this would help people have a smooth transition to gaming on GNU/Linux.

Does anybody know if there is any distro that have corrected this issue?

Revision history for this message
In , Brettcornwall-1 (brettcornwall-1) wrote :

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.

Revision history for this message
Colby Butler (popejamal) wrote :

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.

Revision history for this message
Valerio (ubase133) wrote :

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.

Revision history for this message
Matt Pharoah (mpharoah) wrote :

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.

Revision history for this message
Leonardo Torok (leotorok) wrote :

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
>

Revision history for this message
Ben Shadwick (benshadwick) wrote :

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 :)

Revision history for this message
Sheridan Hutchinson (sheridan-shezza) wrote :

Are Wayland developers more open minded?

Revision history for this message
Bryce Harrington (bryce) wrote :

A while ago we wrote up some architecture and troubleshooting documents for hotkeys - https://wiki.ubuntu.com/Hotkeys

Some of that has gotten dated (e.g. we don't use HAL anymore), but it's still roughly descriptive. Many of the tools listed there are still useful in isolating where in the stack problems creep in.

I'd like to see if I can reproduce this issue locally. Can someone suggest a game (ideally a freely available one) that demonstrates this behavior?

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

Basically every single game that uses SDL full screen will trigger it.

Neverball, Battle for Wesnoth, Tremulous, Nexuiz, Xonotic, Hedgewars, Teeworlds, the list truly can go on.

Revision history for this message
Ravi Kumar (kumarravi-kumar267) wrote :

When it will gonna fixed? Steam is coming to ubuntu..... And this annoying bug....

Revision history for this message
In , Alexander Betaev (infestator) wrote :

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!

Revision history for this message
In , Alexander Betaev (infestator) wrote :

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

Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Eric Knaak (eeknaak) wrote :

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.

Revision history for this message
In , Alkis Georgopoulos (alkisg) wrote :

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.

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- 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.

Changed in xorg-server:
status: Confirmed → Unknown
Paul White (paulw2u)
Changed in xorg-server:
importance: Medium → Unknown
Changed in hundredpapercuts:
importance: Undecided → Low
Changed in xorg-server:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.