Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Fri, 26 Oct 2012 09:04:40 +0200 Martin Gräßlin <mgraesslin kde org> said:

> 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?

it only becomes active if the window is focused, so it doesn't matter until
window is "focused" (active). :) you can have 10 of these and alt-tab between
them and each time your screen changes resolution. if the wm etc. code is done
right, this will work just fine. :)

> > 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.

i think this is an internal implementation inside of kde - feel free to use
private properties or any other mechanism that will work. for things like e17
it doesn't need to as the randr stuff is built in. the mechanisms via which to
talk to your components (like krandr) may be custom from desktop to desktop
(eg via dbus or unix sockets instead of properties), thus i think its best that
the standard doesn't define this and leave it up to the wm/desktop to figure
out.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com