Fullscreen support on X11

Ryan and I have been working on fullscreen support on X11 for SDL 2.0, and
I’d like to share the current status.

There are now two distinct fullscreen code paths, one for modern window
managers and one very similar to the legacy fullscreen support in SDL 1.2.

The modern fullscreen support uses the _NET_WM_STATE_FULLSCREEN hint
defined in the EWMH spec:
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html

The advantage of this path is that the window manager is aware of the
window and can handle things like managing input focus and window stacking.
The disadvantage of this is that the current window manager
implementations leave the desktop resolution alone and resize the window to
match the desktop size.

The legacy fullscreen support is used if the window manager doesn’t support
the _NET_WM protocol, the XVidTune extension is enabled, or
the SDL_VIDEO_X11_LEGACY_FULLSCREEN environment variable is set to 1.

The advantage of this path is that it usually works and you can change
resolution out from under the window manager. The disadvantage is that in
order to do so it needs to grab input and it doesn’t play well with others.
Oh, and if your program crashes the desktop is left in a really bad state.

I’ve done a bunch of testing and it seems like the _NET_WM_STATE_FULLSCREEN
support works very well on various window managers and I recommend using it
if possible. Using the XVidTune extension can really hose compositing
window managers, and using XRandR causes the desktop to be reorganized and
windows to be resized since the window manager doesn’t know it’s a
temporary resolution change.

Ryan is putting together a NetWM protocol proposal for a new fullscreen
state which allows the window manager to handle the display resolution
changes appropriately. This will combine the best of both worlds where the
application can get the resolution it expects, the window manager can
prevent the desktop from being reorganized by a resolution change, and if
the application crashes the window manager can seamlessly restore the
desktop resolution.

Cheers!
–Sam

2012/9/30 Sam Lantinga

Ryan and I have been working on fullscreen support on X11 for SDL 2.0, and
I’d like to share the current status.

There are now two distinct fullscreen code paths, one for modern window
managers and one very similar to the legacy fullscreen support in SDL 1.2.

The modern fullscreen support uses the _NET_WM_STATE_FULLSCREEN hint
defined in the EWMH spec:
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html

The advantage of this path is that the window manager is aware of the
window and can handle things like managing input focus and window stacking.
The disadvantage of this is that the current window manager
implementations leave the desktop resolution alone and resize the window to
match the desktop size.

The legacy fullscreen support is used if the window manager doesn’t
support the _NET_WM protocol, the XVidTune extension is enabled, or
the SDL_VIDEO_X11_LEGACY_FULLSCREEN environment variable is set to 1.

The advantage of this path is that it usually works and you can change
resolution out from under the window manager. The disadvantage is that in
order to do so it needs to grab input and it doesn’t play well with others.
Oh, and if your program crashes the desktop is left in a really bad state.

I’ve done a bunch of testing and it seems like the
_NET_WM_STATE_FULLSCREEN support works very well on various window managers
and I recommend using it if possible. Using the XVidTune extension can
really hose compositing window managers, and using XRandR causes the
desktop to be reorganized and windows to be resized since the window
manager doesn’t know it’s a temporary resolution change.

Ryan is putting together a NetWM protocol proposal for a new fullscreen
state which allows the window manager to handle the display resolution
changes appropriately. This will combine the best of both worlds where the
application can get the resolution it expects, the window manager can
prevent the desktop from being reorganized by a resolution change, and if
the application crashes the window manager can seamlessly restore the
desktop resolution.

Do you know if/how this works with the Xinerama/Twinview/Xrandr changes I’m
making under bug #1571?–
Gabriel.

Ryan is putting together a NetWM protocol proposal for a new fullscreen
state which allows the window manager to handle the display resolution
changes appropriately. This will combine the best of both worlds where
the application can get the resolution it expects, the window manager
can prevent the desktop from being reorganized by a resolution change,
and if the application crashes the window manager can seamlessly restore
the desktop resolution.

Following up, this proposal has now been posted:

https://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

–ryan.

Ryan is putting together a NetWM protocol proposal for a new fullscreen

state which allows the window manager to handle the display resolution
changes appropriately. This will combine the best of both worlds where
the application can get the resolution it expects, the window manager
can prevent the desktop from being reorganized by a resolution change,
and if the application crashes the window manager can seamlessly restore
the desktop resolution.

Following up, this proposal has now been posted:

https://mail.gnome.org/archives/wm-spec-list/2012-
October/msg00001.htmlhttps://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

–ryan.

Is it interacts only with one screen? I mean is where some improvements (on
WM or EWMH) to support multi monitor systems for games (e.g. AMD Eyefinity).

2012/10/23 Ryan C. Gordon

Ryan is putting together a NetWM protocol proposal for a new fullscreen

state which allows the window manager to handle the display resolution
changes appropriately. This will combine the best of both worlds where
the application can get the resolution it expects, the window manager
can prevent the desktop from being reorganized by a resolution change,
and if the application crashes the window manager can seamlessly restore
the desktop resolution.

Following up, this proposal has now been posted:

https://mail.gnome.org/archives/wm-spec-list/2012-
October/msg00001.htmlhttps://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

–ryan.

I think the proposal is spot on, though I’m not sure when it’ll have any
meaningful impact…it seems there’s no replies to your post yet in that
list, and after discussion and acceptance it still needs to be implemented
in the window managers.

I do think we (as in the SDL community) could work on something as a
workaround in the meantime, if not to fix the issue out right, to make it
more usable…from what we’ve seen in bug #1617, XVidMode doesn’t seem to
be the silver bullet and I personally feel on multi monitor systems it’ll
never be usable…

I’m thinking out loud here, but what if we modify SDL_WINDOW_FULLSCREEN and
make it three-fold.

SDL_WINDOW_FULLSCREEN -> Gives you a fullscreen window at desktop
resolution ALWAYS (what every polite game should do IMO).
SDL_WINDOW_FULLSCREEN_LOGICAL -> Gives you a fullscreen window at desktop
resolution ALWAYS, but it uses the logical coordinate stuff Sam made to
match the desktop resolution to the user requested resolution
SDL_WINDOW_FULLSCREEN_FORCE -> Forces a resolution switch if required (what
currently happens), using Xrandr or XVidMode, and icons and windows will
most likely be rearranged if the mode is actually changed.

Too complicated? Unfeasible? Doesn’t solve the problem?–
Gabriel.

Is it interacts only with one screen? I mean is where some improvements
(on WM or EWMH) to support multi monitor systems for games (e.g. AMD
Eyefinity).

The intention is that it only interacts with one screen per window, but
you could certainly put multiple fullscreen windows on different screens.

Is that what you’re asking?

–ryan.

I’m actually going to be working on an SDL_WINDOW_FULLSCREEN_MAXIMIZED
flag, which will go fullscreen at the current desktop resolution, which is
always the safest option.

If you are using the 2D render API you can use the logical size to
automatically scale appropriately.On Wed, Oct 24, 2012 at 5:56 AM, Gabriel Jacobo wrote:

2012/10/23 Ryan C. Gordon

Ryan is putting together a NetWM protocol proposal for a new fullscreen

state which allows the window manager to handle the display resolution
changes appropriately. This will combine the best of both worlds where
the application can get the resolution it expects, the window manager
can prevent the desktop from being reorganized by a resolution change,
and if the application crashes the window manager can seamlessly restore
the desktop resolution.

Following up, this proposal has now been posted:

https://mail.gnome.org/archives/wm-spec-list/2012-
October/msg00001.htmlhttps://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

–ryan.

I think the proposal is spot on, though I’m not sure when it’ll have any
meaningful impact…it seems there’s no replies to your post yet in that
list, and after discussion and acceptance it still needs to be implemented
in the window managers.

I do think we (as in the SDL community) could work on something as a
workaround in the meantime, if not to fix the issue out right, to make it
more usable…from what we’ve seen in bug #1617, XVidMode doesn’t seem to
be the silver bullet and I personally feel on multi monitor systems it’ll
never be usable…

I’m thinking out loud here, but what if we modify SDL_WINDOW_FULLSCREEN
and make it three-fold.

SDL_WINDOW_FULLSCREEN -> Gives you a fullscreen window at desktop
resolution ALWAYS (what every polite game should do IMO).
SDL_WINDOW_FULLSCREEN_LOGICAL -> Gives you a fullscreen window at desktop
resolution ALWAYS, but it uses the logical coordinate stuff Sam made to
match the desktop resolution to the user requested resolution
SDL_WINDOW_FULLSCREEN_FORCE -> Forces a resolution switch if required
(what currently happens), using Xrandr or XVidMode, and icons and windows
will most likely be rearranged if the mode is actually changed.

Too complicated? Unfeasible? Doesn’t solve the problem?


Gabriel.


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

2012/10/24 Gabriel Jacobo :

SDL_WINDOW_FULLSCREEN -> Gives you a fullscreen window at desktop resolution
ALWAYS (what every polite game should do IMO).

Dunno, I’d think it’d be even more polite to let the user choose the
resolution for fullscreen (separately from that of windowed). I always
like to run fullscreen games at a different resolution from the
desktop to save resources (smaller resolution = better performance).
Forcing the program to be always at the desktop resolution goes
directly against that.

I know you mentioned SDL_WINDOW_FULLSCREEN_FORCE for that, but I’d
think everybody would just go with SDL_WINDOW_FULLSCREEN and forget
about the rest.

As for the proposal: I assume width and height are taken from the
window, but what about other parameters? Color depth, refresh rate,
which monitor to go fullscreen on? Well, maybe the latter one would be
better left to the window manager, but what about the other two?

SDL_SetWindowDisplayMode()On Wed, Oct 24, 2012 at 2:09 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2012/10/24 Gabriel Jacobo :

SDL_WINDOW_FULLSCREEN -> Gives you a fullscreen window at desktop
resolution
ALWAYS (what every polite game should do IMO).

Dunno, I’d think it’d be even more polite to let the user choose the
resolution for fullscreen (separately from that of windowed). I always
like to run fullscreen games at a different resolution from the
desktop to save resources (smaller resolution = better performance).
Forcing the program to be always at the desktop resolution goes
directly against that.

I know you mentioned SDL_WINDOW_FULLSCREEN_FORCE for that, but I’d
think everybody would just go with SDL_WINDOW_FULLSCREEN and forget
about the rest.

As for the proposal: I assume width and height are taken from the
window, but what about other parameters? Color depth, refresh rate,
which monitor to go fullscreen on? Well, maybe the latter one would be
better left to the window manager, but what about the other two?


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

Is that about the parameters? I was talking about the X side, not the
SDL side. If only the resolution makes into the official spec then I’d
expect support for everything else to be unreliable. Granted,
resolution is the most important one by far and would be tolerable to
just have that, but if we do this then better to do everything needed
from the beginning.

Granted, I don’t know much about X, so if there’s already a way to
specify those parameters somehow feel free to say so.

2012/10/24 Sam Lantinga :> SDL_SetWindowDisplayMode()

On Wed, Oct 24, 2012 at 2:09 PM, Sik the hedgehog <@Sik_the_hedgehog> wrote:

2012/10/24 Gabriel Jacobo :

SDL_WINDOW_FULLSCREEN -> Gives you a fullscreen window at desktop
resolution
ALWAYS (what every polite game should do IMO).

Dunno, I’d think it’d be even more polite to let the user choose the
resolution for fullscreen (separately from that of windowed). I always
like to run fullscreen games at a different resolution from the
desktop to save resources (smaller resolution = better performance).
Forcing the program to be always at the desktop resolution goes
directly against that.

I know you mentioned SDL_WINDOW_FULLSCREEN_FORCE for that, but I’d
think everybody would just go with SDL_WINDOW_FULLSCREEN and forget
about the rest.

As for the proposal: I assume width and height are taken from the
window, but what about other parameters? Color depth, refresh rate,
which monitor to go fullscreen on? Well, maybe the latter one would be
better left to the window manager, but what about the other two?


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


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

The intention is that it only interacts with one screen per window, but
you could certainly put multiple fullscreen windows on different screens.

Is that what you’re asking?

–ryan.

Yep, the first time I read a little bit wrong.

Following up, this proposal has now been posted:

https://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

–ryan.

I like the proposal for the most part (and the relaxing of MUST in
several places from the resulting documentation)

The only thing I saw missing was the inability to specify the xinerama
screen to have the game go full-screen on. Specifically how that should
be chosen (e.g. do we go based on what the offset coords are for the
window?). IMHO in a perfect world (I know dreaming). I would want to
preset the user a selection of which monitor and then what resolution on
that monitor in a game.

Otherwise I do like the proposal, and I do think that the window manager
is the best place for this interaction to happen… If you look at how
OS X has revamped their full-screen support is 10.6 and further in lion
they are basically doing the same thing. as the OS to set me to
fullscreen and not and let it handle the “mess” associated with it.On 10/23/2012 04:49 PM, Ryan C. Gordon wrote:


Edward Rudd
OutOfOrder.cc
317-674-3296

I’ve mentioned the monitor issue before, but I wonder if that should
be left to the window manager (so e.g. the user can decide what’s the
main monitor). Actually, the proposal mentions nothing at all about
what happens to the other monitors in a multimonitor setup. What’s
going on in that case?

(honestly the real issue here is that the current concept of
multimonitor is wrong, I’d rather keep monitors separate and give each
one its own workspace, which also would have the bonus of making
fullscreen trivial, but that’s outside the scope of this change)

2012/10/27 Edward Rudd :>

On 10/23/2012 04:49 PM, Ryan C. Gordon wrote:

Following up, this proposal has now been posted:

https://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

–ryan.

I like the proposal for the most part (and the relaxing of MUST in several
places from the resulting documentation)

The only thing I saw missing was the inability to specify the xinerama
screen to have the game go full-screen on. Specifically how that should be
chosen (e.g. do we go based on what the offset coords are for the window?).
IMHO in a perfect world (I know dreaming). I would want to preset the user
a selection of which monitor and then what resolution on that monitor in a
game.

Otherwise I do like the proposal, and I do think that the window manager is
the best place for this interaction to happen… If you look at how OS X has
revamped their full-screen support is 10.6 and further in lion they are
basically doing the same thing. as the OS to set me to fullscreen and not
and let it handle the “mess” associated with it.


Edward Rudd
OutOfOrder.cc
317-674-3296


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