A Proposal To Fix the Full-Screen X11 Window Mess 358
jones_supa writes "The SDL developers Ryan Gordon and Sam Lantinga have proposed a window manager change to work out the full-screen X11 window mess, primarily for games. The proposal is to come up with a _NET_WM_STATE_FULLSCREEN_EXCLUSIVE window manager hint that works out the shortcomings of the full-screen hint used currently by most games, _NET_WM_STATE_FULLSCREEN. Ryan and Sam have already worked out an initial patch for SDL but they haven't tried hooking it to any window manager yet. Those interested in the details, information is available from this mailing list message. One of the key changes is that software would make the request to the window manager to change the resolution, rather than tapping RandR or XVidMode directly. Martin Gräßlin of KDE was rather wary about the patch and said that games changing the resolution just tend to mess up the desktop."
Seems like a reasonable idea, given a bit of time to mature as a spec. In KDE's case, a separate daemon from the window manager handles resolution changes so going through the WM would add complexity, and the plasma shell still has no way to realize that it shouldn't reflow the desktop widgets. Setting window properties seems like a sensible IPC method for communicating intent though (without making yet another aspect of the X desktop reliant upon the not-very-network-transparent dbus): "hey, I need to resize, but just for me so don't reshuffle the desktop and docks."
Sam Lantinga (from Loki Games) (Score:5, Informative)
I don't know if kids today remember, but Loki Games was one of the first commercial plays for big name games on Linux. Ended in tragic business troubles and financial doom.
It warms my heart to see that Sam Lantinga is still working on SDL.
That is all.
Re: rendering lower then scaling up to native (Score:4, Informative)
This works - but wastes both ram space and performance.
Re:Hilarious excuses (Score:4, Informative)
This is the exact purpose of this proposal, to create a new signal that would tell the window manager that the change is temporary and only takes effect while a specific window has focus. This way they window manager would know there's no need even to move the icons in the first place.
Re:CRT's (Score:4, Informative)
For the myriad of responses that brought up this point: the answer is video card hardware scaling. E.g. add a flag _NET_WM_STATE_SCALING_ALLOWED which directs the WM to use hardware scaling from a fixed-size framebuffer, as is done by video players. Not only can you make it full screen, but you can resize it to any arbitrary shape and size (e.g. don't cover your widget bar, etc). Then the Window Manager decides what is "fullscreen". It could even make an app span more than one monitor when "fullscreen", or just one.
Re:Sam Lantinga (from Loki Games) (Score:3, Informative)
Re:Trying to solve the wrong problem (Score:5, Informative)
X is a very old protocol, with a lot of things that need to be implemented in order for something to say that it "speaks X". Things like font rendering and 2d drawing routines. Things that nobody actually uses anymore.
X used to be in charge of providing font rendering and such, but now libraries like Freetype and Cairo do it instead (and do it better). X used to be in charge of accelerated video, but now we have good OpenGL support and Kernel Mode Setting. The only thing X really does now is act as a proxy between window managers and applications. But X still has support for all the old stuff, and so it's huge and lumbering.
Wayland is a new protocol designed to be used between window managers and applications directly. In a new breed of window managers, the window manager itself will set up the screen and draw to it using kernel mode setting and opengl, and it will communicate and delegate windows to applications by talking the Wayland protocol. So there's nothing like the X server sitting between them anymore: the window manager runs directly on the console, and talks directly to applications.
This might sound like it would cause a lot of duplication of effort, and in one sense that's true. However, the amount boilerplate code needed to set up a simple Wayland-speaking window manager is about the same as the amount of boilerplate code needed to set up a simple X11 window manager. Except with the Wayland case, there's no huge X server sitting between applications and the screen, because Wayland is so simple the window managers can speak it directly.
One side effect of this is the Wayland library API is *much* simpler to use than the X libraries, so it becomes a lot easier to write new experimental window managers. I expect we'll see a lot of new WM's after Wayland becomes standard. Another plus is that Wayland has built-in support for multiple pointers and arbitrary window transformations, and that's an extremely nice touch for multi-touch screens.
Re:Dump X (Score:2, Informative)
Wayland has an X compatibility layer, sure, but you may also be pleased to know that there are efforts underway to get native Wayland network transparency.
See, the cool thing about wayland is the protocol is written to be flexible enough to have some other program handle the network transparency part, seamlessly. It's not part of the core design of wayland simply because it doesn't have to be in the core at all.
An added bonus of this flexibility is the ability to do network-tranpsarency things that even X couldn't do, like move a window from one screen to another, possibly on another computer entirely. Yes, I'm serious. It's awesome.
Re:Music to my ears! (Score:5, Informative)
I didn't see any information in the article, but what exactly is the problem with X11 full screen support? I don't game in Linux, and this is the first time I've even heard of this.
The biggest issue is that when the game goes full-screen, it changes the resolution to whatever the game is set to--which may or may not be what you keep your desktop at. Then, when you exit the game, the icons are usually huge; the taskbars are usually all messed-up (even when "locked!"), and you have to futz around to make it usable again. Also, many games on Linux won't even let you Alt-Tab to other windows! Either nothing happens; or the resolution won't be correct; or the game crashes. It's really unpleasant to deal with. Also, it's worth noting that many games (especially Linux games, sadly) are extremely limited about what resolutions they'll let you use--so even if you want to set the game to your native resolution, it might not work or let you even try.
Re:Music to my ears! (Score:5, Informative)
The article contained a lot of detail. The current mechanism is a two-step thing where the application first requests full-screen control from the WM. The WM then resizes the window to fit the current screen (which may not make the game happy), removes decorations, and then gets out of the way. Then the game changes the resolution and resizes the window again. The resolution change notification is delivered to the WM, which then propagates it to all of the applications, so if you want to play a fullscreen game at 640x480 then you may find that all of your application windows have resized themselves to fit in this screen when you exit it. The game then runs (hopefully) and if it crashes then in theory the WM is responsible for restoring the video mode, but in practice it doesn't know for certain that the game was responsible for changing it, so it may not.
With the new proposal, the game resizes its window to the resolution it wants and then requests full screen mode. The WM should then change the screen resolution to the closest to the current window size and doesn't propagate the resolution change notification to any other applications. This means that nothing else gets resized. If the game crashes, or if you do any kind of switching out of the game, then the desktop resolution will be restored.
And, while it's fashionable to hate X11, it's worth noting that Windows and OS X both suffer from some of the problems that this proposal is intended to fix.