Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Owen Taylor <otaylor redhat com>]

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

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

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?

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

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

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

   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?

- Owen