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.




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