Slashdot Mirror
A Proposal To Fix the Full-Screen X11 Window Mess
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."
So, ugh... fix your desktop?
With Linux finally becoming a more "proper" gaming platform (i.e. Steam and others), it's "about time" that this is dealt with. _NET_WM_STATE_FULLSCREEN_EXCLUSIVE, where have you been my whole adult life? Gotta hand it to Ryan Gordon ("Icculus," as I recall) for consistently making Linux gaming that much more viable.
Who is still running a CRT? Who wants any program to change the resolution of their screen?
This strikes me as the wrong solution to the problem: A program should instead request the "current monitor's resolution" (because there can be more than one!) set its display area to that size, and then tell the window manager to "fullscreen" it by removing title bar and border decorations and moving it to (0,0) of that monitor. But NEVER EVER RESIZE MY MONITORS. Thank you. The window manager should always be superior to the app, and one should always be able to manage the window (task switch, move to another desktop, etc) using the window manager, regardless of what the app thinks it is doing.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
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
KDE doesn't need the help.
I still think X needs to go. For truely forward thinking, it needs to be replaced. Just look at Andriod. Andriod would not be useful if it was forced to use X.
Frankly, X does too many things that too few people need. It was designed for a different era and it scales to modern workflows very clumsily. Multi-monitor desktops and gaming on windows is effortless. On X it's frankly a chore.
Sorry, no, network transperancy is not an important feature anymore. Probalby implemented by .001% of regular users. VNC/RDP style remote access is the way it's done now. An no, nobody cares if it's tehnically inferior. It's hundreds of times easier to implment and use.
Modern toolkits pretty much ignore 95% of X's built in features an just pass bitmaps.
Yeah, X has lots of cool things but you have to realize most of them are impractical or unnecessary. Today we really have the memory, computational power, and bandwith to bang whatever we want on to the screen with out any trouble. The latency and overhead X present are the enemies today.
Now stop. - Yes you, stop. I know you're about to type up a 10 paragraph screed about how you ported X ap to obscure platform Y, or remotely managed 10,000 servers with facial twitches and GTK. Just stop. Your use case does not represent the vast majority of computer users. It doesn't even represent a full fraction of a percent.
Legacy baggage and clinging to old ideas spawned x.org. The same thing is what will spawn whatever is to replace X.
This is exactly how some games work on Mac OS X, for instance Source-based games like Portal and Half-Life 2. They don't muck with the actual screen resolution, but just render into an offscreen buffer at whatever resolution ant blit it stretched to the full screen. Switching from the game back to other apps doesn't disturb the desktop in any way. Would definitely love to see more Linux games using this technique.
Chu vi parolas Vikipedion?
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.
This works - but wastes both ram space and performance.
Not sure what 'mess' is referred to in the title but I sidestepped the issues I met with Baldur's Gate by running it in its own X-server on a separate VT.
As I recall it just took a simple script to start the server and the game, and one extra command to make the mouse cursor less fugly. My main desktop remained completely undisturbed and just an Alt-F7 away. A little polish and this approach could be a good general solution, no?
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.
Not what I heard. Sounded more like "why the heck are you making the problem more complicated than it needs to be?
Ideally, I am not sure why the heck a game of the full-screen sort would need X11 to begin with. Perhaps for portability. Wouldnt want to try and run games over remote X either, so why?
Assuming there are nonetheless plenty of reasons in practice to want to make that work (starting with 'lots of existing games that do require it' of course) then why not just set them to start their own exclusive server instance, tuned for that purpose?
If it's a game that's supposed to be running full screen and not interacting with a desktop, why then force a desktop to be part of the environment at all? Keep it simple.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Exceedingly little, though.
Modern games render to more than one off-screen buffers already (necessitated by HDR, deferred shading, and other fun things), only blitting and gamma-correcting the final bits to the screen's framebuffer at the very end.
The tiny amount of RAM occupied by the 8-bit framebuffer to accommodate a large screen resolution is dwarfed by these several framebuffers, some which will use 16-bit components.
The amount of GPU needed to draw a solid full-screen quad really is too trivial to care about.
For the myriad of responses that brought up this point: the answer is video card hardware scaling.
And this is exactly the solution that the Xbox 360 uses. A lot of newer games are fill rate limited. Because of the complexity of the pixel shaders that games use, the AMD Xenos integrated GPU in the Xbox 360 (similar to a Radeon X1800) can't run it with an acceptable frame rate at any resolution over 1024x576. So games use the Xenos's scaler to turn 1024x576 into 1280x720 or 1920x1080 pixels for the component or HDMI output.