“Although current discussion of the Linux desktop tends to focus on the disharmony around Unity and the GNOME shell, the true revolution on the desktop is taking place out of sight of users. The Wayland display server is expected to reach version 1.0 later this year, and is seen by many as the long term replacement for the X Window System, with real potential to improve and transform the performance of the desktop for Linux users.”
From the FAQ: “X will always be there on the side.”
X is effectively the remote desktop protocol for Linux. The only strangeness has been that Linux has used “remote desktop” on the local machine as well. Wayland basically gives an app direct access to the compositor.
I hope like hell that this is only implemented for games or other “special” applications, and that toolkits like GTK and QT add Wayland support for better performance. I’d hate to lose the ability to realistically use a linux desktop remotely.
From my own reading on Wayland, X isn’t being kept for remoting – it’s being kept for compatibility, since apps compiled for X aren’t going to go away any time soon. Support for remoting is incidental to that.
For native Wayland apps, the hypothetical solution to remoting involves a custom compositor – the app has direct access to *a* compositor, but it’s one that simply proxies everything across a network to the real one.
(Hypothetical because nobody has actually done it, but this is how the Wayland guys think remoting should be done – in the compositor, not in the rendering API where apps have to deal with it.)
Great explanation, I wish someone will write a network-transparent compositor using Wayland.
So we can debunk the myth that “Wayland won’t be able to do network transparency” and so that people can actually learn how Wayland works.
Edited 2012-02-14 03:57 UTC
Good luck on that. The information is already there for anyone to read – that’s why I’m able to comment on the subject, from having read what the developers have said on the mailing lists.
But the people who spread myths generally aren’t the kind of people who are interested in spending time learning how things actually work – if they were, they’d have done it, and wouldn’t be spreading myths. They read the the summary and comments on news sites, and don’t bother following the links to get the details.
Exactly, that’s why I’d like to see someone with the right skills to show up and write a network-transparent compositor for Wayland.
That will silent all the people crying and spreading FUD.
If I only had the skills…
Edited 2012-02-14 05:11 UTC
They read the the summary and comments on news sites, and don’t bother following the links to get the details.
Or maybe they do and lack the technological depth in display technology to make heads or tails of it. Then it becomes a game of following the most convincing comments.
The first cries were “Wayland can’t do remote windowing”. Now we are at the stage that “Wayland can possibly do remoting of a window, but it hasn’t been implemented (yet) and it isn’t a high priority.”
I’m quite the simpleton when it comes to technology. When I first heard that Wayland couldn’t do remoting, I thought that would be a loss over X.
After that I thought, if the system can send multiple windows over an HDMI wire to a display screen, at least it should be able to do the same over a network cable.
Now that the internal architecture is becoming more clear, it seems feasible to use a “compositing relay” that sends the individual screenbuffers remotely to another Weston compositor on a different machine.
I could be way of the mark here, but that is what I plussed together from info over Wayland out of articles and, more importantly, comments.
“Loss” is that there is no standard for network transparency, like with X. Remoting protocol design is left to the implementers of the compositor. I don’t see that as a big problem. NX for example is a custom protocol encapsulating X, but works brilliantly and does everything X does, but much better and faster.
Since, in modern day, “raw” X remoting of apps is done in most cases over ssh, once OpenSSH implements Wayland remoting, there will be no sensible difference (with added features, like remoting whole desktop over ssh).
I have my doubts: the desktop projects (KDE, Gnome) which do a lot of maintenance of the toolkits are quite famous for their lack of compatibility.
So I wouldn’t be surprised that soon they’ll say, now we don’t support anymore X, Wayland is better..
And IMHO noone has suggested a convincing remote mechanism for WAN access on Wayland (no rewrite everything in HTML isn’t convincing, neither is send full buffers).
That’s not what’s meant here with “compatibility”. What’s meant here is legacy apps for which there is no current equivalent, but they still do their job fine. X will be there, working inside Wayland, so that you’ll still be able to run such legacy apps.
Why would you expect the client to send the full compositing buffer? It just has to send the damage regions (and probably it’s clip list).
That’s still a slow way to do it. RDP supports tunneling GDI and GDI+ commands over the wire so that rendering can be done server-side. Images, of course, will have to be transmitted over the wire, but text and rectangles and even gradients can be done server-side. The result is that RDP is pretty darn fast, especially compared to the Unix equivalents (VNC, which uses screen-scraping and is slow; NX which is closer to tunneling and thus is faster, but still not as good as RDP; native X which uses nothing but X commands, but because of the inefficiency in protocol usage, is horribly slow over the internet).
That’s a really simple way of describing it. +1!
I use the network capabilities of X on a regular basis and until there is a comparable feature in Wayland both are going to be living together for a few years yet.
The first time i opened up a remote nautilus window at work from my laptop at home; i was sold.
It is going to be a decade before Wayland is anywhere near what X is in features and support where a LINUX distro doesn’t need a Xorg display server.
Also, I doubt X is going to sit still during that time. Contrary to what everyone is reading, X is not going to go away, and it most certainly is not going to stop evolving.
Not only that but there are other developments going on in the SPICE camp that could trump both X and Wayland. Who knows what they will think up over there.
Good thing too. If LINUX is going to be a desktop OS, it has to have better display performance than Mac OS X, and Windows combined.
SPICE, Wayland and Xorg should converge over the next 3 years to provide a environment that I am hoping will do that.
Think of it as the Grand Unified Display Theory.
😉
-Hack
So we all know that Wayland doesn’t implement network transparency directly in the protocol, fine.
We can still implement network transparency in the compositor or toolkit.
My question is: what happens if kwin (or another wm/compositor) implements their own network transparency, will that only work with kwin?
What if kwin implements network transparency in their own way and someone else writes a different compositor with a different approach for network transparency?
Does that means that network transparency will suffer with interoperability problems?
I think there has to be a standard protocol.
What are your thoughts?
Edited 2012-02-14 05:44 UTC
Perhaps it could be done as a separate proxy process (1 per remote app) that communicates with the remote app and redirects input/output. The compositor sees that process as a normal local app. That process could be used with different compositors without changes.
Yes, note though that the compositor see only buffers so network transparency in the compositor may work correctly on a LAN but it would probably suck for a WAN.
That depends: if the network transparency reuse the existing protocol (X) in a not too different way then there won’t be too many interoperability problems (assuming and that’s a big assumption that the desktops projects still support X).
Well there is one currently X, but as you may have noticed it is under attack..
The probability that the desktops projects arrive to an agreement for a new remote protocol is about the same that distributions agree on a standard packaging format..
I don’t mind, choices and alternatives are a good thing, and I’m actually very excited about Wayland.
I hope we don’t get issues with interoperability though.
Imagine in the future if the compositors start implementing their own versions of network transparency, and we want to forward a window from KDE to Gnome and then the compositors for those environments have problems with interoperability, that would suck.
I don’t want to have to install the same compositor (kwin/mutter/whatever) in all my machines for network transparency to work well.
Well, maybe I’m just making this up, and it’s probably going to work well.
I’m also not trying to be pessimistic, I only hope the developers will think about all those scenarios and do a great job, I’m sure they will.
Edited 2012-02-14 10:13 UTC
I don’t mind, choices and alternatives are a good thing, and I’m actually very excited about Wayland.
I hope we don’t get issues with interoperability though.
Imagine in the future if the compositors start implementing their own versions of network transparency, and we want to forward a window from KDE to Gnome and then the compositors for those environments have problems with interoperability, that would suck.
I don’t want to have to install the same compositor (kwin/mutter/whatever) in all my machines for network transparency to work well.
Well, maybe I’m just making this up, and it’s probably going to work well.
I’m also not trying to be pessimistic, I only hope the developers will think about all those scenarios and do a great job, I’m sure they will. [/q]
Ignore my comments above. I think compositors can just implement RDP or another protocol and be done with it. Problem solved.
Edited 2012-02-14 12:25 UTC
From what I gather, KWin *wouldn’t* implement their own network transparency on Wayland – it’s only job is to display the content that clients provide it with.
The network compositor would be a separate thing, which instead of displaying content, proxies it across the network where it acts as a client to KWin (or other), which actually displays that content.
This compositor would potentially be linked into SSH, so you could tunnel Wayland apps over an ssh connection, just like you can with X today.
Very nice, thanks for explaining.
Using SSH would be great, since it’s encrypted and secure.
Thanks.
Where is it leaving the BSDs?
In terms of display manager they do not seem to innovate. A clean room implementation of a similar technology would help them.
It seems that Xorg is pushed to the user space. Where does it leave them?
For the short term Xorg will be there. But in the long run they should sit all-together and find a solution.
They could adopt X-over-DirectFB or X-over-SDL. Both are reasonable alternatives. Or they could take parts of Haiku DM and create a true cross-BSD solution.
There is also OpenWF which could also be part of the solution. Or even re-implement Quartz.
Haiku desktop ontop of BSD?, holy mackaroni! Imagine the driver support compared to today. Some caveats though, BSD does not provide a good desktop for most haiku users at the moment, and it is just a toolkit hell as linux, and some bad decisions might be made to keep the “jack of all trades” feat of BSD (in my oppinion, but specialized BSD versions could probably do just fine). I doubt anyone using BSD would use the desktop oriented filesystem BFS of haiku, wich could be problematic for using the haiku desktop instant search and handling of metadata. (if they do not find something else that works with the OpenTracker ofcourse). And most haiku users do not like GTK very much, so the desktop would be using haikuapi and gui or QT with native look. Also i would be afarid of what boot times BSD would provide, even OSX is slow as dirt to start up in comparison to Haiku or BeOS on supported hardware.
Otherwise hell yeah, why not, i would follow that project closely.
If my post seems wierd, it probably is, and then you can disregard it all. It made sense to me atleast at posting time. Hehe
If BeOS was made open source when Be Inc. died, the IT world would be far different from today… just imagine.
However “gone wild” imagination of geeks can be – IT world doesn’t care, it would be pretty much the same.
As nice as BeOS was, it didn’t really see any substantial uptake even when it was essentially given away for free (yeah, beer not speech, but it seemingly hardly matters to vast masses – and they are who ultimately shapes any possible shifts, large scale dynamics), didn’t change IT world much.
In the end, the IT world really hardly even noticed the death of Be a decade ago, it firmly embraced other solutions by then (sure, you might point to some nefarious conspiracies – which, in the end, doesn’t change anything; plus the errors of Be would be enough – heck, BeOS was made available for x86 machines only 3 years earlier, by then it was already too late)
If it was to scrap X11 altogether, the most powerful benevolent dictators of large open source projects should have at least considered existing and more matured solutions first, like Fresco Windowing System.
Why the incomplete and highly experimental Wayland is being favored after all when we have ready to use solutions at hand?
R.I.P: from Wikipedia: last CVS activity was in 2004.
You realize that the trend is to reduce what the display server does and to have powerful toolkits for client applications?
Which is the exact opposite of the Berlin/Fresco’s design.
A ‘solution’ that’s been dead for eight years and never really went anywhere before then – you count that as “ready to use”?
For developers to finish it, yes. Its a ready to use code base.
Unmaintained for nearly a decade, never really going beyond simple demos, and putting it up to speed after such time would be probably more work than making Wayland usable.
Don’t live in fantasy world; focusing on few realistic goals would do us much better (not saying that Wayland is necessarily the best approach; but Fresco or Y are almost certainly at least not better)
I am so surprised that his got such a small response. How awesome is this? A potenital to finally move away from X. The Plusses:
1. Complete with the modularity to accomodate for network transparency in the future for those who want or need it, and a way to continue to use X until it comes along! Talk about a clear path to adoption for those requiring that feature!
2. The ability to take advantage of kernel features, clean out all the code that isn’t really necessary to render a single PC/desktop, and once again still use X until the clean up is complete!
Yowza! I’ve been excited about this project since I read about it on phoronix and then checked out the home page! I don’t understand how no one else can be…
Oh well, Ill just do my happy dance over here in the corner 🙂