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."
First, SDL isn't an alternative display technology, it's a library which works on top of X (and Weston). Second, I am running KDE on Weston right now and it is working pretty well. It's not ready to replace X for most users yet, but it's stable and getting close to ready for mass consumption.
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.
I have never seen a good argument for this.
Read the article, then.
Well he gave an answer in the article: if you move to "fix X", you end up making X12. And when you do that, all the stakeholders in X come out of the woodwork and insist on preserving all the legacy parts of the system that, frankly, don't belong.
The way things have unfolded, X11 will become a library on top of Wayland. And that's perfectly fine.
Each application does its own rendering? 31-bit pixel counter?
This sounds like it's all pixels, like X, rather than geometry, like NeWS or display postscript.
So if I have monitors with high resolution I still have to tell all the applications to change their size, individually, or use a microscope to read the text, right?
If I stretch a window (intending to scale it, rather than just see more of what it shows) it has to go back to the application for re-rendering, right?
And if I have adjacent monitors with different resolutions they won't match up. Heaven help me if I lay a window across the boundary between two, the T between 3, or the + between four. Right?
Or have I missed something?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Why not fix X?
The simplest and most obvious answer: it's easier and faster to just not bother and start from scratch.
In addition, X was originally written when networks and client systems were slow(er). Many of original design decisions are no longer appropriate with respect to the X server code complexity and maintenance requirements. A long (long) time ago, I wrote a program (called CXC - Concurrent X Control) to manage the low-level X protocol (think everything in the X11 Volume 0 book) and support transparent X traffic interception, blocking, redirection and insertion for a CBT application (called CAST) and, if I remember correctly, I remember wanting to off myself (or at least start drinking heavily) after trying to make sense of it all. Just my $.02.
It must have been something you assimilated. . . .
Why not fix X?
The article answers that question on the very first page. (Scroll down to the bottom.)
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?)
* 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?
Apps can use the Cairo library to render. That is what most of them are doing now anyway, since that is the only practical way to get antialiased lines and scalable images on X.
* 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 problem was not really described correctly. The Wayland developers have this idea that applications should not know what their window positions are (I don't agree with this btw). X applications when they do the X api to figure out the window position are told it is at 0,0. On X an application wanting to make a popup menu not go off the screen, compared it's window position to the screen position, and thus knew where to place the menu (on Wayland the client says what position it wants the menu in (relative to it's window) and is told how it will be clipped, so the client can try another position). This means some errors with the popup of menus in X applications.
I was under the impression that they "fixed" this by allowing the X emulation to get at the secret information about where the window is. I complained on the mailing list that this means that X clients have a special privledge and they really should allow regular clients to get this secret info, but was ignored.
* 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?
It looks like they are planning to use per-window RDP. This makes sense because the api and remote clients already exist, and you would run an X RDP client to display the Wayland windows.
It was invented here. A large share of the Wayland developers are ex-X11-developers. They know X11 from the inside.
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.
I've seen demos of Wayland that had per window remoting, including moving and cloning per window across different diplays. Wouldn't it be nice if xmove still actually worked for most applications? If you could just move your application across Xservers as you wished and didn't have to worry about temporary network outages killing you application? Well apparently Wayland can do that. So it seems to me that Wayland has potentially more to offer in terms of network transparency than X. It isn't done yet, so let's wait and see. Everything I've seen looks very promising.
Craft Beer Programming T-shirts
I'm not worried about it, or complaining about the difficulty of installing it, as I'm aware that I'm currently not the target audience (although the Apache comment was hyperbole). Just wondering if I had missed anything, or if the current situation really was "build xwayland or gtfo." It sounds like the answer is, "build xwayland or gtfo."
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
A major problem is not whether Wayland supports old X applications but instead that new Wayland applications are not going to be network transparent like X ones. That limits them to one to one network connection via third party hacks like VNC instead of the many to one and one to many options that X gives you.
It's a backwards step to the non-networked, single user, single platform mindset. That's not even what people are looking for in gaming consoles any more.
The ramifications are that new wayland only apps are only going to be useful if you are sitting right in front of the computer you want to use - an insane restriction now that phones and tablets with wifi are at the point where they can be effective terminals to a desktop computer doing the heavy lifting (video, graphics, voice recognition whatever).
The single platform restriction also sucks - linux only due to a deliberate design choice.
Sorry kids, a dumb framebuffer is not a new idea and a trip back to the 1970s has got to be justified with new features and good benchmarks before it can be proclaimed as better. For now there's only stupid block diagrams that pretend any internal complexity and internal communication is faster than something with more blocks in a diagram even if they are a lot simpler - it's just smoke and mirrors without benchmarks.
Even calling it Metro for linux at this point would be giving it too much credit - save the hype for when it delivers on a performance promise and has more features than SVGAlib from 1995.
There was a time when displays did everything by passing around rendering primitives -- lines, rectangles, black and white bitmap pattern tiles. At that time it made a lot of sense to integrate network at the low level because you had to figure out how to send and decode all those drawing primitives over the wire.
Display technology moved on. Displays became rich and complex and colourful, and different applications had very different needs and took on more and more of the rendering task themselves and simply pushed bitmap buffers to the display system. Now the task of the display system was to mediate and manage and request complex bitmap buffers from the various clients.
At this point remote display was a matter of having the client send (potentially compressed) bitmap buffers -- let the clients do their own rendering. This is how most remote display systems written in the last 15 years do it. Indeed, that is how X does it these days for most applications: the applications do their own rendering via GTK or QT and Cairo and X pushes the pixmaps down the wire.
If all you are doing is throwing around bitmap buffers, and the display software is simply mediating and displaying those, then remote display doesn't need a whole lot of thought at the display level -- all it has to do is mediate and display the bitmaps it gets from clients. Now, providing a remoting system to let remote clients get their bitmap buffers to the display when requested ... well that's still a thing that needs to be done, but it the base display software doesn't have to care too much about how that gets done.
Think of it as teasing out the layers in the software. The base layer is pushing pixels to the screen (no matter where the data for those pixels came from, remote or local). That's one job: pixels on screen. Focus on that and do it well. Another job is getting the data that the base layer is going to display to it, and you can worry about remote/local differences in that layer.
Craft Beer Programming T-shirts