The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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
http://innsbay.toile-libre.org

Sylvain Brunerie wrote:

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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 2012-01-19 20:16, Sylvain Brunerie wrote:

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.

--
Alan.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Alan Swanson wrote:

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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2012/1/19 Jeroen van Aart
 
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

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.

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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sylvain Brunerie writes:


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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2012/1/19 Alan Swanson

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



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

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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:



--
- Ben S.

2012/1/20 Benjamin Shadwick

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

 

2012/1/20 Forest Hale

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

2012/1/20 Terry Welsh

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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:



--
- Ben S.

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

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

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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Tue, 2012-01-31 at 10:49 -0800, Forest Hale wrote:

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.

--
Alan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Thu, 2012-01-26 at 21:24 +0000, Alan Swanson wrote:

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.

--
Alan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Starting a discussion on the wm-spec mailing list is a great idea.  I was thinking about doing that myself with respect to SDL 2.0 window management.

FYI, SDL 1.2 window management is not likely to change at this point.  For better or worse, it has pretty much been consistent for the last 10 years and I'm loathe to introduce changes to it at this point.


SDL 2.0 window management is completely different, and my goal for it is to embrace and create the next generation fullscreen window management for modern desktops.  To that end, I would love it if I and other people on this list can put our heads together and worked out the best way to do this, in collaboration with the window manager folks at freedesktop.org.


Cheers!

On Tue, Jan 31, 2012 at 2:53 PM, Karl wrote: