About focusing out of a fullscreen game (alt-tab or minimize)

Sylvain_Brunerie · January 19, 2012, 8:16pm

Hi,

This is something I wanted to talk about since a long time. I’m sure many
others have talked on the subject many times, but I still can’t find an
answer as to why this problem is not getting resolved. There are more and
more games that run under Linux, and yet I can’t play confortably on Linux,
for a very simple reason: when playing in fullscreen (that is to say, most
of the time), I can’t alt-tab or minimize the window in order to focus
another window. If I need help on the Internet about a game, I am forced to
quit the game, look for help and then reopen it.
Maybe there is a simple solution that I wasn’t able to find. Actually, I
use sdlhack[1], a wrapper that offers a shortcut to minimize the fullscreen
window. But this is still annoying to use. I would have to change all my
launchers to add “sdlhack” before the executable. And the simple existence
of this little program seems to show that this is a problem that can be
solved at the SDL level.
I just can’t understand why the situation is still the same, while this
problem is the only thing that prevents me from playing games under Linux.

Sorry for my approximative English. Sorry if I didn’t get something, and
sorry if I seem to be angry, I don’t want to whine, I would just like an
answer as to why the problem is still there.

[1] http://www.jspenguin.org/software/sdlhack/

? Sylvain Brunerie

Jeroen_van_Aart · January 19, 2012, 9:40pm

Sylvain Brunerie wrote:

more games that run under Linux, and yet I can’t play confortably on Linux,
for a very simple reason: when playing in fullscreen (that is to say, most
of the time), I can’t alt-tab or minimize the window in order to focus
another window. If I need help on the Internet about a game, I am forced to
quit the game, look for help and then reopen it.

Normally if a game goes to full screen in X it will open a new display.
You can switch displays and virtual consoles using (ctrl) alt and the Fx
keys.

In many cases the following should work fine, it has for me since the
mid 90s for all distributions I have used:

To go from X to a virtual console use ctrl-alt-F1 (or F2 F3 F4 F5 F6)
To switch from one virtual console to another use alt-F2 (or F1 F3 F4
F5 F6)
To go from a virtual console to X use alt-F7

To fix your particular problem:

To go from the full screen game to X use ctrl-alt-F7
To go back to the game use ctrl-alt-F8

Greetings,
Jeroen–
Earthquake Magnitude: 4.7
Date: Thursday, January 19, 2012 07:29:30 UTC
Location: off the west coast of northern Sumatra
Latitude: 2.4189; Longitude: 93.1334
Depth: 31.50 km

Alan_Swanson · January 19, 2012, 10:46pm

No, it is annoying!

The cause is that the game grabs all mouse and keyboard input with
SDL_WM_GrabInput() to lock the mouse to the window, which is desirable,
but which then prevents the window managers from registering Alt-Tab
requests.

Unfortunately, Alt-Tab wasn’t set as a standard by SDL leaving the
games to support Alt-Tab themselves in their own input routines. And
they mostly don’t…

However many do at least support Alt-Return or Alt-Enter to toggle
between fullscreen and windowed (and I’d use this over Alt-Tab anyway)
and also Alt-g to enable and disable the input grab but usually only
when windowed and not in fullscreen.

One solution I’d found, originally for NWN, was to patch SDL itself
to intercept Alt-Enter and Alt-g requests as above. I have been
meaning to make patch only apply to specific games rather than
universally though.

http://home.roadrunner.com/~nwmovies/fullscreen-toggle-1211.patch

Finally, another wacky “solution” is to start games in a separate X
server and then use Alt-Cntl-F7 or Alt-Cntl-F8 to switch between
their virtual terminals.On 2012-01-19 20:16, Sylvain Brunerie wrote:

Hi,

This is something I wanted to talk about since a long time. Im sure
many others have talked on the subject many times, but I still cant
find an answer as to why this problem is not getting resolved. There
are more and more games that run under Linux, and yet I cant play
confortably on Linux, for a very simple reason: when playing in
fullscreen (that is to say, most of the time), I cant alt-tab or
minimize the window in order to focus another window. If I need help
on the Internet about a game, I am forced to quit the game, look for
help and then reopen it.
Maybe there is a simple solution that I wasnt able to find.
Actually,
I use sdlhack[1], a wrapper that offers a shortcut to minimize the
fullscreen window. But this is still annoying to use. I would have to
change all my launchers to add “sdlhack” before the executable. And
the simple existence of this little program seems to show that this
is
a problem that can be solved at the SDL level.
I just cant understand why the situation is still the same, while
this problem is the only thing that prevents me from playing games
under Linux.

Sorry for my approximative English. Sorry if I didnt get something,
and sorry if I seem to be angry, I dont want to whine, I would just
like an answer as to why the problem is still there.

–
Alan.

Jeroen_van_Aart · January 19, 2012, 10:58pm

Alan Swanson wrote:

Finally, another wacky “solution” is to start games in a separate X
server and then use Alt-Cntl-F7 or Alt-Cntl-F8 to switch between
their virtual terminals.

I don’t find that a wacky solution. I always found it pretty elegant to
have a totally different display (X server) for the game than you have
for the desktop and switch between them with ctrl-alt-FX. It’s not like
you’re in any way restricted to just one X server per system so why not
take advantage of it?

When your game crashes (the X server) you won’t have the chance to lose
your whole desktop environment. And as long as you have an ssh server
running you can almost always regain back control of mouse and keyboard
in case that’s not responding anymore…

That’s just my 2 cents from years of playing quake1/2/3 on Linux…

Greetings,
Jeroen–
Earthquake Magnitude: 4.7
Date: Thursday, January 19, 2012 07:29:30 UTC
Location: off the west coast of northern Sumatra
Latitude: 2.4189; Longitude: 93.1334
Depth: 31.50 km

Sylvain_Brunerie · January 20, 2012, 9:55am

2012/1/19 Jeroen van Aart

Normally if a game goes to full screen in X it will open a new display.
You can switch displays and virtual consoles using (ctrl) alt and the Fx
keys.

In many cases the following should work fine, it has for me since the mid
90s for all distributions I have used:

To go from X to a virtual console use ctrl-alt-F1 (or F2 F3 F4 F5 F6)

To switch from one virtual console to another use alt-F2 (or F1 F3 F4 F5
F6)

To go from a virtual console to X use alt-F7

To fix your particular problem:

To go from the full screen game to X use ctrl-alt-F7

To go back to the game use ctrl-alt-F8

On my computer (under Arch Linux), X starts in alt-F7, and games do not
seem to open a new display. Ctrl-Alt-F8 is as empty as are Ctrl-Alt-F9, F10?
But I admit using a different X server for the game seems an elegant
solution to me, although it is not a solution for new users. I will try
this though.

? Sylvain Brunerie
http://innsbay.toile-libre.org

Forest_Hale · January 20, 2012, 10:22am

My own experience suggests the desired behavior in 99% of cases on Linux is the following:

do not resize the desktop in any way (on Linux this tends to kill secondary monitors, and shuffle icons and windows around to fit the small space, both are very annoying).
open a maximized window and request the window manager to make it borderless (there’s an Atom to negotiate for this).
grab mouse only, do not grab keyboard.

This works well for me in my native (non-SDL) GLX game engine port, the SDL version has the undesirable behaviors being discussed here.

This issue in SDL is the single reason I do not play fullscreen SDL games on Linux, I always switch them to a windowed mode (to get back my secondary monitors, and to not mess up my desktop layout)
and I also do not play any SDL games that do not have an easy way to release the input grab (which disables alt-tab, alt-f4, my volume control keys, my mute key, my previous/next music track keys and
other such features of my keyboard).

I would go as far as saying there is no valid excuse for this behavior.–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Alberto_Luaces_Ferna · January 20, 2012, 10:23am

Sylvain Brunerie writes:

2012/1/19 Jeroen van Aart

Normally if a game goes to full screen in X it will open a new display.
You can switch displays and virtual consoles using (ctrl) alt and the Fx
keys.

In many cases the following should work fine, it has for me since the mid
90s for all distributions I have used:

To go from X to a virtual console use ctrl-alt-F1 (or F2 F3 F4 F5 F6)

To switch from one virtual console to another use alt-F2 (or F1 F3 F4 F5
F6)

To go from a virtual console to X use alt-F7

To fix your particular problem:

To go from the full screen game to X use ctrl-alt-F7

To go back to the game use ctrl-alt-F8

On my computer (under Arch Linux), X starts in alt-F7, and games do not
seem to open a new display. Ctrl-Alt-F8 is as empty as are Ctrl-Alt-F9, F10?
But I admit using a different X server for the game seems an elegant
solution to me, although it is not a solution for new users. I will try
this though.

Doesn’t the program need to have root permissions in order to create a
new display? I guess that’s why so few programs open their own one. As
Sylvain, I personally have never run through one, I think. Usually when
programs crash, they leave my desktop in the resolution mode they were
using.–
Alberto

Sylvain_Brunerie · January 20, 2012, 10:29am

2012/1/19 Alan Swanson

Hi,

This is something I wanted to talk about since a long time. Im sure
many others have talked on the subject many times, but I still cant

find an answer as to why this problem is not getting resolved. There
are more and more games that run under Linux, and yet I cant play

confortably on Linux, for a very simple reason: when playing in
fullscreen (that is to say, most of the time), I cant alt-tab or

minimize the window in order to focus another window. If I need help
on the Internet about a game, I am forced to quit the game, look for
help and then reopen it.
Maybe there is a simple solution that I wasnt able to find. Actually,

I use sdlhack[1], a wrapper that offers a shortcut to minimize the
fullscreen window. But this is still annoying to use. I would have to
change all my launchers to add “sdlhack” before the executable. And
the simple existence of this little program seems to show that this is
a problem that can be solved at the SDL level.
I just cant understand why the situation is still the same, while

this problem is the only thing that prevents me from playing games
under Linux.

Sorry for my approximative English. Sorry if I didnt get something,
and sorry if I seem to be angry, I dont want to whine, I would just

like an answer as to why the problem is still there.

No, it is annoying!

The cause is that the game grabs all mouse and keyboard input with
SDL_WM_GrabInput() to lock the mouse to the window, which is desirable,
but which then prevents the window managers from registering Alt-Tab
requests.

Unfortunately, Alt-Tab wasn’t set as a standard by SDL leaving the
games to support Alt-Tab themselves in their own input routines. And
they mostly don’t…

However many do at least support Alt-Return or Alt-Enter to toggle
between fullscreen and windowed (and I’d use this over Alt-Tab anyway)
and also Alt-g to enable and disable the input grab but usually only
when windowed and not in fullscreen.

I understand the problem of the game grabbing all input, and that Alt-Tab
isn’t a standard.
Concerning Alt-Enter, it seems many of the games installed on my system do
not support it (though I’m not sure whether they all use SDL or not anyway).
But some do switch to windowed mode very well, thanks for the tip. I have
yet to try it more games to see how many do support this (I have plenty of
them with the Humble Bundles).

One solution I’d found, originally for NWN, was to patch SDL itself

to intercept Alt-Enter and Alt-g requests as above. I have been
meaning to make patch only apply to specific games rather than
universally though.

http://home.roadrunner.com/~nwmovies/fullscreen-toggle-1211.patch

That seems great, thanks. I will try it and maybe write a PKGBUILD for AUR
if it works, if you don’t mind. I don’t understand, though, how this patch
is supposed to only apply to specific games.
Finally, shouldn’t this kind of patch be included in SDL? Maybe there isn’t
a consensus on such a shortcut that forces toggle between fullscreen and
windowed?

? Sylvain Brunerie
http://innsbay.toile-libre.org> On 2012-01-19 20:16, Sylvain Brunerie wrote:

mogumbo · January 20, 2012, 5:10pm

One solution I’d found, originally for NWN, was to patch SDL itself

to intercept Alt-Enter and Alt-g requests as above. I have been
meaning to make patch only apply to specific games rather than
universally though.

Instead of making it game-specific, how about just making it a feature
the developer can easily switch on or off?

I have been leaning toward making my game fullscreen only for a few
reasons. 1. When the mouse goes outside the window, the controls stop
working. 2. On games where the mouse is confined to the window I
sometimes get annoyed trying to figure out how to get the game to let
go of the mouse. 3. I’m using OSG for graphics, which only seems
about 99% reliable when I switch between fullscreen and windowed.
Sometimes a texture is blank or the wrong texture, and I’m not sure if
I can debug this to make it 100% reliable.

Is making a game fullscreen only a valid solution? I get the
impression from some of the messages on this thread that players want
windowed mode really bad.–
Terry Welsh
mogumbo ‘at’ gmail.com
www.reallyslick.com

Benjamin_Shadwick · January 20, 2012, 5:42pm

I have to agree that said behavior is unacceptable in my opinion. The main
problem for me with SDL grabbing all input in fullscreen on X is that it
locks out the ability to adjust the sound volume via the multimedia keys on
my laptop and keyboard. I’ve had to resort to telling X not to handle those
keys, and instead run a daemon (which itself is an abandoned project that
doesn’t even compile on modern Linux without patching) that handles them
for me.

It’s partly X.org’s fault I think, as I’m pretty sure that Windows doesn’t
allow this without some significant hacking.On Fri, Jan 20, 2012 at 2:22 AM, Forest Hale wrote:

My own experience suggests the desired behavior in 99% of cases on Linux
is the following:

do not resize the desktop in any way (on Linux this tends to kill
secondary monitors, and shuffle icons and windows around to fit the small
space, both are very annoying).

open a maximized window and request the window manager to make it
borderless (there’s an Atom to negotiate for this).

grab mouse only, do not grab keyboard.

This works well for me in my native (non-SDL) GLX game engine port, the
SDL version has the undesirable behaviors being discussed here.

This issue in SDL is the single reason I do not play fullscreen SDL games
on Linux, I always switch them to a windowed mode (to get back my secondary
monitors, and to not mess up my desktop layout)
and I also do not play any SDL games that do not have an easy way to
release the input grab (which disables alt-tab, alt-f4, my volume control
keys, my mute key, my previous/next music track keys and
other such features of my keyboard).

I would go as far as saying there is no valid excuse for this behavior.

–
LordHavoc
Author of DarkPlaces Quake1 engine -
LadyHavoc's DarkPlaces Quake Modification
Co-designer http://icculus.org/twilight/darkplaces Co-designer of
Nexuiz - Nexuiz Classic – Alientrap
“War does not prove who is right, it proves who is left.” - Unknown
“Any sufficiently advanced technology is indistinguishable from a rigged
demo.” - James Klass
“A game is a series of interesting choices.” - Sid Meier

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

Ben S.

Sylvain_Brunerie · January 26, 2012, 12:02pm

2012/1/20 Benjamin Shadwick

I have to agree that said behavior is unacceptable in my opinion. The main
problem for me with SDL grabbing all input in fullscreen on X is that it
locks out the ability to adjust the sound volume via the multimedia keys on
my laptop and keyboard. I’ve had to resort to telling X not to handle those
keys, and instead run a daemon (which itself is an abandoned project that
doesn’t even compile on modern Linux without patching) that handles them
for me.

It’s partly X.org’s fault I think, as I’m pretty sure that Windows doesn’t
allow this without some significant hacking.

Ah, you’re right, I forgot this one. It’s a pretty annoying thing. Most of
the time when I start a game, I’m forced to exit, turn down the volume, and
restart the game, unless I want to wake up everyone in the house (assuming
it’s late evening).

Windows seem to allow Alt-Tab, Windows key and multimedia keys, at least.
Maybe it doesn’t grab keyboard input at all. I suppose it can’t be easily
bypassed, and therefore grabbing all input in a game under Windows is less
common, or inexistent (I didn’t see that happen once). What are the cons of
such a behavior? Why shouldn’t SDL behave more or less this way? At least
implement a keyboard combination to minimize the window, probably more
reliable than toggle between fullscreen and windowed.

? Sylvain Brunerie
http://innsbay.toile-libre.org

Sylvain_Brunerie · January 26, 2012, 12:13pm

2012/1/20 Forest Hale

My own experience suggests the desired behavior in 99% of cases on Linux
is the following:

do not resize the desktop in any way (on Linux this tends to kill
secondary monitors, and shuffle icons and windows around to fit the small
space, both are very annoying).

open a maximized window and request the window manager to make it
borderless (there’s an Atom to negotiate for this).

grab mouse only, do not grab keyboard.

A maximized borderless window will still have panels (in any) under/over
it, won’t it?

I agree with points 1 and 3, as I hate having my resolution changed and my
desktop icons messed up when a game doesn’t quit correctly, and as I don’t
see what could be prohibitive with not grabbing the keyboard (this would
allow Alt-F4 to close the window, Alt-F1 to open the Gnome Applications
menu, but why not?). Not being able to change volume when in a fullscreen
game may be, when I think of it, the first issue preventing me to play
games under Linux.

? Sylvain Brunerie
http://innsbay.toile-libre.org

Sylvain_Brunerie · January 26, 2012, 12:24pm

2012/1/20 Terry Welsh

One solution I’d found, originally for NWN, was to patch SDL itself

to intercept Alt-Enter and Alt-g requests as above. I have been
meaning to make patch only apply to specific games rather than
universally though.

Instead of making it game-specific, how about just making it a feature
the developer can easily switch on or off?

I have been leaning toward making my game fullscreen only for a few
reasons. 1. When the mouse goes outside the window, the controls stop
working. 2. On games where the mouse is confined to the window I
sometimes get annoyed trying to figure out how to get the game to let
go of the mouse. 3. I’m using OSG for graphics, which only seems
about 99% reliable when I switch between fullscreen and windowed.
Sometimes a texture is blank or the wrong texture, and I’m not sure if
I can debug this to make it 100% reliable.

Is making a game fullscreen only a valid solution? I get the
impression from some of the messages on this thread that players want
windowed mode really bad.

For my part, I don’t really want windowed mode, I largely prefer playing in
fullscreen. It’s just that switching to windowed mode permits to focus
another window, or turn down the volume, for instance. As I said, I think a
solution for me would be a shortcut that minimizes the window (as does
sdlhack, but it’s a wrapper, therefore I have to launch games with
“sdlhack” before). This way there are, I think, no problems like the ones
you mentioned.
That said, I would prefer to be able to turn down volume directly from
inside the game.

? Sylvain Brunerie
http://innsbay.toile-libre.org

mogumbo · January 26, 2012, 8:55pm

I have been leaning toward making my game fullscreen only for a few
reasons. ?1. When the mouse goes outside the window, the controls stop
working. ?2. On games where the mouse is confined to the window I
sometimes get annoyed trying to figure out how to get the game to let
go of the mouse. ?3. I’m using OSG for graphics, which only seems
about 99% reliable when I switch between fullscreen and windowed.
Sometimes a texture is blank or the wrong texture, and I’m not sure if
I can debug this to make it 100% reliable.

Is making a game fullscreen only a valid solution? ?I get the
impression from some of the messages on this thread that players want
windowed mode really bad.

For my part, I don’t really want windowed mode, I largely prefer playing in
fullscreen. It’s just that switching to windowed mode permits to focus
another window, or turn down the volume, for instance. As I said, I think a
solution for me would be a shortcut that minimizes the window (as does
sdlhack, but it’s a wrapper, therefore I have to launch games with
“sdlhack” before). This way there are, I think, no problems like the ones
you mentioned.
That said, I would prefer to be able to turn down volume directly from
inside the game.

? Sylvain Brunerie
http://innsbay.toile-libre.org

I already have in-game volume control. It doesn’t affect the system
volume, just a gain applied to SDL_mixer. I like the idea of
minimizing. This will be a good alternative to windowed mode as long
as it doesn’t cause a new OpenGL context to be created, which is the
root of my fullscreen/windowed problems.

Does anyone know where the alt-enter convention comes from? I
searched around and couldn’t find anything about it. Some games also
use F4 or F11 to switch between fullscreen and windowed modes. There
doesn’t seem to be one good standard on this.–
Terry Welsh
mogumbo ‘at’ gmail.com
www.reallyslick.com

Alan_Swanson · January 26, 2012, 9:24pm

Loki games.

This thread has finally motivated me to start patching SDL 1.2 to add
multimedia key support and optional (environment variable) key combos
for;

Fullscreen toggling or minimisation and key grabbing (tweaked the NWN
patch I commented upon earlier).
Volume control and muting (alsa master volume only though).

Patches next week maybe after finishing the alsa coding and testing.On Thu, 2012-01-26 at 12:55 -0800, Terry Welsh wrote:
On other random date Sylvain Brunerie wrote:

For my part, I don’t really want windowed mode, I largely prefer playing in
fullscreen. It’s just that switching to windowed mode permits to focus
another window, or turn down the volume, for instance. As I said, I think a
solution for me would be a shortcut that minimizes the window (as does
sdlhack, but it’s a wrapper, therefore I have to launch games with
“sdlhack” before). This way there are, I think, no problems like the ones
you mentioned.
That said, I would prefer to be able to turn down volume directly from
inside the game.

I already have in-game volume control. It doesn’t affect the system
volume, just a gain applied to SDL_mixer. I like the idea of
minimizing. This will be a good alternative to windowed mode as long
as it doesn’t cause a new OpenGL context to be created, which is the
root of my fullscreen/windowed problems.

Does anyone know where the alt-enter convention comes from? I
searched around and couldn’t find anything about it. Some games also
use F4 or F11 to switch between fullscreen and windowed modes. There
doesn’t seem to be one good standard on this.

–
Alan.

Benjamin_Shadwick · January 26, 2012, 10:41pm

I believe Alt+Enter is a Windows carryover, as it was used for MS-DOS
sessions running in Win 3.0 and later.On Thu, Jan 26, 2012 at 1:24 PM, Alan Swanson wrote:

On Thu, 2012-01-26 at 12:55 -0800, Terry Welsh wrote:
On other random date Sylvain Brunerie wrote:

For my part, I don’t really want windowed mode, I largely prefer
playing in
fullscreen. It’s just that switching to windowed mode permits to focus
another window, or turn down the volume, for instance. As I said, I
think a
solution for me would be a shortcut that minimizes the window (as does
sdlhack, but it’s a wrapper, therefore I have to launch games with
“sdlhack” before). This way there are, I think, no problems like the
ones
you mentioned.
That said, I would prefer to be able to turn down volume directly from
inside the game.

I already have in-game volume control. It doesn’t affect the system
volume, just a gain applied to SDL_mixer. I like the idea of
minimizing. This will be a good alternative to windowed mode as long
as it doesn’t cause a new OpenGL context to be created, which is the
root of my fullscreen/windowed problems.

Does anyone know where the alt-enter convention comes from? I
searched around and couldn’t find anything about it. Some games also
use F4 or F11 to switch between fullscreen and windowed modes. There
doesn’t seem to be one good standard on this.

Loki games.

This thread has finally motivated me to start patching SDL 1.2 to add
multimedia key support and optional (environment variable) key combos
for;

Fullscreen toggling or minimisation and key grabbing (tweaked the NWN
patch I commented upon earlier).

Volume control and muting (alsa master volume only though).

Patches next week maybe after finishing the alsa coding and testing.

–
Alan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

Ben S.

Forest_Hale · January 31, 2012, 6:49pm

#2 is only a clarification, it describes the current behavior.

X11 allows a window to be created that is managed by the window manager (this is the normal kind) and that can then negotiate for an Atom asking for fullscreen (borderless, covers panel, etc).

X11 also allows a window to be created that is NOT managed by the window manager, this kind is borderless by nature (without the window manager to add decorative window rects around it for
interactivity), and CAN NOT receive keyboard or mouse events unless it grabs these input sources intentionally, which overrides the window manager shortcuts.

As far as I understand it, SDL currently uses the managed type, and this is what I am saying we should stick to.

I was only clarifying that the unmanaged type requires keyboard grab, and the use of keyboard grab in SDL may be a hold-over from past code that used an unmanaged window.

Back to the theory of what users want however:

In general, users don’t like SDL doing keyboard grab, it is reserved for screensavers and screen locking, it was never meant to be used for common usage.

My point is that we should not resize the desktop (mode switching), we should use a managed window, and we should not grab keyboard (thus allowing window manager shortcuts to continue functioning).

The all-or-nothing nature of the keyboard shortcut handling is potentially problematic for some apps, but that is another topic entirely, from a user perspective it is less annoying to contend with
shortcut conflicts (such as alt-F keys) than it is to lose volume control, alt-tab and other conveniences that any NORMAL app would not interfere with.

If one wishes to write screen locking software with SDL, then we need to provide the keyboard grab functionality, but I do not think it should be used in any normal situation.On 01/26/2012 04:13 AM, Sylvain Brunerie wrote:

2012/1/20 Forest Hale <@Forest_Hale mailto:Forest_Hale>
My own experience suggests the desired behavior in 99% of cases on Linux is the following:
1. do not resize the desktop in any way (on Linux this tends to kill secondary monitors, and shuffle icons and windows around to fit the small space, both are very annoying).
2. open a maximized window and request the window manager to make it borderless (there's an Atom to negotiate for this).
3. grab mouse only, do not grab keyboard.
A maximized borderless window will still have panels (in any) under/over it, won’t it?

I agree with points 1 and 3, as I hate having my resolution changed and my desktop icons messed up when a game doesn’t quit correctly, and as I don’t see what could be prohibitive with not grabbing
the keyboard (this would allow Alt-F4 to close the window, Alt-F1 to open the Gnome Applications menu, but why not?). Not being able to change volume when in a fullscreen game may be, when I think of
it, the first issue preventing me to play games under Linux.

–
LordHavoc
Author of DarkPlaces Quake1 engine - LadyHavoc's DarkPlaces Quake Modification
Co-designer of Nexuiz - Nexuiz Classic – Alientrap
“War does not prove who is right, it proves who is left.” - Unknown
“Any sufficiently advanced technology is indistinguishable from a rigged demo.” - James Klass
“A game is a series of interesting choices.” - Sid Meier

Karl_Glatzer · January 31, 2012, 7:53pm

2012/1/20 Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>>
My own experience suggests the desired behavior in 99% of cases on Linux is the following:
1. do not resize the desktop in any way (on Linux this tends to kill secondary monitors, and shuffle icons and windows around to fit the small space, both are very annoying).
2. open a maximized window and request the window manager to make it borderless (there's an Atom to negotiate for this).
3. grab mouse only, do not grab keyboard.
A maximized borderless window will still have panels (in any) under/over it, won’t it?

I agree with points 1 and 3, as I hate having my resolution changed and my desktop icons messed up when a game doesn’t quit correctly, and as I don’t see what could be prohibitive with not grabbing
the keyboard (this would allow Alt-F4 to close the window, Alt-F1 to open the Gnome Applications menu, but why not?). Not being able to change volume when in a fullscreen game may be, when I think of
it, the first issue preventing me to play games under Linux.
#2 is only a clarification, it describes the current behavior.

X11 allows a window to be created that is managed by the window manager (this is the normal kind) and that can then negotiate for an Atom asking for fullscreen (borderless, covers panel, etc).

X11 also allows a window to be created that is NOT managed by the window manager, this kind is borderless by nature (without the window manager to add decorative window rects around it for
interactivity), and CAN NOT receive keyboard or mouse events unless it grabs these input sources intentionally, which overrides the window manager shortcuts.

Yes this is how things work with X11, but this:

As far as I understand it, SDL currently uses the managed type, and this is what I am saying we should stick to.

is only true for SDL 2.0. SDL 1.2 still uses windows which are not
(cannot be) managed by the window manager aka setting xoverride-redirect.

I tried to backport the SDL 2.0 window handling to SDL 1.2 and even send
a patch to Sam with an implementation that I thought was working.

Luckily he refused it and I now found out that my backport broke the old
behaviour which should be kept for window managers which don’t support
the fullscreen atom and in addition the current implementation in SDL
2.0 also isn’t sufficient because it will only work correctly with
XRandr mode switching.

The better XVidMode mode switching sadly can’t be used reliably with
windows which are managed by the window manager.

I already have an Idea how to solve this. I think the best way would be
to add a new fullscreen method to the wm-specs on freedesktop.org which
gives more control over the window to the application and is closer to
the xoverride-redirect method in the way that it should be possible to
place the window anywhere (not restricted by panels) and on top of the
window stack when it is focused.

I have worked this out a lot more and will start a discussion about it
on the wm-spec mailing list of freedesktop.org soon.

Now to Keyboard Grabs: Yes they are really bad and i think sdl shouldn’t
use them at all except for old window managers which don’t support the
fullscreen atom. That’s all i want to say about it now, but it
definitely needs to be discussed.

PS: I also think that the keyboard shortcut handling should be improved
possible by making another spec for it on freedesktop.org ;)Am 31.01.2012 19:49, schrieb Forest Hale:

On 01/26/2012 04:13 AM, Sylvain Brunerie wrote:

Alan_Swanson · January 31, 2012, 8:01pm

There was an initial patch last year to support NET_WM_FULLSCREEN with
SDL 1.2 (as SDL 2.0 already does support it) by Karl Glatzer. Search for
subject “[PATCH] net_wm_fullscreen for SDL1.2” on 26/6/11. However there
were a number of issues preventing it being usable.On Tue, 2012-01-31 at 10:49 -0800, Forest Hale wrote:

On 01/26/2012 04:13 AM, Sylvain Brunerie wrote:
2012/1/20 Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>>
My own experience suggests the desired behavior in 99% of cases on Linux is the following:
1. do not resize the desktop in any way (on Linux this tends to kill secondary monitors, and shuffle icons and windows around to fit the small space, both are very annoying).
2. open a maximized window and request the window manager to make it borderless (there's an Atom to negotiate for this).
3. grab mouse only, do not grab keyboard.
A maximized borderless window will still have panels (in any) under/over it, won’t it?

I agree with points 1 and 3, as I hate having my resolution changed and my desktop icons messed up when a game doesn’t quit correctly, and as I don’t see what could be prohibitive with not grabbing
the keyboard (this would allow Alt-F4 to close the window, Alt-F1 to open the Gnome Applications menu, but why not?). Not being able to change volume when in a fullscreen game may be, when I think of
it, the first issue preventing me to play games under Linux.
#2 is only a clarification, it describes the current behavior.

X11 allows a window to be created that is managed by the window manager (this is the normal kind) and that can then negotiate for an Atom asking for fullscreen (borderless, covers panel, etc).

–
Alan.

Alan_Swanson · January 31, 2012, 8:26pm

And the first revision of the patch. I wouldn’t expect this to be
applied to source except perhaps for the XF86 vendor keys support. It
provides optional overrides for;

Alt-Tab to minimise when fullscreen.
Alt-Tab to ungrab input when windowed (in other words Alt-Tab twice to
get window switching)
Alt-g to grab and ungrab input when windowed.
ALSA volume control using either:

Multimedia volume up key or Control-Alt-Q to increase volume.
Multimedia volume down key or Control-Alt-A to decrease volume.
Multimedia mute key or Control-Alt-Z to mute volume.
Defaults to Master but can be changed with SDL_AUDIO_ALSA_MIXER=Foo
command line option.

After applying the patch you’ll need to regenerate the configure file
with autogen.sh for the XF86 vendor key symbols. Then the following
command line options will activate the respective overrides;

 SDL_OVERRIDE_ALTTAB=1
 SDL_OVERRIDE_ALTENTER=1
 SDL_OVERRIDE_ALTG=1
 SDL_OVERRIDE_SOUND=1
 SDL_OVERRIDE_ALL=1

The multimedia volume keys are always be overriden, the option is just
for Control-Alt-[qaz] combos.

For the future I’m thinking of a game lookup table so combos not used by
the game are automatically enabled and I’m currently leaning towards
enabling the Alt-Tab override by default as no game I’ve played ever
supports it. However there’s always the possible problem of OpenGL apps
not reloading context and textures if not paying attention to
SDL_APPACTIVE signal. And if somebody actually likes Pulseaudio, please
send a volume control patch.

http://www.swanson.ukfsn.org/#sdlcombo

Maybe we’ll also see if keyboard grab (as opposed to mouse grab) is
really necessary and NET_WM_FULLSCREEN gets support in SDL 1.2.On Thu, 2012-01-26 at 21:24 +0000, Alan Swanson wrote:

This thread has finally motivated me to start patching SDL 1.2 to add
multimedia key support and optional (environment variable) key combos
for;

Fullscreen toggling or minimisation and key grabbing (tweaked the NWN
patch I commented upon earlier).

Volume control and muting (alsa master volume only though).

Patches next week maybe after finishing the alsa coding and testing.

–
Alan.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl-1.2-supercombo-20120131.patch
Type: text/x-patch
Size: 17163 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120131/c5da9706/attachment.bin