Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE



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.



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