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."
Hilarious excuses (Score:5, Insightful)
So, ugh... fix your desktop?
Games are the problem? (Score:2, Insightful)
Just start the goddamn games on a totally different TTY. There, problem solved!
CRT's (Score:4, Insightful)
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.
Re:CRT's (Score:5, Insightful)
Who wants any program to change the resolution of their screen?
Someone whose graphics card isn't up to the task of running a game at full native resolution? That'd be my guess anyway; I haven't willingly used a lower resolution for a while. (Some games don't support high resolutions, or don't support widescreen resolutions, and there it's "reasonable" that they change it as well. But a program like that probably wouldn't use that in the first place, so whatever.)
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.
I don't know enough about this proposal to say how it interacts with this (indeed, I'm rather disappointed by both the summary and TFA not actually, you know, saying what the problems are in the first place), but there's absolutely no reason why those goals are in conflict. In fact, the proposal specifically addresses this: "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."
Dump X (Score:5, Insightful)
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.
Re:CRT's (Score:5, Insightful)
This. I came here to say the same thing, but you already had. Every single modern graphics card is very efficient at scaling textures, and in fact, LCD scaling these days most often ends up happening on the GPU anyway. Don't touch my screen resolution. Ever. If the goal is to get better performance by rendering at a lower resolution, then render at a lower-resolution offscreen buffer and scale that up to the screen resolution.
I wish Wine had a mode that did this for Windows games that expect to change the screen resolution and don't play well with Xinerama. These days I end up using the "virtual desktop" wine mode with per-game settings and KDE's window override support to put it on the right display head and remove the borders, but it's a suboptimal manual solution. The Linux game situation is slightly better (they tend to be configurable to respect the current resolution and usually get the display head right), but still don't have scaling support.
Need inspiration? Do what video players (particularly mplayer) do. That is how fullscreen games should work.
Re:Hilarious excuses (Score:2, Insightful)
Indeed, he didn't even realize this flag wouldn't even tell the widgets the resolution changed so they would never be rearranged for starters. I doubt he has even read the proposed spec.
Re:Then will it be year of the Linux desktop? (Score:3, Insightful)
I'm pretty sure somebody did go in and fix the X11 desktop..... It was Apple w/ OSX.
Re:CRT's (Score:4, Insightful)
No, you are missing his point. There is no reason the game could not run at a lower resolution and be scaled by the WM, instead relying on the screen to do the rescaling. Only CRTs are able to do rescaling physically, LCDs end up doing it in software anyway and usually in a crappier maner than what the WM could do.
Re:Hilarious excuses (Score:5, Insightful)
The desktop doesn't know what caused the changes, so you could run into a lot of strange issues. Imagine you lay out your desktop on a 30" 2560x1440 monitor, then switch to a 1920x1080 monitor and added/removed/moved an icon. What happens when you reattach the first monitor, should everything just "snap back" to the places it had - even if you'd arranged your icons completely differently now? To me the solution outlined here seems much smarter, just let the game have it's own "screen" with its own settings, no need to even tell the other windows about it.
Re:Hilarious excuses (Score:2, Insightful)
Why do game developers always assume that my computer doesn't have any other purpose except to play their game? I've got other stuff on this computer -- stuff that is more important than the games. My computer is my alarm clock, my calendar, and a communication tool, among other things. Games had darned well better stay in the window I put them in, or I won't be playing them.
Because not everybody wants to be annoyed by the rest of the UI when playing a game. Of course, when fullscreen is available it should be an option (and not the only way to play the game), but that isn't an excuse to completely get rid of it.
Re:Dump X (Score:3, Insightful)
This is a lot of FUD.
Android. Look at the N9 with an award winning UI. It uses X and is really cool (on outdated hardware).
Network transparency is really useful. VNC/RDP sucks compared to X. And I don't see how it is
easier to use than X. Maybe there are more GUI for it that make it easier for beginners, but that
is not for any technical reasons.
I don't see what overhead X causes. I worked fine decades ago. Latency is an issue over the network,
but only because the toolkits never cared about that. It's not a problem on a LAN and can also
be solved with a (local) proxy.
My use case does not interest you? That was never the Linux philosophy. Please go back to Windows.
Legacy baggage. There is no legacy baggage. There are some APIs which are not used anymore by
modern application, but that does not hurt anybody.
Re:CRT's (Score:4, Insightful)
> This strikes me as the wrong solution to the problem: .. set its display area to that size
*sigh*
It is sad to see you unfortunately don't know what you the hell you are talking about. Let me explain:
There are these precious little things called RAM, Video Memory, Video Buffers, DMA speed, and Scaling.
Games typically use _at least_ *four* buffers:
* Frame Buffer Front (32-bit)
* Frame Buffer Back (32-bit)
* Depth Buffer (24-bit)
* Stencil Buffer (8-bit)
Why should the Window Manager force the app to *over* allocate memory say @ 1920x1080 when the user has selected 640x480??
That is, why would you have the GPU waste a total of 24 MB (8 MB FB Front + 8 MB Back + 6 MB Depth + 2 MB Stencil) compared to ONLY needing 3.6 MB (1200K + 1200K + 900K + 300K) ??
More memory allocated for the buffers means you have LESS resident textures on the GPU.
Also, By using a native (lower) resolution you force the monitor to use native *hardware* up-scaling.
> and then tell the window manager to "fullscreen"
And this is done for "free" in your fantasy world??
Why would you force the GPU to do *extra* work of texture-copy up-scaling when it doesn't need to one in the first place if you are running at a 1:1 resolution at full-screen??
> 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.
That is called "Windowed No Border Mode"
i.e. Gamers want _3_ choices
* Full-Screen (change resolution)
* Windowed (don't change resolution)
* Windowed No Border (don't change resolution)
Lastly SOME games do NOT support arbitrary resolutions. I *want* them to fill my 22" monitor at whatever resolution they DO support. The *fonts* and the rest of the UI elements are BIGGER and easier to see when running in full-screen mode.
Likewise, games that *only* run in full-screen mode are BADLY DESIGNED.
The *proper* thing to do is to give the _user_ choice: Namely the 3 I listed above.
Hope this helps explains some of the issues and WHY this solution is The Right Thing.
Re:CRT's (Score:5, Insightful)
This is a very nice example of what is wrong with Linux. Not the actual problem. The attitude towards the problem and the users who experience it.
Re:Games are the problem? (Score:4, Insightful)
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.
Re:Hilarious excuses (Score:4, Insightful)
It's not that I don't trust the LCD. It's that when you change the resolution, you tend to screw other things up as well.
I have three monitors and I game on the center one. I like to keep my email and IRC open on the other ones while I play. But if the game adjusts the resolution, the positions of the other windows move around and I can no longer see all of them. This happens in Windows if the game doesn't run at the same resolution as my center monitor.
Re:Hilarious excuses (Score:2, Insightful)
Re:Hilarious excuses (Score:5, Insightful)
Why don't games just spawn a separate X11 window server instance with a different resolution on a separate VC? Adding proper resource sharing between X11 instances seems like it would be a lot easier to do than rearchitecting all the existing apps to do the right thing during a temporary resolution change.
And there's no benefit to a full-screen app running in the same X11 instance as any other app other than making it possible to transition a window from being a normal window to a full screen window and back, and with a resolution change, that won't work very well anyway, which makes even that argument mostly moot.
Why the hell should the user suffer with resource expansion taken up by X because the damn paradigm is a big pile of hurt that goes back to the early days? I remember all the arrogance of X windows during NeXT's days and decisions with Display Postscript. It's rather clear the NeXT design has always been superior and OS X benefits from it.
Comment removed (Score:5, Insightful)
Re:Hilarious excuses (Score:5, Insightful)
I mean c'mon guys, X11 has had a good run but it should probably be in the same group as Gopher and Telnet,
Aw geez not this crap again.
Why whenever anything new comes up do a shrill group of people start shreiking omg omg x11 is so old omg omg scrap it omg omg we can't possibly make a minor tweak to fix a minor problem omg omg omg legacy omg omg omg bloat ong oh the legacy omg won't someone please THINK OF THE CHILDREN omg legacy.
Without ever stopping to *THINK*.
Just stop and think. Not about X11, but about any GUI system.
The GUI runs at the monitor's maximum resolution. Things like windows are spread out over the whole area, as perhaps are icons, widgets etc.
If the user reduces resolution, a common thing to do is to move all the windows into the new area, otherwise they may become inaccessible.
So far so good. Nothing specific about X11 in there.
Any good system will have a protocol or API for changing resolutions so 3rd parts resolution changing programs are possible to write.
So far so good.
But in some cases you don't want to rearrange the windows because the resolution change is temporary, so you need to have an extra flag which tells the system that it's temporary and not to bother.
OK, still nothing about X11 in there.
Now this is a proposal to add such a flag using a mechanism for adding such flags which has been standardised since 1985. And it will work smoothly and be completely backwards compatible.
IOW the design of X11 is ideal for this kind of change and it shows how solid the underlying design is.
Nothing breaks. No need to have a ChangeResolution and ChangeResolution2 API, no need to deprecate the old API no need to break anything.
Seriously if you scrapped the entire GUI and rendering system whenever a minor tewak is needed you'd never get anywhere.