Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Owen Taylor <otaylor redhat com>]

On Mon, 2012-11-19 at 15:56 -0500, Ryan C. Gordon wrote:
> Just pinging about this; anyone have any problems with this draft 
> (besides the one concern about specifying a monitor for the window)? 
> Everyone happy? Everyone already overwhelmed by the upcoming holidays?  :)

I've had a chance now to go over the current draft in detail. I think
it needs more work- it isn't ready to go in as is.

I'm still not happy about the relationship between _NET_WM_FULLSCREEN
and _NET_WM_FULLSCREEN_RESOLUTION. The draft is written as if these are
two independent concepts with the only connection that they can't be
used as once.

What if we have a PDF viewer, a movie player, and a game, all with
fullscreen modes. Maybe the PDF viewer and the game should behave
slightly differently - but what about the movie player? I don't think
anybody would argue that that it should behave more like the PDF viewer
or more like the game depending on whether it wants to change the output
resolution or not. Or what about a game that is happy running at the
default desktop resolution - does it need to use
_NET_WM_FULLSCREEN_RESOLUTION to get "gamelike" behaviors.

I'd like to propose a basic rule here - that we treat three things
independently.

 * An app that wants the resolution changed when its fullscreen
   window is displayed.
 * Any fixes that are needed to the definition of a fullscreen window,
   like specification of what happens when there are multiple
   fullscreen windows or when a fullscreen window loses input focus.
 * Any behavioral differences what we need for a fullscreen game and
   for a fullscreen PDF viewer or web-browser.

and for now, we try only to figure out the right fix for the first one.

So, does it make sense to use a separate state for "fullscreen with a
resolution change" compared to "fullscreen"? I don't think it's
unworkable - so if that's the general consensus, I'm willing to go along
with it - but what would make more sense to me in the context of the
specification is to parallel _NET_WM_FULLSCREEN_MONITORS:

  _NET_WM_FULLSCREEN_DIMENSIONS, width, height, CARDINAL[2]/32

  A size that the application prefers when displayed fullscreen.
  If set by the application, when the window is in the fullscreen
  state, the window manager SHOULD change the effective display
  resolution so that the pixel size of the window is as close as possible
  to the specified size while being equal to or larger than
  the specified size in both width and height. If no display resolution
  would permit the given size, the window manager SHOULD use the
  largest display resolution possible.

  The determination of what monitor or monitors the fullscreen window
  will occupy MUST be done as if _NET_WM_FULLSCREEN_DIMENSIONS was not
  set. If the application wants to ensure that a particular monitor
  is used because the available resolutions for that monitor better
  match an intended size, it it MUST set _NET_WM_FULLSCREEN_MONITORS.

  Rationale: a game or similar application might want to take advantage of
  scaling capabilities of the display subsystem. Making the window manager
  responsible for changing the resolution provides more information to the
  desktop environment about what is going on and robustness if the
  application quits unexpectedly.

I still think that letter-boxing should be left to the application - it
will be more efficient, more flexible, and just a few lines of code.

The reason that I wrote the above to disallow picking the monitor based
on the dimensions is to avoid games inadvertently jumping between
monitors if the user changes the screen resolution preference. If an
application wants that, they can use _NET_WM_FULLSCREEN_MONITORS.

 _NET_RESOLUTIONS - as written, this has a couple of problems - First,
  resolutions are just width/height not x/y/width/height. Second, it
  doesn't take multi-monitor into account.

  I think probably we should just drop this for now - as was
  pointed out, software scaling by the compositor under current X has an
  input-redirection problem.

_NET_FULLSCREEN_TEMPORARY - I don't think this works - you've described
  it as being useful for some app to ignore *changes* - but what
  if an application started up when _NET_FULLSCREEN_TEMPORARY was
  already set - the geometry would be indeterminate.

  I think any solution would require knowing what the use cases are
  for listening to RANDR changes, figuring out what the apps actually
  need to calculate, and exporting that (_NET_WM_VISIBLE_DESKTOP_AREA
  or something.) But I think the currently known examples - file
  managers drawing the desktop, panels - are components of the desktop
  environment, so it's probably better to just leave it up to the
  desktop environment rather than making a stab toward a solution.

- Owen