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?
Just start the goddamn games on a totally different TTY. There, problem solved!
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'm pretty sure somebody did go in and fix the X11 desktop..... It was Apple w/ OSX.
Force ALL games to run at 640x480 -- problem solved.
Except for those i386 Linux systems who are trying to run Half Life 2 .. perhaps we should lower that resolution to 320x240, just to guarantee we're not butting heads with the window manager. After all, the first goal of every Linux game designer should be to ensure the tail log window you're running is properly proportioned at all times.
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.
The issue is that some programs change the screen resolution, and different programs take notice and rearrange their windows and icons when a screen resolution change notification takes place.
..and thus, those different programs never see the resolution change and therefore do not destroy the users chosen window and icon layout in their attempt to "fit" the temporary resolution that never should have mattered to them to begin with.
The problem is that there are no semantics in X that allow a program to change the screen resolution while NOT causing those other programs to do stuff.
This new flag is to signal these semantics. "Hey, we are changing the resolution, but we have this new idea called Exclusive Control over the display, so nobody needs to know that we did it because they cant render themselves anyways"
"His name was James Damore."
We can all agree the X is a gigantic mess. It needs replaced by something better -- badly.
Maybe instead of everyone jumping in and telling us how bad X is, someone could take a minute to explain what's wrong with it for us non-technical types.
Sheesh, evil *and* a jerk. -- Jade
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.
Why hasn't Linux taken off yet on the mainstream desktop (er, laptop)? Why don't average folks want to run Linux yet? Isn't it ready for prime time?
This is a hacked account, for which the owner can not be held responsible.
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.
These two files, window.c and image.c, are an entire simple GUI toolkit and an example program using that toolkit, for use with a Wayland compositor.
This directory is an entire compositing window manager that speaks the Wayland protocol. This is already impressively small, but keep in mind that most of the complexity here is in actually drawing to the screen and getting input events from hardware, something that Wayland has nothing to do with, and it's *still* small.
Wayland is simple because it is small, and it's small because it only concerns itself with communication between compositors and applications. There are already good APIs for drawing (cairo, opengl), so Wayland lets application developers use those, or whatever else crops up in the future.
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.
I want to change the resolution and I will tell you why. On 32" monitor, I can't read the text unless it runs in 720P of even 800x600.
Actually, unless you have become totally inured to blocky, pixelated displays what you really want is for everything to be rendered larger.
Fortunately, many operating systems support resolution independence, which would allow you to keep your display at its high, native resolution and still draw your widgets, text, etc at a large size. This is done by changing the DPI hint in the OS so that it knows to render things larger (or smaller).
This approach would accomplish the overall effect you desire while avoiding the blocky scaling artifacts. As a bonus, changing the DPI typically gives you the ability to change the size of things at a much finer granularity than the handful of resolutions offered by a display, so you can often make things precisely the size you desire rather than having to settle (as it appears you have been forced to do with 720p vs 800x600).
I'm uncertain which GUI you're using, but if you Google for " change dpi" you may find that it's only a few clicks to tweak it.
The "network transparency" objection is a red herring, and it's getting rather tiresome. We're not "losing" network transparency. First, we don't have network transparency now; when nearly every application depends on Xshm and direct rendering for anything resembling reasonable display performance, the fact that you can draw obsolete primitives on the server through X11 core rendering protocol requests is hardly relevant. Remote X11 apps have already been reduced to rendering their windows locally and sending uncompressed pixmaps to the X server. The most basic of all possible remoting protocols for Wayland could hardly be worse than what we already have for X11.
Second, Wayland is specifically designed to be a local API, basically a front-end for KMS, DRI2, and the input subsystem. It does not define a rendering protocol, either local or remote. A separate layer for forwarding arbitrary Wayland apps across the network has already been prototyped, and should be far more efficient than sending raw pixmaps as remote X11 do due to the use of video compression algorithms.
As if this wasn't sufficient, it is also possible to implement a remote rendering protocol (like X11 core rendering) which sends only the drawing commands over the network to be rendered locally and then displayed by Wayland. This seems to be what most of the detractors are pushing for, but in practice it's likely to require more bandwidth and have more latency issues than simply rendering the window remotely and streaming the result to the local display as compressed video.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat