Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

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

On Wed, 24 Oct 2012 17:49:08 +0200 Martin Gräßlin <mgraesslin kde org> said:

> Hi Ryan,
> 
> 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 for bringing up the issue, we (KDE window management) actually hate 
> that games change the resolution and I don't think that moving the 
> responsibility to the window manager will solve anything.
> 
> I try to explain the problems we have with this from the workspace 
> perspective. In KDE Plasma we have a desktop shell which is strongly widget 
> based and our users arrange the widgets on the whole screen. Also windows are 
> manually placed and so on.
> 
> Now if a game changes the resolution this gets completely destroyed. The 
> manual layout is completely broken and cannot be restored (!) once the screen 
> resolution changes back. A resolution change normally does not happen 
> automatically, but only after a user e.g. plugged in an additional screen and 
> configured it.
> 
> Also windows get completely messed up when the resolution goes down. Most 
> likely too large windows will get maximized and they will stay maximized once 
> the screen resolution is changed.
> 
> For the user it is not visible that the screen resolution changed at all. All 
> she sees is that the desktop is f*** up once she ended the game. Even worse
> if the game crashed.
> 
> A very unpleasant experience and our users are angry about it (I could show 
> you bug reports...).

and that is what this hint is trying to fix - by passing the work back off to
the wm to do this in an organised way "temporarly" for this fullscreen window
and to restore it back to where it was when the window goes away or loses focus.

> Moving the responsibility to the window manager to change the screen 
> resolution will not solve this issue. It just increases the complexity of
> what could go wrong (hello Intel drivers crashing KWin when going back from 
> unredirection state about a year ago).

i beg to differ. it provides the only sane path to try solve it. otherwise
games will continue to go behind the desktops back and go right to randr and
fiddle with the screen. driver bugs aside - this hands the responsibility back
to the desktop and it could choose to ignore this hit and just letterbox the
window (despite the proposal - i think its too strict there), but proposal
aside, if you dont support it - game will keep chaning resolution via randr if
you like it or not and give you these bugs (if there are any).

> Also in the case of KDE Plasma Workspaces the window manager is not at all 
> responsible for handling the resolution. This is done by a daemon called 
> krandr. I will not add code to change the resolution as that is nicely
> handled by krandr. So we would need to announce the support only if the

then you just pass a request via dbus, other x client messages or whatever
other ipc mechanisms you have off to krandr to do it for you. that's easy
enough, but kwin as the "entry point" for the request should first handle it.
the rest is an implementation detail of your environment.

> daemon is present - this is something we would most likely not be able to
> guarantee correctly as in session start KWin should be started before krandr
> and it's possible that KWin is run outside a KDE Plasma session.

perfectly possible. add the ability to know once krandr has started THEN
advertise the ability to do this property. easy enough to do. you could just do
a nasty hack and set an environment variable when kwin is run inside a full kde
session with krandr... and if env var set.. then advertise feature... but this
is a problem "kde side" and i don't think kde's specific problems with
implementation or design should preclude a property like this.

> Last but not least I have never understood the need to change the resolution. 
> If the screen is larger than the resolution supported by the game, why not
> run in windowed mode? At least I (though I'm not a gamer) hate the pixel
> graphics I get when running a game which supports only 1024x768 on my full HD
> computer screen.

performance. pure and simple. if your window is the exact size of the screen
resolution (and at 0, 0 and nothing is on top) the driver can do buffer swaps
instead of copies from back to front buffer. this reduces the cost of a swap to
0 - ie no copies at all. it's a buffer base address change during next vblank.
so we just chopped out copying several mb of pixels per frame. in addition it
now allows the number of pixels to be rendered to be lowered, thus lowering
rendering cost and upping framerate. it's a trade-off a game or gamer can make -
they prefer more effects/quality or do they prefer more framerate. unless you
invest a small fortune in a gpu, you can't have both (and sometimes you don't
even have the option of investing in the gpu, or the game is so demanding no
gpu exists that lets you have your cake AND eat it).

> Although I dislike the fact that games change the resolution and tend to just 
> announce support for this extension without implementing it ;-) I forwarded 
> your mail to our krandr maintainer to get further input.

the point of an extension like this is to stop the games from implementing any
resolution changing code and hand it off to the wm (and thus back off to the
desktop environment). if desktops support this and libraries like SDL do too,
then the people on those desktop environments will have a much improved
experience with games. this is a game both the game side (SDL etc.) and desktop
side have to play together. if we both do, we both win. games are less a source
of bugs/annoyance and are simpler, and desktops have their displays messed up
less.

i'm all for an extension like this. i think the only debates are the "nitty
details" like "must vs should" and what is the current window size, should we
use min and max size hints as well, and what about more than 1 screen? maybe we
don't have to solve these now, but we need to ensure that solutions to these
are not made harder/impossible by this exclusive fullscreen hint.

> Best Regards
> Martin Gräßlin
> 
> KWin maintainer
> > 
> > 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.
> > 
> > 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.
> > 
> > 
> > _______________________________________________
> > wm-spec-list mailing list
> > wm-spec-list gnome org
> > https://mail.gnome.org/mailman/listinfo/wm-spec-list


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