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

Forest_Hale · January 31, 2012, 9:00pm

Good report on the situation, thanks.

Mostly I’m saying that when possible we should use “modern” techniques to accomplish what the users want.

If not fullscreen, we should not grab keyboard, this has nothing to do with X extensions of any kind.

If fullscreen and the modern features (XRandR, NET_WM_FULLSCREEN) are supported then we should not be grabbing keyboard.

When no video mode change is requested, this comes down to only NET_WM_FULLSCREEN as a consideration.

To put that another way; if using a managed window (which we should where possible) we should not be grabbing keyboard, if using an override redirect window then by design we MUST grab keyboard and
mouse for the entire duration of that window, but we should not be using an override redirect window unless absolutely necessary.

In general my preferred failure modes in a game are:
NET_WM_FULLSCREEN not supported - play game in a maximized window (with border).
XRandR not supported - disable video mode switching (can still do fullscreen).

Both of these solutions are very predictable in the user experience.

I’m not saying we need to remove XVidMode support or anything of that nature, only that these failure modes do not seem that bad to me, so I’m not sure why we NEED XVidMode and override redirect
window handling.On 01/31/2012 11:53 AM, Karl wrote:

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.

–
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

Karl_Glatzer · January 31, 2012, 10:05pm

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.

Good report on the situation, thanks.

Mostly I’m saying that when possible we should use “modern” techniques to accomplish what the users want.

If not fullscreen, we should not grab keyboard, this has nothing to do with X extensions of any kind.

If fullscreen and the modern features (XRandR, NET_WM_FULLSCREEN) are supported then we should not be grabbing keyboard.

When no video mode change is requested, this comes down to only NET_WM_FULLSCREEN as a consideration.

To put that another way; if using a managed window (which we should where possible) we should not be grabbing keyboard, if using an override redirect window then by design we MUST grab keyboard and
mouse for the entire duration of that window, but we should not be using an override redirect window unless absolutely necessary.

In general my preferred failure modes in a game are:
NET_WM_FULLSCREEN not supported - play game in a maximized window (with border).
XRandR not supported - disable video mode switching (can still do fullscreen).

Both of these solutions are very predictable in the user experience.

I’m not saying we need to remove XVidMode support or anything of that nature, only that these failure modes do not seem that bad to me, so I’m not sure why we NEED XVidMode and override redirect
window handling.

I agree that these failure modes are reasonable, but although i might be
a bit idealistic here i think we can do better at least in the long run

The thing with XRandR vs XVidMode is that they are actually used in
different ways when it comes to resolution changes in fullscreen
applications.

XRandR changes the whole desktop resolution and after that the window is
maximized and has either xoverride-redirect set or
_NET_WM_STATE_FULLSCREEN so the panels and everything else is hidden.

The problem is that changing the desktop resolution messes up the window
coordinates on some maybe most window managers when changing back to the
original resolution.

So in my opinion XRandR style mode switching is the way to go for
setting the desktops resolution, but not for temporarily setting the
resolution for a fullscreen application.

XVidMode doesn’t have this problem when used correctly since it changes
the current Viewport to zoom in on the Window. This works correctly with
xoverride-redirect windows since they are placed above the panels, but
_NET_WM_STATE_FULLSCREEN only works when a window is maximized which
would be wrong to do in this case and thus the window is placed under
the panels (in terms of coordinates not in the window stack i would have
used “below” in that context).

This makes the XVidMode viewport method superior to XRandR but sadly
isn’t applicable with the current wm-specs.

In Addition IIRC XVidMode is considered deprecated that’s why it would
be nice if XRandR could provide Viewport switching, too (if it doesn’t
already and we’re just not using it …).

PS: XRandR mode switching also seems to take much longer than simply
resizing the Viewport with XVidMode

PPS: There is also Xinerama but i guess we should sort this mess out
first before starting with the next one ^^Am 31.01.2012 22:00, schrieb Forest Hale:

On 01/31/2012 11:53 AM, Karl wrote:

slouken · February 1, 2012, 2:00am

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 <karl.glatzer at gmx.de> wrote:

Am 31.01.2012 19:49, schrieb Forest Hale:
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).

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

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

Karl_Glatzer · February 3, 2012, 7:10pm

I have started a discussion on the wm-spec mailing list for the wm-spec
specific parts of this discussion here:

http://mail.gnome.org/archives/wm-spec-list/2012-February/thread.html#00000

Sam I still would like to update SDL 1.2 to support the new fullscreen
handling when available and when SDL 2.0 has a well tested
implementation. I promise not to rush it like before and make sure that
it will not break the existing behaviour.

And of course everyone is welcome to help me and test it.

I’m also open to share my last attempt which works nicely when using
XRandR together with a WM that support _NET_WM_STATE_FULLSCREEN.Am 01.02.2012 03:00, schrieb Sam Lantinga:

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 <@Karl_Glatzer> wrote:
Am 31.01.2012 19:49, schrieb Forest Hale:
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).

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

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

Forest_Hale · February 3, 2012, 9:46pm

I know this reply won’t go to that list, but I want to just point out my views on Presentation Mode:

Most users are now on compositing window managers which are more than capable of scaling the window contents to fit the entire monitor, the idea of resolution changes is ridiculous on these WMs (and
yes I know this means scaling mouse coordinates).

What is wanted is a Presentation Mode with optional resolution override - how the WM implements this is up to the WM.
Handling methods I can see:
0. Fail - feature not supported, app is on its own.

Resolution Rejected - Presentation Mode active, changing resolution not supported (no good mode match) or disabled by user (there are good reasons for this), window is full desktop size and it is
up to the application how it chooses to render into this.
Resolution No Change - Presentation Mode active, requested resolution is the desktop resolution, or application did not specify a resolution.
Resolution Scaled - Presentation Mode active, requested resolution is less than desktop resolution, compositing is active and the application should render into the bottom left corner of the window
and expect the WM to scale it up for display.
Resolution Changed - Presentation Mode active, display resolution was changed to satisfy request as near as possible (>= width, >= height), window size may not exactly match request, it is up to
the application to render into this different resolution as it sees fit. (Similar to Rejected case)

A few examples on my own monitors (30" 2560x1600 monitors with 1280x800 and 2560x1600 as only supported modes):
1280x720 requested, compositing is off, result is 4 1280x800, display is changed (1280x800), it is up to the app to use this resolution properly, mouse is unchanged (range 0x0 to 1279x799).
1280x960 requested, compositing is off, result is 1 2560x1600, display is unchanged (2560x1600), it is up to the app to use this resolution properly, mouse is unchanged (range 0x0 to 2559x1599).
1280x720 requested, compositing is on, result is 3 1280x720, display is unchanged (2560x1600), WM will scale image, mouse is unchanged (range 0x0 to 2559x1599).

Also I should mention that in multi-monitor configurations it is almost never desirable to change display resolution (I.E. I’d prefer the first example choose 0 2560x1600), I’d even go as far as
saying the same about single monitor setups.On 02/03/2012 11:10 AM, Karl F. Glatzer wrote:

I have started a discussion on the wm-spec mailing list for the wm-spec
specific parts of this discussion here:

http://mail.gnome.org/archives/wm-spec-list/2012-February/thread.html#00000

Sam I still would like to update SDL 1.2 to support the new fullscreen
handling when available and when SDL 2.0 has a well tested
implementation. I promise not to rush it like before and make sure that
it will not break the existing behaviour.

And of course everyone is welcome to help me and test it.

I’m also open to share my last attempt which works nicely when using
XRandR together with a WM that support _NET_WM_STATE_FULLSCREEN.

Am 01.02.2012 03:00, schrieb Sam Lantinga:
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 <karl.glatzer at gmx.de> wrote:
Am 31.01.2012 19:49, schrieb Forest Hale:
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.

#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

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
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
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