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...). 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). 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 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. 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. 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. 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
Attachment:
signature.asc
Description: This is a digitally signed message part.