Every time there is an article about Wayland you can see that there a lots of uneducated comments about the “fact” that Wayland does not support network trancparency and because of that it is completely wrong to go for network trancparency. These discussions contain a lot of myths and even FUD and I consider it important to share my thoughts about these concerns as I am belonging to those who actively work to bring the benefits of Wayland to the KDE Plasma Workspaces.
Wayland Could Use Network Transparency
Nothing in the Wayland protocol forbidds network transparency. It is not yet implemented, but it is possible to implement it. Wayland uses a Unix Socket for communication but I think it would be rather trivial to either add network transport to the Wayland protocol or to just forward the buffer in the compositor. Stating that Wayland does not support Network Transparency in general is just wrong. It’s not yet implemented but many things are not yet implemented. Obviously it’s true that the Wayland protocol does not support the X11 Network Transparency as it’s not X11 (and that is a good thing). Obviously even a direct X11 successor (let’s name it X12) would also not support the X11 Network Transparency.
X11 Network Transparency is not Suited for Modern Applications
The idea behind the network transparency is to send drawing commands over the wire (useful idee for the requirements of 30 years ago). Nowadays modern applications do not use X11 any more for rendering. They use technologies like Cairo, Clutter, QPainter (Raster) or OpenGL directly. Without using X11 for rendering you end in streaming pixels over the wire. And there are clearly better technologies to do that than X11. Face it: network transparency is going to break very soon even without Wayland. I want to see the Qt 5 used over the wire.
Modern Applications require DBus
Yes DBus is not network transparent and yes most modern application use it, for things like StatusNotifier (this one has fallback to Xembed) or moving the menus somewhere else. Now without network transparency these things are just shown on the wrong system or not at all. Damn stupid devs not thinking about network transparency… So face it: no modern app can be used without DBus which breaks implicitly also the X11 Network Transparency.
Wayland targets Mobile Devices
Desktop will continue to Support X11
We will only switch to Wayland as our primary windowing system if we can continue to support legacy X11 applications, because we don’t want to break the desktop. This means you can still run your legacy X11 windows over network even under Wayland and also X11 applications on the Wayland system can still be forwarded to a remote system. So I hear you already complaining about the Wayland windows not being able to be forwarded. Well if the toolkit (like Qt) supports multiple backends there is no reason why you should not use the X11 backend to forward the window. Apart from that: remember, it would not be working at the time when we switch to Wayland even under X11 (see above).
Network Transparency Does Not Belong Into The Windowing System
Adding Network Transparency in the Windowing System is the wrong layer. The windowing system only receives the pixels and that can never be performant. Network Transparency needs to be added to the layer which does the rendering. That used to work with X11 as X11 also did the rendering, but this is not true any more. We need support for Network Transparency in the toolkit. Just imagine the possibilites: remote applications picking up your local font settings, color themes, icon themes… That’s what needs to be done!
But Distros will remove X11 support in $X Years
=-=-=-=-=
Powered by Blogilo
i cant understand the fear, that distros will remove x11 in a few years ether
think of rhel
they always support “old” versions of software a looong time even if they have to spent time writing patches themselves
btw: your blog-posts are always the highlights on planetkde and way more entertaining than thing like waisting time with watching tv 🙂
“As long as there is a demand for legacy support distros will still support it.”
The concern isn’t that distros will stop supporting X. The concern is that developers will stop supporting X in favour of something that makes creating pretty things easier but ultimately removes useful functionality. Now we could get that functionality and more in wayland, but it needs to be thought about now before we invest too much in ideas that are counter to good network transparency.
For the most part X11 isn’t sending pixel data either, it’s sending the exact same draw calls that it gets. That’s why you can’t use opengl X11 forwarding on an xserver without any opengl extensions. When gnome draws something on screen it draws it using X11 (or one of its extensions) calls.
“We need support for Network Transparency in the toolkit”
I agree that this is the way to go, but it relies on individual toolkits to all provide network transparency. Getting all the toolkit makers to agree is difficult. I propose a simpler solutions. A simplified set of openGL calls that can run on any machine, even ones without a graphics card. Something that can be run on cpu. Make that simplified opengl your network transparent protocol and set up a network transparency foundation to ensure that everything works with your simplified spec. This way you can still easily implement things like web based viewers and viewers on devices that aren’t posix compliant without needing to port a bunch of toolkits and libraries.
One of the points of wayland was to make it easier to port the server to other devices and frameworks, if you want wayland to have network transparency as a feature and you’re just using toolkit based network transparency, you’re requiring all the libraries and toolkits to also be ported over. You could go just pixel based but they’re slow.
But that’s no longer true. Applications do not use X11 to render, they use CPU methods (e.g. raster engine in Qt) to render in RAM and just transfer the rendered image to the X server, so it is pixel data. Same for OpenGL if you require direct rendering (which Qt 5 will do).
Good to know, I am curios why openGL apps won’t work without that extension being on the local machine though…
Thanks for blogging this. It’s eased my mind a bit about the move to Wayland. I do have a few questions, though:
1. Games. Will games written in the days of X work in Wayland? I’m quite fond of the Enemy Territory series, for example.
2. I get that, for the sake of efficiency, having network transparency in the part of the stack that draws the pixels is worse than having it in the part that actually handles the rendering of the window (the toolkit), but this raises a concern. Are there plans to collaborate with the Gnome developers to ensure that a common protocol is used between Qt and GTK, or is there a risk that I will need GTK installed on the computer even if I don’t have any GTK applications installed locally in order to use remote GTK applications?
Other than that, the idea of not only having network transparency after the move to Wayland, but also having it perform better and integrate better with the local system, is actually pretty good.
Just to make it clear: that is my idea how to solve the problem. I do not know if there are any plans in Qt or GTK land to implement it, but at least GTK has the broadway project to get applications into the browser
You are right. Modern Desktops get more and more useless. Using KDE on a X11 thin client is a nightmare. Most applications are still quite usable but the DBUS thing starts to be really annoying. For example if I ssh to another machine and just start kate to edit a file it fails and tells me that I have to start a dbus session. WTF? It is really sad that KDE looses more and more of its power
The way I see this use case it is more a limitation of SSH than any other involved component.
When you forward X11 over SSH you are not actually using X11’s network tranparency, both application as well as X-server side are using the local unix socket transport.
SSH could simply deploy the same mechanism to forward D-Bus but it seems to even lack options to do that manually
I do not use ssh’s X11 forwarding feature. I explicitly set the DISPLAY to my X-server directly after logging in. ssh’s X11 forwarding causes too much trouble with some applications.
What confused me for a long time is the “D-Bus is not network transparent” issue. This is only an issue if you run applications from different hosts on the same display. This an entirely different issue to running the display on a different host (i.e. a thin display) which is the most likely need for network transparency.
remember that thin displays are only one usecase for network transparency. And personally I doubt that everyone complaining about network transparency in Wayland is using thin displays.
Who needs network transparency? Desktop users?
Funny, you’re speaking of FUD against Wayland, then you say things such as D-Bus is not network transparent so it doesn’t matter that Wayland isn’t by default network transparent.
Imitating stupid design decisions is not how one make great software IMHO.
I think the DBus design decisions are good and correct.
> I think the DBus design decisions are good and correct.
Of course you would!
Well for what it worths Al Viro calls D-bus “spectaculary ugly” http://lwn.net/Articles/453529/
I don’t really get that stuff about “network transparency”. X uses sockets for communication between client and server. And wayland uses… sockets. Don’t see much differences there.
About rendering, AFAIK, both Qt and GTK can use server-side rendering (both core rendering, and i.e. xrender) when needed, and it actually makes things faster and uses fewer bytes of memory. You can grep Qt code for XFillRectangle/XRenderFillRectangle to make sure. But that’s not the main thing.
I see a lot of other problems in wayland. And the main one – what is it for? No, really, what is that goal, that wayland allows you to get, but Xorg does not? For example, Xorg allows me to watch full-HD blu-ray movie on a side of a compiz cube without lags, that is impressive, will wayland have less CPU usage in that case? Xorg allows me to make a screencast of my desktop. It allows me to set a common decoration theme for all applications – if I want, I can use kde-window-decorator, if I don’t like it, I can use emerald. Can wayland do the same thing? These are just usual use-cases.
If I want to make drawing faster I can use some pixmap caching in Xorg, and most programs and toolkits do that, because that allows you to copy texture into a video-RAM and later just draw it in a single shot, can I do that with Wayland? There’s xrandr extension for Xorg, that allows me to use Xorg on a multihead system, what wayland has instead? Xorg has a known killing-feature of separate clipboard and selection, if you don’t like it – you can ignore it, but if you like it – it is there. What wayland can suggest for clipboard? What about keyboard layout switching, is wayland any better than Xorg there? BTW, how can you change desktop background in wayland? 😉
Architecture of X protocol was developed for years, and it was working for years. I can develop something on my Xorg desktop, then move it to my ebook reader (using Xvesa) being sure that it will work there. And even developed years ago X protocol is still so good that it allows such things as VDPAU/VAAPI (for video acceleration), Xnest/Xephyr (good for multiseat on modern dualhead cards) and bumblebee (you can’t say that bumblebee is unused, can you).
And if you say that wayland is still in development and “everything” will be there later – it won’t work. Because I can answer that you should drop wayland development and use Xorg, because “everything” IS already there.
So, actually, to explain people why they should spend their time for wayland you should not only say that all these things ARE already possible in wayland, but also find something, that you can do with wayland better than with Xorg. Is there such thing in this world?
Please have a look at my slides of Desktop Summit to understand why we need Wayland.
I was actually curious about some kind of comparison. Something simple, that an ordinary user can understand. For example, “With Xorg I can dynamically arrange my monitors using xrandr, but with Wayland I cannot”, or “With Xorg I can install cairo-dock/AWN or any other dock-bar I like, but with Wayland I cannot”. Or, maybe, some developer-style explanation, i.e. “With Xorg I can update only small parts of the window with pixmaps cached in Video-RAM to save CPU and reduce latency, but Wayland protocol has no support for it”. Can you name a few comparison-style examples like that to show what benefits wayland may have?
In your slides you’re mainly talking about differences in structure of X and Wayland, and naming a few disadvantages, like “Missing Input Redirection” (I guess you mean something like this: http://www.youtube.com/watch?v=k8bXfJhmOVg ), or “Strong limitations with Compositing”, but you’re not comparing them for Xorg and Wayland.
Also my question is not related to the kwin. The fact that KDE/kwin is so flexible that it can be adopted to work with different graphical backend is a great thing. The question was only why have you chose wayland as a background for it, why i.e. not directfb/nano-X/etc?
Everybody say that wayland will eventually replace Xorg. What is so good in the wayland itself?
The *one* thing that Wayland allow that X cannot do currently is to have an application render itself using the GPU then pass the buffer of the GPU’s memory to the display server without using the main memory.
This is an optimisation for the local display setup, unfortunately instead of adding this optimisation to X as an option, Wayland developpers choosed to provide only this feature, relying on others to re-add all the other features (network transparency, X compatibility), which will probably create an ugly mess IMHO.
FOAD
Wayland FTW, can’t wait!