Slashdot Mirror
Clearing Up Wayland FUD, Misconceptions
An anonymous reader writes "In clearing up common misconceptions about Wayland (e.g. it breaking compatibility with the Linux desktop and it not supporting remote desktops like X), Eric Griffith (a Linux developer) and Daniel Stone (a veteran X.Org developer) have written The Wayland Situation in which they clearly explain the facts about the shortcomings of X, the corrections made by Wayland, and the advantages to this alternative to Canonical's in-development Mir."
Why not fix X?
The simplest and most obvious answer: it's easier and faster to just not bother and start from scratch.
Yes, I did it on my Raspberry Pi using the implementation of Weston that they discussed.
Making your ignorance plain is quite helpful to others in knowing to avoid you.
Yes, here we are, still with X. That doesn't make X good and it doesn't mean Wayland has made no progress. In fact the biggest driver of the Wayland transition is the wide availability of graphics accelerators that we didn't have back in 1997.
I won't really shed a tear when X is reduced to a library that sits on top of Wayland. I will enjoy improved performance and compositing that Wayland brings.
SurfaceFlinger. Of course, no one has actually adopted it. It's just prevalent because of Android.
As an Ubuntu user, and somewhat of a fan, I was hoping to see the discussion on Mir vs Wayland. But where is it? The only mentions of Mir I see are in the Phoronix summary, and the slashdot summary. Only the slashdot summary makes it seem like Mir is talked about.
I don't have the knowledge to decide whether Mir is a good or bad way to do things (and certainly the "I hate anything that caninical does" sentiment of slashdot isn't informative either), so it would have been nice to here about Mir from someone who knows what they are talking about.
You're using a modern toolkit, one that scales depending on the DPI reported by the display server, right? Wayland is entirely correct to be aware of pixels, it's your toolkit that should provide and operate with geometry which it translates into a rendered output that is placed into the buffer that Wayland manages.
If the toolkit is any good, the application won't be aware of it.
A bit of reading would suggest that scaling would be employed on a per-monitor basis, I don't have time to read in depth to figure out what the logic is behind it.
Because it wasn't invented here.
I've been a supporter of X11 for some time, but only as a user. I know how to use it, and it's more or less the same as it was ages ago. That heritage will be difficult to break, especially the network transparency it has (which some claim it doesn't really have if you're using DRI2 etc, but you don't have to use those).
However, I've read enough of these rants from both camps to start looking at this differently.
Back when X.org started, I was surprised that it became the norm so quickly. It did so because it worked, could be dropped in, and had some improvements.
AFAICT, Wayland isn't done yet. As a user, we're judging too early. Right now, they really only need to be convincing toolkit, driver, and X developers to get that development on board.
Once Wayland is drop-in usable with all common apps, it won't matter to the user except for how it performs in their various tasks. Once it gets to the point that, for example, a Ubuntu user could "sudo apt-get install wayland-somethingorother && dpkg-reconfigure somethingorother" to try it out, then we'll see if it lives up to the hype.
There are plenty of things it's saying it'll do that sound good. The parts that worry me from my naive perspective will be answered when it's usable, such as:
* apps having to do all the rendering. What about apps that don't do this now? Are we really going to force them through X, or will there be some middleware they can use, etc?
* the mini x server solution... there was a problem noted due to the change in coordinate systems. How will that be solved? What other problems may we run into? etc.
* the network transparency question. They haven't completed this yet. They may not ever do it (might be 3rd party). There's already some other attempts at this that show something can be done with it, but it's just not finalized yet. We just have to wait and see.
* remoting apps, and how that will relate to interoperability. Sounds like I'll be able to pull an X app up on my local Wayland desktop and have it displayed using the built in mini x server (maybe). What about the reverse? How do you export a Wayland app to a client that is only running X.org?
Seems to me that those are all solvable. Will the solutions pan out? well.. seems like those are still a work in (early) progress.
It's far enough now that there's no point in asking, "why do this?" or "why not fix X?" etc.. they're doing it, period. I'm done reading these things now, cause it's just a matter of "will it succeed?" (and it won't unless all the stuff people have been bitching about are solved, so who cares for now?)
Not much, except that all modern Linux software already does this because X is utterly obsolete as a drawing toolkit. Wayland is pretty much the answer to "If we assume the toolkits look at X like a dumb framebuffer, how much of X can we throw away? And fix some deep design issues in a process." That's it, nothing more. It's not an either-or, nothing prevents you from building an overlay that talks geometry to clients and pixels to Wayland, if you can get any traction for that. But then you're probably going to compete with similar functionality in GTK+, Qt, wxWidgets, OpenGL, OpenGL ES, SDL and so on that all like to render pixels. Unless you can force developers to use one library like Windows and OS X can you'll be just another library clamoring for support. But they all need something to render on and that's Wayland.
Live today, because you never know what tomorrow brings
The only argument I've seen is the lack of network transparency, often poorly worded with no actual technical argument behind it.
Sounds like you aren't interested in hearing the arguments, but I'll try. Practically all X11 apps can run remotely - the ones that can't are likely to be inherently limited, like video players or 3d first person shooters that have bandwidth and latency requirements that are transport constrained. Outside of those types and pathological configurations, remote X11 just works for all apps.
V) "Wayland can't do remoting." Wrong. Wayland should be BETTER than X at remoting, partially do its asynchronous-by-design nature. Wayland remoting will probably look a like a higher-performance version of VNC, a prototype already exists. And this is without us even giving it serious thought about how to make it better. We could probably do better if we tried.
"We haven't given it serious thought" is a particularly bad approach to convince people to quit bitching. Show us a well thought out plan to support per window/application remoting, not vnc-style desktop remoting and that will shut up practically everyone. Act like you really don't give a shit and nobody will have any confidence that it ever will "better than X."
When information is power, privacy is freedom.
A subset of people like me use their desktop as primarily a terminal to connect to more powerful servers. I want to know if Wayland will let me "ssh me@oldserver-running-X xterm" and then use the remote xterm to start a bunch of programs that open their own windows. I don't want to know how it does it, only if it will work.
If the Wayland developers don't want to commit to making something like this work, that's fine. It just means Wayland isn't designed for me. If they *are* going to make it work, I would feel more comfortable is they would come and say for certain that they are committed to supplying this functionality.
This same point comes up again and again. I think that the developers at some level don't understand the question, because there never seems to be an answer that is straightforward and pitched at the level of the user. (Not that anyone *owes* me an answer. I am just making a request.)
They have barely given it second thought because they've established that it can be done in principle, and it isn't the stuff they're working on (which is getting the actual display working cleanly and efficiently). They can worry about it when they've gotten the fundamentals pinned down. Do you really want excellent networking for a display system that doesn't display well, or is horribly slow? First things first and all that. As long as nothing they do makes it infeasible, or overly complicated there's no point in worrying about it till the very core functionality is working as they wish.
Craft Beer Programming T-shirts