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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]