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.
So another ten years? Seriously, this is well past due. This is the second story about someone wanting to fix the desktop in the last month or so. Hopefully if there are enough one of them might actually gain traction. Here is hoping. The X system really is a heap. As much as the purists like to bitch about it, thank goodness for nvidia when it comes to multiple monitor support. Too bad it doesn't help the gaming though.
-- I ignore anonymous replies to my comments and postings.
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.
It is a bit unusual to craft a news entry with deeply technical stuff taken from project mailing lists. What is _NET_WM_STATE_FULLSCREEN_EXCLUSIVE? A flag in some protocol?
And then make sure that different versions of it cant coexist on the same system and cant run each others code. Perhaps change all the method calls every build.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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?
When a game starts, it wants the entire desktop, it doesn't want the other desktop elements at all, no dock, no icons, interaction, etc.
Why isn't there a function to create a new virtual desktop at any resolution you want and leave the other desktop untouched? So when you switch between them it knows to switch resolutions as well. Have the resolution tag part of the desktop, so when you switch between them it knows what to switch to.
Seems like an easy fix.
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.
Get it fucking right.
Even Windows had it right by the time of XP SP1, when no game worth even pirating actually broke anything when changing resolution.
Ho comes Linux can't do that?
Yeah, I know some answers. Fuck those answers. I can install HackOSX on the same machine and it works even better even when it's not even supposed to.
That speaks of QUALITY.
Linux's state of hardware 3D support and everything that needs for it to Just Work Right fucking SUCKS, and that this article exists is a symptom of that. A band-aid on a wooden leg, a hack on top of a hack, and nothing works right anyway.
That's actually the one first reason I hate using Linux. One more datapoint in the graphs, but I know I'm not exceptional enough that I'm not in a statistically-significant place. Are YOU that arrogant? Do you deserve to?
Games shouldn't need to change resolutions in the first place. If the real unemasculated cards were sold at reasonable prices, everyone could play every current game at native resolution in the year they come out, and next ones at native res and lessened candy.
Lolno not gonna happen. It's not like I don't know it. But that's what we deserve for spending money on things. A graph card that can't display current games at native resolutions is a scam deserving of a class-action for damages beyond bankruptcy until one company (or some Open Design) gets it right.
Just so that we use tech the way it's designed to be used.
Making laws based on opinions that stem up from false informations leads to witch hunts.
I'm glad they have a fix for this issue but it isnt one exclusive to X11. Try loading a fullscreen game at an alternate resolution on a multi-screen desktop in windows and you will see the other screens get all messed up
http://interserver.net/
Switch to OS X or Windows and dump Linsux already.
Actually, I keep a Windows box to use for gaming. Linux works just fine for everything else.
(And would probably work just fine for gaming, if anyone would bother making games for it.)
Sheesh, evil *and* a jerk. -- Jade
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?
When Wayland supports !linux, it can be considered.
MidnightBSD: The BSD for Everyone
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.
>Linsux
Anyone who says this or "loonix" or a variation on this is just as bad as someone who spells Microsoft as Micro$oft and variations thereof.
--
BMO
Disclaimer: I had that habit but then I grew up.
...that make me realize I may not really belong here.
Your brain is not a computer.
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.
Full screen presentations aren't needed
There are some users here that have a pathological hatred for maximized windows -- just hearing about full screen, to them, is like getting raped by Satan.
These guys don't believe you can do anything productive without at least 7 36" monitors, with 15 or so windows arranged in each.
I have little doubt that they'd try to give a presentation on their dedicated presentation monitor (one of those old, microscopic, 21" LCDs) in a window that takes up about 25% of the display.
Be careful. They tend to bite if they're not handled a few times a week.
Required reading for internet skeptics
Use a window manager without this problem (ie. everything apart from gnome and kde) until they fix their window managers or this extension especially for them is added.
Examples instead of future hopes please.
Yes. I have about a dozen people running that with X on top (XWin32) so they can run scientific software on a cluster as well as applications that only run on MS Windows.
Why don't you guys actually find out what X is before you attempt to lecture us about alternatives?
As a Linux Dabbler / Windows Gamer it does seem kind of silly that the X crowd doesn't embrace: A) The idea of change. B) The idea of the change helping to make Linux more popular. Why can't X support a module or a plugin or behavior switch along those lines that does what some people want AND still do what it has done all along? This could be added right into the config which then makes the choice at boot up. You get your cake and eat it too...althought this Wayland project sounds interesting as well. I just keep wondering: why can't X just add this functionality ontop of its core functionality with ability to swap methods prior to it starting up the display, sort of like how I can choose to use GNOME or I can choose to use KDE prior to logging in?
X is big and bloated, in the sense that X contains a lot of dead code. This severely limits how fast the project can move, and makes it hard to attract new developers. This is more important than (I think) most people realize. Nobody wants to work on a codebase where 90% of code isn't used (but has to keep working), and the 10% people actually do still use are all implemented as extensions. That's insane.
With regards to network transparency, see this other post of mine. I will never understand why this myth is perpetuated.
With regards to backwards compatibility, you can always run an X server on top of Wayland. It's not even particularly inefficient to do so, because Wayland is such a thin layer.
With regards to not gaining any features, removing X takes away one layer between applications and the screen. This matters, even today. If you're running a video game on a compositing window manager, that game's frame now has one less layer to pass through before it hits the screen. Using Wayland simplifies the Linux display process.
Basically, using Wayland will not prevent you from doing what you've always been doing, nor will it encourage developers to write programs that prevent you from doing what you're doing. What it will do is make it easier for those developers to make new things and be happy about it.
LCDs have one resolution, but the scaler between the video cable and the LCD has several resolutions. I'll grant that cheap monitors are more likely to have cheap looking scalers.
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.
You should NEVER have to upscale images if you are doing things right.
Doing things right in real time is often cost prohibitive, as it'd need a newer, much more powerful GPU that the user may not already own. This is why a lot of Xbox 360 games run in 576p and upscale to 720p or 1080p as the system settings request.
Unless your game uses OpenGL and you have a fully accelerated driver (read: the proprietary Catalyst or nVidia blob), it will not be able to scale fast enough. Most games use SDL and main memory surfaces that are then blitted to the screen.
I thought "most games" made for PC and sold in 2012 either were 3D (and relied on OpenGL or DirectX) or were designed for Flash or HTML5. I thought user expectations were beyond the point where commercial games could still use SDL software rendering. Or by "most games" are you including hobbyist productions?
"Standard resolution" arcade games have 240p graphics that can be scaled up by a factor of four to look good on a 1080p monitor.
Do you mean DisplayPostScript from NeXT? Apple never used X11 for their primary display [on mainstream products]
The implication is that NeXT fixed X11 by replacing it with DPS, and Apple continued this by basing Quartz on the PDF data model.
Linux already runs on shipping laptops, albeit not necessarily GNU/Linux or X11/Linux. There are Android tablets with a clamshell keyboard (e.g. ASUS Transformer series), there are Android netbooks, and there are Chromebooks.
There are two exceptions.
"Micro$oft" is immature, but "M$" alludes to Microsoft's origins as a BASIC interpreter publisher and distinguishes it from the other MS. As the old joke goes, the difference between M$ and MS is that one is a debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task, and the other is a medical condition.
"Loonix" and "Linsux" are immature, but "LUnix" is an operating system for Commodore 64/128.
Don't you mean a Ctrl-Alt-F7 away? At least, that how I change between x-server windows on Debian...
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.
Actually, I think the major defect in X11 is the focus model and things like grabs that are a huge pain in the ass to work with, and make little sense in the modern world (which window gets an input event for a multi-touch gesture for example? Actually, there's an X extension for that now...). The protocol itself is pretty clean and not particularly inefficient. The issue with compositing is that it might involve a few extra context switches, triggering things like TLB flushes... of course, the last couple of generations of x86-64 chips have tagged TLBs (albeit only designed for virtualization) so in theory even that expense could be mitigated. And then the compositor is probably just bypassing most of X anyway nowadays, so someone got the bright idea to get rid of X. I suspect a compositor-specific protocol for X might solve a lot of the problems (because, well, window managers performing compositing instead of having external compositors hints at a flaw in the way compositing fits in the X architecture).
There are a few things that need sorting out. The keyboard handling code is... umm... "mysterious to mortals", and the whole business with visuals and colormaps has been outdated for well over a decade. But the big thing now is probably that window positions and sizes are described by a short; it's now becoming generally practical (if still a little expensive) to assemble a display that is larger than 32k pixels in some dimension, so now is the time to update the protocol to allow larger values for coordinates. Yes, it sounds trivial, but it permeates through the whole protocol itself, so fixing it will be disruptive and incompatible. But it needs doing.
The compositing problem is mostly due to the lack of a good way to do alpha blending of an image at speed. Some apps need closer integration, but they're a minority. (And for goodness' sake, font rendering belongs server side. If only I could be certain that it didn't have crippling bugs when rendering at angles other than the four cardinal directions...)
"Little does he know, but there is no 'I' in 'Idiot'!"
I am TheRaven on Soylent News
It seems that you could benefit of "Cognitive Retention Therapy, a dementia treatment". ;)
Things that nobody actually uses anymore.
Liar.
I, and many others still use xterm (among other things), so you're making a false claim to support your point. That's called lying. Stop doing it.
The only thing X really does now is act as a proxy between window managers and applications.
Um yeah? And input device handling. The windowing system, especially the reparenting aspect is one of the major parts and it is why X11 is so much of a better GUI than any other system.
But X still has support for all the old stuff, and so it's huge and lumbering.
It worked on a Sun 3/60. There is no way it could be bloated by modern standards.
And now for some fud:
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
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.
Those can't both be true. And the X11 API isn't really that complicated. It's quite simple if you understand it.
SJW n. One who posts facts.
What about MICROS~1?
SJW n. One who posts facts.
That one is a valid criticism.
Long filename support on FAT file systems was a joke. I had one FAT filesystem literally blow up on me because Windows forgot how to string together the 8.3 filename kludge to make the long filenames.
File.001
File.002
File.003
Dir.001
Dir.002
Dir.003
And so on...
Try finding your data after this happens.
--
BMO
X needs to be replaced with something the way Linux replaced Unix. X is full of old solutions to old problems, loads of features and methods that nobody (or hardly anybody) uses, is far too complex. It's stuck with an architecture and components slavishly oriented to the client/server pattern rather than distributed peers and meshes of servers for shared AV on multiple devices of very different power that people actually use.Android ditched X. We should replace it even on Linux with Skia, adding a multi-window extension and a widget that allows both X and Skia to display simultaneously. Until nobody uses X anymore.
Make these windows into objects that can be easily collected into groups, pipe data among them, flick them among networked machines (including public screens). A new infrastructure for the new, ubiquitous AV presentation we're running on mobile parallel supercomputers.
--
make install -not war
I, and many others still use xterm (among other things), so you're making a false claim to support your point. That's called lying. Stop doing it.
I meant developers no longer use it. If you know of a project started in the last 5 years that decided to use these features of X, and not use GTK or Qt or some other toolkit (which themselves don't use these features), I would like to hear about it because I genuinely don't know of any.
You will still be able to run xterm under a Wayland compositor, don't worry about that.
Um yeah? And input device handling.
Input is a bit of a sticky wicket, but that's not exactly an insurmountable problem. Why should input devices be tied in with the display server (and in X's case, font rendering, vector graphics, ...)? I honestly feel like they're better off in a completely separate system that can be re-used elsewhere without bringing in all of X. Isn't that the unix philosophy?
It worked on a Sun 3/60. There is no way it could be bloated by modern standards.
See this cousin comment. All this old stuff it needs to support makes the X project huge and lumbering. Dead code stifles innovation because it scares off developers.
Those can't both be true. And the X11 API isn't really that complicated. It's quite simple if you understand it.
Yes, that is often the case with things you understand. I have tried and failed many times to understand X, I really have. I understood what the Wayland protocol does in about a day. As for the first part, code length is not the same as understandability, or even simplicity. You can have 1 kilobyte of brainfuck and 2 kilobytes of python, and the python is still simpler. Wayland provides bitmaps to compositors, and delivers input events from compositors to windows, and at no point do you need to probe some server for COMPOSITE support, or manage the child X window's global coordinates to correspond to where you're drawing them on screen, or muck around with who gets control of the root window. You get bitmaps, you draw them. You get input events, you distribute them however you please. It's really straightforward.
You list statements I made and rebut them as if every single sentence in that post is a reason why X is bad. Sometimes the sentences are used to introduce a reason why X is bad, or provide a comparison.
X is old, which explains why it has a lot of unused code. Wayland is an example of how you can replace X with something conceptually simpler, with other benefits. Dead code increases the barrier to entry for new developers, and causes the X project itself to be organizationally huge and lumbering.
Is Vista our gold standard for how good a composited desktop can be? If we can do better than Compiz, why shouldn't we?
Writing a compositor for X is harder because X has a lot of fiddly bits that compositor authors really shouldn't have to worry about, like global window positions and probing for COMPOSITE support. The Wayland protocol delivers bitmaps to compositors, and input events from compositors to client windows. That's it.
That's great and all, but why do we have to lose network transparency? Nothing you said requires losing network transparency, and nothing you said is worth trading network transparency for.
Give me Classic Slashdot or give me death!
If you know of a project started in the last 5 years
Woah there cowboy! Linux is what, 20 years old? There's an awful lot of software out there which is older than 5 years but is not going to disappear for the forseeable future.
I'm sure you could find some, especially window managers if you looked around though.
Input is a bit of a sticky wicket, but that's not exactly an insurmountable problem. Why should input devices be tied in with the display server (and in X's case, font rendering, vector graphics, ...)? I honestly feel like they're better off in a completely separate system that can be re-used elsewhere without bringing in all of X. Isn't that the unix philosophy?
Well, for input devices you need to control which application gets the inpus, so you need the windowing stuff. And you need good ways for the applications to communicate (copy/paste) and so on and so forth. The rendering is a small part of that.
See this cousin comment. All this old stuff it needs to support makes the X project huge and lumbering. Dead code stifles innovation because it scares off developers.
I contest that. The drawing code is from the Sun 3/60 days. If it existed then it is tiny by modern standards. The Linux kernel is vast and most code for most people is effectively dead code since there is tons driver etc code.
Wayland provides bitmaps to compositors, and delivers input events from compositors to windows, and at no point do you need to probe some server for COMPOSITE support, or manage the child X window's global coordinates to correspond to where you're drawing them on screen, or muck around with who gets control of the root window. You get bitmaps, you draw them. You get input events, you distribute them however you please. It's really straightforward. ...and that hides half the complexity under the carpet because you need more than just that for a system to work.
Why are you managing a child's global coordinates? That's a very odd thing to be doing. Why are you dicking with the root window? That's a good way to annoy users. And how on earth is handling X events anything other than "you get events and distribute them however you please"?
SJW n. One who posts facts.
X is big and bloated,
No, it isn't,
in the sense that X contains a lot of dead code.
no it doesn't. The amount of code is quite small.
This severely limits how fast the project can move, and makes it hard to attract new developers. This is more important than (I think) most people realize. Nobody wants to work on a codebase where 90% of code isn't used (but has to keep working), and the 10% people actually do still use are all implemented as extensions. That's insane.
er huh? Have you looked at Linux? Much of the functionality is in modules. Huge amounts of code are dead to almost all users because they will never have an S390 or Sparc box to run it on. That doesn't seem to hinder Linux, and yet it still supports binary code from 20 years ago.
With regards to backwards compatibility, you can always run an X server on top of Wayland. It's not even particularly inefficient to do so, because Wayland is such a thin layer.
Noone ever said you couldn't.
But the X clients won't integrate well with the native ones and the native ones won't have remoting.
With regards to not gaining any features, removing X takes away one layer between applications and the screen. /em.
Except that now DRI works, there is no layer in the way.
SJW n. One who posts facts.
X had half of a solution to this decades ago. It's called the Viewport. Remember back when you scrolled around your 1600x1280 desktop on your 800x600 monitor? Rather than simply changing the resolution of the display and saying fuck everything else that's running, the operation should be to set the viewport to the current resolution, then lock it to prevent it from scrolling away from the origin. Then you can decrease the display resolution without fucking up the desktop.
The other half, if you want to have an 800x600 desktop and game at 3200x5000 or something ridiculous, that's left as an exercise to the reader.
If I have been able to see further than others, it is because I bought a pair of binoculars.
The RAM hit isn't too bad, given that GPUs these days ship with 1GB or more
Sure, for desktops. What about laptops?
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
Rather than try to cram modern features into the creaky old pile of bloat that is X11, that ancient technology needs to be relegated to server-only usage, and replaced with something modern that can talk more closely to the hardware without going through half a dozen abstraction layers.
Yes, network transparency, I know. 99% of users don't give a shit, and just want things to display and animate smoothly – which X11 fails miserably at. Keep that on servers, where it matters, and drop it on desktops, where it doesn't. There is a reason why, when Google borrowed parts of Linux to make Android, they dropped the X11 layer without a second thought.
The desktop market is probably the last thing that Linux should be trying to succeed in.
Linux isn't really an OS. It's more like a box of parts for an OS. Some people have slick packages that have been put together that work pretty well, but you're going to get the most out of it if you have an interest in getting under the hood -- starting with installing it. For most people having to install an OS is a non-starter.
For "serious" computing this can be inescapable. It's also useful to embedded developers.
So tell me what's so compelling about the desktop market anyway? Users will hammer the developers ("Isn't it ready for prime time?") if the product isn't perfect in every way, and generally aren't interested in paying for support or even the OS itself. If you've read The Old New Thing, you may recall that they considered each product-support call to cost about the same as the sale price of the software. When people (mostly anti-Linux commentators these days) talk about how Linux should be a contender in the desktop market, I can only think of millions of complaints as vacuous as yours, or worse.
I believe that mass-market appeal and the ability to tinker with system internals are diametrically opposed. Android and iOS are the success stories of recent OS history: do note that these are single-user systems with extremely limited system configuration options. I haven't played much with Win8, but it seems like they're running in this direction as fast as they can.
The refrain seems to be "Linux has technical problem X which means it's not suitable for the desktop!" I would like to hear a compelling argument that [a] the technical perfection of an OS has anything to do with market share, and [b] that the desktop market is worth participating in.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
The "network transparency" objection is a red herring, and it's getting rather tiresome.
Guarantee that every Wayland app will work at least as well across the network as X11 apps do today and we'll shut the hell up.
First, we don't have network transparency now
Funny, I use it every day. NX is a big help, and I agree that X's network transparency isn't ideal. But that's no reason to toss the baby out with the bathwater.
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.
Then how can you guarantee that every Wayland app will be compatible with whatever remote rendering protocol becomes standard, if any?
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.
Do you have data to back that up?
I would love to be convinced that Wayland will provide superior network transparency to X11. But it doesn't seem like the Wayland developers take network transparency seriously.
Give me Classic Slashdot or give me death!
Actually, I'm not sure it does - how do you scale mouse input if you're just scaling the window to fill the display rather than changing the display resolution, for instance?
Guarantee that every Wayland app will work at least as well across the network as X11 apps do today and we'll shut the hell up.
What do you want as a guarantee? As someone which is familiar with Wayland's design, though not one of the developers, I have no doubt that any non-trivial remote Gtk or Qt-based application will work at least as well with Wayland on the display side as it currently works with X11. It's basically the same process as X11 apps already use in practice, but with fewer round trips and better compression algorithms.
First, we don't have network transparency now
Funny, I use it every day. NX is a big help, and I agree that X's network transparency isn't ideal. But that's no reason to toss the baby out with the bathwater.
You're missing the point. X works over a network, obviously, but it isn't transparent. Modern toolkits assume that it is cheap to render into pixmaps with DRI and send them (via shared memory) to the server for compositing. This is true in the local case, but not when the client and server are on different systems. When running an X11 app remotely, you don't have direct rendering and pixmaps must be serialized and transferred over the network. The protocol doesn't even allow for compression. NX can cut down on the resource requirements, but once again, that's something you have to manage yourself, on top of the X11 protocol; it isn't transparent.
Then how can you guarantee that every Wayland app will be compatible with whatever remote rendering protocol becomes standard, if any?
The current plan for arbitrary Wayland apps is to have two Wayland compositors, one on the client and one on the server. The app supplies frames to the client-side compositor, which compresses them and sends the compressed video to the server. A Wayland app on server decompresses the video and sends it to the server-size Wayland instance, which composites it onto the display. Any app which supports the local Wayland protocol can be remoted in this manner. In this scenario the app does not require any remote rendering protocol; all the rendering is local, and can take advantage of the client's GPU via DRI2.
Any actual remote rendering protocol, like X11, would obviously require support from the app itself, which in practice means the major toolkits (Gtk and Qt).
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.
Do you have data to back that up?
I don't have benchmarks, but it's obvious if you think about it. Rendering a window with OpenGL, as most modern toolkits do, requires textures, depth buffers, mask layers, etc., which may even be higher resolution and/or higher bit-depth than the window itself. Altogether they represent much more data than the final window. A PCIe connection with gigabits per second of bandwidth is required to process them efficiently. Even regarding basic geometry, I understand that current rendering techniques can require more triangles than there are pixels in the final framebuffer. Sending just the final result—the changes in the final result, after motion estimation and video compression—is bound to require less bandwidth than the raw data required to render the same image.
As for latency, rendering on the server requires copious synchronization and round-trips where a simple video stream needs only one-way communication for display, and perhaps some delay feedback if there is sound involved.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
I'm really not convinced of the utility of Colormaps and indexed visuals in the modern world... my phones going back about eight years now have supported at lesat 15-bit color, and at that point you stop using colormaps. But maybe not. You certainly shouldn't have to agonize over whether your application will work on a very small fraction of displays, and it's madness that (unless you use a toolkit, but you're mad if you're not using a toolkit nowadays) your application will just fail to work if you don't handle ColorMaps.
The input mechanism is certainly powerful, but it's wonky and not particularly clean. The way input events make it to windows is particularly ugly... you do not want to be the one writing code to deal with it.
I like X11 (I mean, it gets the job done, and I probably use the network transparancy features to my home server a couple times a month), but the protocol events really need revisiting. Things like colormaps and core text handling could be moved to extensions, all of the universally implemented extension should be made part of the protocol. Wayland is the first attempt at that. Maybe it'll fail, maybe it'll succeed. But there's no reason to think we can't do better than X11.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
... my delicate compiz configuration or I will get mad and whine.
now we need to go OSS in diesel cars
the low end game of WOW with all the special effects on in a populated area will easilly use all of that 1GB and probably can now even use at least 2GB. I know 2 expansions ago people were running into the 4GB per 32 bit app memory limit.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
XInput2 provides the ability for the window manager to perform arbitrary coordinate transforms on user input, for precisely this reason (the use case was screen magnifiers, wanting to make a window larger and still have input work correctly).
I am TheRaven on Soylent News