Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Tue, 23 Oct 2012 16:26:20 -0400 "Ryan C. Gordon" <icculus icculus org> said:

this is good. my only concerns are more related to this not handling multiple
screens. what will you do when you want a game to span 2 or 3 screens with
multiple viewports (eg side monitors with different view angles to provide
wider field of view) etc.? i'd vote for multiple windows in this case but then
some hint telling the wm which window is master, slave and where they should be
placed relative to eachtoher.

> I've been doing Linux video games for over a decade now, and we've never 
> really had a satisfactory means to handle fullscreen games on X11. I see 
> this mailing list discussed fullscreen problems briefly in February, but 
> I wanted to make a formal proposal of how the system should handle 
> applications that want to "go fullscreen."
> 
> This is a first draft that Sam Lantinga and I put together, envisioning 
> how we would like SDL to cooperate with the Window Manager to solve the 
> problem.
> 
> Being a first draft, anything that's silly is totally open to change. We 
> have an SDL patch that implements the client side of this spec, but no 
> one's tried to implement the Window Manager side of things yet.
> 
> Comments and criticism are appreciated!
> 
> Thanks,
> --ryan.
> 
> 
> 
> This is an addition to the spec for _NET_WM_STATE:
>       http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id3076525
> 
> Rationale:
> 
> There are some problems with the current _NET_WM_STATE_FULLSCREEN hint 
> that we would like to address.
> 
> First, it is not explicit in its instructions to Window Managers; for 
> example, we found some Window Managers required the window to be marked 
> resizable (Metacity) and others did not (XFCE); it's not clear which is 
> correct. It doesn't address virtual desktop size verses physical 
> resolution. This proposal tries to be very clear about exactly what 
> steps are required.
> 
> Second, the window manager needs to be responsible for changing 
> resolutions. If an app tries to use XVidMode, the virtual desktop will 
> not be resized and _NET_WM_STATE_FULLSCREEN will size the window 
> incorrectly. If an app instead tries to use XRandR, the rest of the 
> desktop may change irreversibly; icons may move around, other app 
> windows may shrink down. Worse still, if an app changes the resolution 
> with XVidMode or XRandR and then crashes before cleaning itself up, the 
> desktop will remain in the wrong state until the user takes heroic 
> measures to fix it. Moving this operation into the Window Manager and 
> associating it with a specific window lets the system know that this is 
> a temporary state change, instead of two discrete actions that may be 
> unrelated, so that it can protect desktop state appropriately. This also 
> has the side benefit of centralizing a complex negotiation with X11 
> extensions and multiple processes into one place--the Window 
> Manager--instead of every application.
> 
> Certainly _NET_WM_STATE_FULLSCREEN still has a place; it still makes 
> good sense that the example given, a presentation program, use that 
> hint. For applications like video games, which need more control over 
> window geometry and specific screen resolutions, a new hint is extremely 
> useful.
> 
> 
> Specification:
> 
> A Window Manager supporting this specification MUST specify 
> _NET_WM_STATE_FULLSCREEN_EXCLUSIVE in the list of atoms reported by the 
> _NET_SUPPORTED property.
> 
> (Added to the list of _NET_WM_STATE hints...)
> _NET_WM_STATE_FULLSCREEN_EXCLUSIVE indicates that the Window Manager 
> MUST change the resolution of the window's screen to one that most 
> closely matches the window's current dimensions. If no available 
> resolution matches exactly, the Window Manager MUST select the closest 
> available resolution larger than the window. The Window Manager MUST 
> center the window within the new resolution, remove any window 
> decorations, retain its original geometry, and grant that window input 
> focus. If the chosen resolution does not match the window geometry, the 
> Window Manager MUST obscure the rest of the screen so that the window is 
> the only thing visible. If there is no resolution that can completely 
> contain the window's undecorated geometry, the Window Manager MUST 
> refuse to allow this hint.
> 
> If the window loses input focus while fullscreen, the Window Manager 
> MUST revert the resolution change and iconify the window until it 
> regains input focus. The Window Manager MUST protect desktop state (icon 
> positions, geometry of other windows, etc) during resolution change, so 
> that the state will be unchanged when the window ceases to be marked as 
> fullscreen. The _NET_WM_STATE_FULLSCREEN_EXCLUSIVE and 
> _NET_WM_STATE_FULLSCREEN hints MUST NOT be used together by an 
> application; in such a case, the Window Manager must reject the 
> _NET_WM_STATE_FULLSCREEN hint.
> 
> If more than one window on the same screen requests the 
> _NET_WM_STATE_FULLSCREEN_EXCLUSIVE hint, the latest window MUST obtain 
> its requested resolution and input focus, and all other windows with 
> this hint MUST be iconified.
> 
> For example, a video game would use this hint.
> 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> https://mail.gnome.org/mailman/listinfo/wm-spec-list
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com