Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

["Ryan C. Gordon" <icculus icculus org>]

> ok - i'm cycling around to this after some e17 stuff. i have an issue:

Cool, thanks for getting back to this!

> trying to syncrhonize the randr event changes with events indicating changes in
> this property is bound to be hell. what rationale would apps have to listen to
> BOTH randr events AND property changes here? i see the logic of this list - it
> indicates which windows have been treated specially by the wm to have screens
> change resolution.

This was put in at Martin's suggestion: the concern was that there might 
be apps listening for XRandR events directly, and they should have a 
mechanism to decide if the resolution change was something they should 
react to (user is changing their desktop), or something they should 
ignore (game is taking over the monitor). It's a totally opt-in thing, 
but in the worst case you have apps doing what they do now in response 
to a game changing the mode. I suspect the surface area of apps that 
listen for XRandR events directly is extremely small, though.

The idea I was going for was that the WM makes sure this property is set 
before trying to do a resolution change for the game at all. Things that 
care then use XGetWindowProperty() while handling the XRandR event 
instead of trying to synchronize with a PropertyNotify event. Maybe 
that's a goofy idea, though. Psuedocode like so:

 ...loop for events...
 case XRRCrtcChangeNotify:
   XGetWindowProperty(dpy, rootWin, _NET_FULLSCREEN_TEMPORARY, ...);
   foreach (window in net_fs_temp_array) {
       if (window is in (x,y,width,height) specified in event) {
           break;  /* ignore this event, it's temporary. */
       }
   }
   /* handle this event, it's a legitimate change... */
   /* ...or a legacy app, which we can't do anything about anyhow. */

My honest opinion is that apps listening for XRandR events directly get 
what they deserve, but if this piece of the spec is workable, they can 
at least attempt to do the right thing.

> this is not possible in x11 without event redirection/transformation too
> (xevie being dead.. i put this in the "can't be done" list). even then that is
> tricky to get right. perhaps you wish to word this more like:
>
> "In relation to _NET_WM_STATE_FULLSCREEN_RESOLUTION, the Window Manager MAY
> simulate a physical resolution change by instead letterboxing' a window ans
> blanking out unused regions, making the window occupy the fullscreen visually as
> the rest has been blanked out".

People really seemed to want wording like this in the last round of 
comments to do some magic with compositing window managers, and I'd like 
them to have the wiggle room. I think the intent is clear, so I'll let 
those that really really don't want to switch resolutions come up with 
the clever implementations.

(me personally? I want my WM to change the resolution, not fake it, but 
certainly lots of people felt strongly about both approaches.)

> "If there is no resolution that can completely contain the window's undecorated
> size hints, the Window Manager MUST refuse to allow this hint."
>
> in this case.. how does the app KNOW it has been refused? it knows when it
> succeeded, but not when it failed. as i read it... ? did i miss something?

I was thinking that you'd query _NET_WM_STATE and see if the property 
was listed (existing spec for _NET_WM_STATE says "The Window Manager 
MUST keep this property updated to reflect the current state of the 
window.")

Perhaps it would be better to rely on _NET_WM_ALLOWED_ACTIONS...if the 
Window Manager thinks it can work with the current min/max size hints, 
then it lists _NET_WM_ACTION_FULLSCREEN_RESOLUTION, otherwise, it 
doesn't. This is what the spec vaguely says already. Maybe we should 
drop the explicit text about refusing the hint (although what's the WM 
going to do if it can't accept it?).

The basic concern is that we should have a way for the app requesting 
fullscreen to know if something went catastrophically wrong. I'm not 
married to any specific approach, though.

> for now the _NET_RESOLUTIONS hint should do for advertising all available
> resolutions (and even monitor locations) to clients to pick from.  we're find
> for a single window fullscreening to a single monitor here. maybe we should
> worry about "spanning/filling  multiple screens" at some future date. i'd like

I suppose there's no reason that a listed resolution can't be 
(0,0,width_of_two_monitors_side_by_side,height), but I think it's beyond 
this spec to really dig into the details.

I have no doubt someone out there wants to make a game span over two 
monitors, but all I've ever gotten was bug reports when a game did so by 
accident.  :)

My concern is being friendly to apps that want to go fullscreen, and 
maybe specify a monitor to use (and, by extension, have multiple windows 
do it on multiple monitors, if they're being really fancy). I think 
getting fancier than that is going to complicate the spec for little gain.

But I think that between _NET_RESOLUTIONS and the existing 
_NET_WM_FULLSCREEN_MONITORS property, we haven't spec'd ourselves into a 
corner about spanning windows across monitors. I'll make a note about it 
in the spec.

--ryan.