Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

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

On Thu, 25 Oct 2012 15:20:45 -0400 Owen Taylor <otaylor redhat com> said:

> On Tue, 2012-10-23 at 16:26 -0400, Ryan C. Gordon wrote:
> > 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.
> 
> I'm generally in favor of your approach dealing with this at the
> compositor and desktop level instead of having the application deal
> directly with changing the resolution. It first allows a lot more
> flexibility in how to best handle the situation, and second is less
> likely to have different parties stepping on each others toes and
> leaving the user in a bad situation.
> 
> But you in letting the environment take advantage of that flexibility I
> think what you've written here is too restrictive.
> 
>  "the Window Manager  MUST change the resolution of the window's screen
>   to one that most closely matches the window's current dimensions."

i would agree. the wm SHOULD attempt to get the closest affect of this.
changing resolutions should be recommended, but it CAN just paste letterbox
black around the window and center it if it likes. this of course then
requires the game grab the mouse cursor in the event that it wants to use the
screen edges eg as  scroll areas like many RTS games do.

> Why not let the Compositor decide how to best present the window? If
> the compositor can change the resolution, then it can resolution. If the
> compositor would rather scale the window up, then it can scale up.
> In the xwayland world, the compositor would probably just set the video
> display to scan out directly from the window pixmap.
> 
>   "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."
> 
> This is just a SHOULD or quality-of-implementation issue - the
> application itself doesn't care that this happens. (When changing the
> resolution, it may be impossible, since applications can listen directly
> for resolution changes.)

agreed. wm should try, but doesn't need to. let users complain to the
wm/desktop that doesn't do this as a bug if they want.

> In general, I think what is important here is that the application is
> describing an intent about the treatment and the window manager is free
> to do whatever it can to best implement that.
> 
> Beyond that on specifics:
> 
>  * How do you see this working with respect to multihead?
>    Can it be used in conjunction with _NET_WM_FULLSCREEN_MONITORS?

that is actually one of the more interesting aspects of this. in fact if i have
2 or 3 screens - which screen should it go on? if game asks for 1600x900 and
one of my screens is 1600x900 and the other 1920x1080 - does wm move the window
to the "already" 1600x900 screen? then comes the case of - what if we have 2 or
3 screens and we want our game to SPAN all the screens? eg create some
immersive display with wide field of view? the realistically best way to do
this is for the game to create multiple top level windows, make 1 the "master",
then mark each with properties indicating where they should be placed relative
to the master. the wm will have to give feedback here other than relying on just
window geometry.

>  * Would it make more sense to simply resize the window to the
>    size of the closest resolution rather than requiring the window
>    manager to obscure other portions - that would have a couple
>    of advantages:
>   
>     - It would allow direct scanout from the window's front buffer,
>       which is not an option if the window manager has to draw
>       black-bars.
> 
>     - It lets the application chose whether it wants to just draw
>       at the bigger resolution, or use black areas.

while this sounds sensible, i think ryan will come around with something like:

"gems are often written to handle N modes, not "arbitrary sizes", and thus
present those N modes explicitly after finding the intersecting set of modes
and what hw can do". i ssuspect this should be an additional property like
_NET_WM_STATE_FULLSCREEN_EXCLUSIVE_APPROXIMATE allowing the wm some leeway *IF*
the game supports adapting somewhat to the new size.

>  * The requirement to iconify when the window loses input focus
>    conflicts with desktop environments where iconification is not
>    part of the user interface. I think any specification should
>    instead require switching the window back into windowed mode,
>    or to allow both.

i suspect the intent here simply is to say that the window should not be
resized after this point as the game wants to live in its "1 resolution to rule
them all" window world. a desktop can minimize or simply hide the window - do
whatever it likes as long as the window is not resized.

>  * I don't like the reference to "current dimensions" - current
>    dimensions is something that the app doesn't control. It would
>    be better to specific the sizing with respect to the geometry
>    hints to on the window - for example, the minimum size of the
>    window.

hmm - this has precedent. the current size before a window is mapped can be
neither min nor max size. current size can be defined as the size of the last
configurerequest from the client. (or well last configurerequest on the
window). using min and max size hints can provide constraints for an
approximate match as above. ie if wm has freedom to fuzz about it can try
"current size" and if that doesn't work try resolutions UP to max and DOWN to
min size as it sees fit. in fact future configurerequests for new sizes can act
nicely as resolution change requests. :)

>  * I'm not sure that I fully understand how everything that you've
>    bundled in here fits as a unit. The "EXCLUSIVE" part of this
>    proposal - the specification of what happens when the window
>    loses focus - seems actually like a behavior that would apply
>    as much to a presentation program as to a game. Do we have
>    in mind a class of applications that wants different behavior?

in this i agree. in fact E17 already does this to all fullscreen windows. it
iconifies them when they lose focus (and un-iconifies them when they gain it) to
avoid window resizes and to "get them out of the way" when not focused. this
kind of behaviour is separate to the exclusive hint, but a request that the
window not be resized arbitrarily during its lifespan like this is reasonable.

>    Perhaps this just needs to be some sort of advice-to-implementors
>    about what happens when a full-screen window loses focus?
>    (With details about what should happen for windows that are
>    transient-for that window like dialogs.) And then the rest
>    of this is simply a flag about how the application wants to be
>    fullscreened, rather than a separate type of fullscreening?

i think its up to the wm here for transient-for's (for the exclusive fullsscreen
window). i know e17 allows transient-fors to be on top of a fullscreen window
if they are transient-for that window  it wont iconfiy the fullscreen window in
that case. i dont see how this hurts the exclusive mode thing (these dialogs
just are now at a different screen resolution). i would expect though that any
app using this exclusive hint wouldnt bother with transient's :)

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