On Tue, 2012-10-23 at 16:26 -0400, 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.
I'm generally in favor of your approach dealing with this at the compositor and desktop level instead of having the application deal directly with changing the resolution. It first allows a lot more flexibility in how to best handle the situation, and second is less likely to have different parties stepping on each others toes and leaving the user in a bad situation. But you in letting the environment take advantage of that flexibility I think what you've written here is too restrictive. "the Window Manager MUST change the resolution of the window's screen to one that most closely matches the window's current dimensions." Why not let the Compositor decide how to best present the window? If the compositor can change the resolution, then it can resolution. If the compositor would rather scale the window up, then it can scale up. In the xwayland world, the compositor would probably just set the video display to scan out directly from the window pixmap. "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." This is just a SHOULD or quality-of-implementation issue - the application itself doesn't care that this happens. (When changing the resolution, it may be impossible, since applications can listen directly for resolution changes.) In general, I think what is important here is that the application is describing an intent about the treatment and the window manager is free to do whatever it can to best implement that. Beyond that on specifics: * How do you see this working with respect to multihead? Can it be used in conjunction with _NET_WM_FULLSCREEN_MONITORS? * Would it make more sense to simply resize the window to the size of the closest resolution rather than requiring the window manager to obscure other portions - that would have a couple of advantages: - It would allow direct scanout from the window's front buffer, which is not an option if the window manager has to draw black-bars. - It lets the application chose whether it wants to just draw at the bigger resolution, or use black areas. * The requirement to iconify when the window loses input focus conflicts with desktop environments where iconification is not part of the user interface. I think any specification should instead require switching the window back into windowed mode, or to allow both. * I don't like the reference to "current dimensions" - current dimensions is something that the app doesn't control. It would be better to specific the sizing with respect to the geometry hints to on the window - for example, the minimum size of the window. * I'm not sure that I fully understand how everything that you've bundled in here fits as a unit. The "EXCLUSIVE" part of this proposal - the specification of what happens when the window loses focus - seems actually like a behavior that would apply as much to a presentation program as to a game. Do we have in mind a class of applications that wants different behavior? Perhaps this just needs to be some sort of advice-to-implementors about what happens when a full-screen window loses focus? (With details about what should happen for windows that are transient-for that window like dialogs.) And then the rest of this is simply a flag about how the application wants to be fullscreened, rather than a separate type of fullscreening? - Owen _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list