On Tuesday 23 October 2012 16:26:20 Ryan C. Gordon wrote: > I've been doing Linux video games for over a decade now, and we've never > really had a satisfactory means to handle fullscreen games on X11. I see > this mailing list discussed fullscreen problems briefly in February, but > I wanted to make a formal proposal of how the system should handle > applications that want to "go fullscreen." > > This is a first draft that Sam Lantinga and I put together, envisioning > how we would like SDL to cooperate with the Window Manager to solve the > problem. > > Being a first draft, anything that's silly is totally open to change. We > have an SDL patch that implements the client side of this spec, but no > one's tried to implement the Window Manager side of things yet. > > Comments and criticism are appreciated! > > Thanks, > --ryan. > > > > This is an addition to the spec for _NET_WM_STATE: > http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id3076525 > > Rationale: > > There are some problems with the current _NET_WM_STATE_FULLSCREEN hint > that we would like to address. > > First, it is not explicit in its instructions to Window Managers; for > example, we found some Window Managers required the window to be marked > resizable (Metacity) and others did not (XFCE); it's not clear which is > correct. It doesn't address virtual desktop size verses physical > resolution. This proposal tries to be very clear about exactly what > steps are required. > > Second, the window manager needs to be responsible for changing > resolutions. If an app tries to use XVidMode, the virtual desktop will > not be resized and _NET_WM_STATE_FULLSCREEN will size the window > incorrectly. If an app instead tries to use XRandR, the rest of the > desktop may change irreversibly; icons may move around, other app > windows may shrink down. Worse still, if an app changes the resolution > with XVidMode or XRandR and then crashes before cleaning itself up, the > desktop will remain in the wrong state until the user takes heroic > measures to fix it. Moving this operation into the Window Manager and > associating it with a specific window lets the system know that this is > a temporary state change, instead of two discrete actions that may be > unrelated, so that it can protect desktop state appropriately. This also > has the side benefit of centralizing a complex negotiation with X11 > extensions and multiple processes into one place--the Window > Manager--instead of every application. > > Certainly _NET_WM_STATE_FULLSCREEN still has a place; it still makes > good sense that the example given, a presentation program, use that > hint. For applications like video games, which need more control over > window geometry and specific screen resolutions, a new hint is extremely > useful. > > > Specification: > > A Window Manager supporting this specification MUST specify > _NET_WM_STATE_FULLSCREEN_EXCLUSIVE in the list of atoms reported by the > _NET_SUPPORTED property. > > (Added to the list of _NET_WM_STATE hints...) > _NET_WM_STATE_FULLSCREEN_EXCLUSIVE indicates that the Window Manager > MUST change the resolution of the window's screen to one that most > closely matches the window's current dimensions. If no available > resolution matches exactly, the Window Manager MUST select the closest > available resolution larger than the window. The Window Manager MUST > center the window within the new resolution, remove any window > decorations, retain its original geometry, and grant that window input > focus. If the chosen resolution does not match the window geometry, the > Window Manager MUST obscure the rest of the screen so that the window is > the only thing visible. If there is no resolution that can completely > contain the window's undecorated geometry, the Window Manager MUST > refuse to allow this hint. What if there are two windows which want the exclusive state? Maybe a manager selection is a better solution? > > If the window loses input focus while fullscreen, the Window Manager > MUST revert the resolution change and iconify the window until it > regains input focus. The Window Manager MUST protect desktop state (icon > positions, geometry of other windows, etc) during resolution change, so > that the state will be unchanged when the window ceases to be marked as > fullscreen. The _NET_WM_STATE_FULLSCREEN_EXCLUSIVE and > _NET_WM_STATE_FULLSCREEN hints MUST NOT be used together by an > application; in such a case, the Window Manager must reject the > _NET_WM_STATE_FULLSCREEN hint. > > If more than one window on the same screen requests the > _NET_WM_STATE_FULLSCREEN_EXCLUSIVE hint, the latest window MUST obtain > its requested resolution and input focus, and all other windows with > this hint MUST be iconified. > > For example, a video game would use this hint. Maybe the window manager just set a root window property if the resolution is "temporarily" changed for a window? That would allow other parties to ignore the resize event. E.g. a desktop shell adjusting itself to randr events could look up the root window properties and ignore the randr event. Cheers Martin Gräßlin
Attachment:
signature.asc
Description: This is a digitally signed message part.