Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

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

Sorry for my extremely late reply to this, I've been in crunch time on a 
project this month.

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

I think we've been trying to solve multiple problems here, under the 
expectation that we'll get one shot at it and have to live with the 
consequences. I'm a little uncomfortable with how large the spec is 
becoming, if we're being honest, so refocusing isn't a bad idea.

> 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

This is a pretty good idea. The whole idea started as a parallel to 
_NET_WM_STATE_FULLSCREEN, but perhaps that was the wrong place to start. 
An added benefit to this approach: talk of "fullscreen" windows in other 
places in the spec would no longer be ambiguous.

If there aren't objections, I think I'll rework the spec like this, 
probably lifting a lot of this language directly.

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

The x,y was to specify the monitor. It wasn't enough to say "I want it 
on the third monitor because it has a resolution I like," when a game 
(in Raster's example) might want to say "I need the monitor that's 
directly to the left of the other one I'm using."

I know Mac OS X has a control panel that lets you specify monitor 
position in relation to each other (including to the left and right, but 
also above and below), and I imagine X11 DEs could offer the same thing, 
if they don't already.

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

There seemed to be a real (some would say "passionate") desire to at 
least allow for this, in hopes that some other extension would make 
input-redirection possible at a later point. We don't have to talk about 
it directly, so long as the spec doesn't make it hard to implement later.

That being said, there are two other big uses for _NET_RESOLUTIONS:

- The DE can allow a user to specify resolutions a game is allowed to 
use (even if the X server offers 800x600 on an LCD, maybe the user only 
wants the native LCD's 1920x1200, or whatever).

- This allows applications to never touch XRandR at all. Without this, 
even if the Window Manager handles the actual resolution switch, the app 
still needs to use XRandR to query for available resolutions.

I'd say, even without rescaling, this is useful and important 
functionality which should remain.

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

This was something Martin wanted, so I threw it in there. I don't feel 
strongly about removing it, or replacing it with a better solution. 
Martin, any thoughts?

It would be useful to know what listens for XRandR events and what would 
behave badly. If it's just a system control panel, I don't think it 
matters. If it's everything using Qt, that could be a problem.

Then again, these apps already are responding to an XRandR event, as 
games change the resolution themselves, and the world hasn't ended. I'm 
inclined to say we drop this section, but it's possible I just didn't 
draft a decent approach.

--ryan.