Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The ways of Wayland (lwn.net)
126 points by iso-8859-1 on March 5, 2013 | hide | past | favorite | 60 comments


It's really frustrating reading all of the misunderstandings regarding Wayland and remote access.

The rendering modes modern applications use (SHM and dri2) are already just swapping image buffers around. The applications(the toolkits mostly) are doing all the rendering. So you if you are accessing X11 remotely you are _already_ sending image buffers over the network. Wayland can will be no worse at that and can potentially be much better.


For people using old X programs it's probably still sending X core protocol messages, but you're right that there are misunderstandings. What I and most people want is "ssh [-Y]" to continue to transparently forward the display so we can run programs. Luckily it seems that xpra[1] will do this for Wayland at some point, although the real test will be how simple it is to set up (like ssh -Y it should Just Work for the majority of users).

[1] http://xpra.org/


From my understanding, it seems like what we want is a VNC switch in ssh rather than necessarilly display server specific functionality. Go even further and maybe the ssh server could just use the RFB protocol vnc uses.

Any Linux VNC server worth its salt already support tunneling RFB over ssh. To take it a step further, you would just need very little display server support for an ssh server to request the framebuffer of an application it opens and send it via RFB or the vnc server to the client.

And I'd imagine Wayland already has some mechanism for other applications to read somethings frames. If it is generic enough, ssh should be able to use that. My only concern is that Wayland would need to be rendering programs but not displaying them locally, and I don't have any understanding of Wayland's internal implementation enough to know if it supports hidden windows like that.


Thank you so much for pointing out xpra. I've been wanting this exact feature for years. I frequently use Matlab on remote servers (they're closer to the data and faster than my laptop). I've been mostly able to get by through a combination of tmux, matlab -nodisplay, and rendering plots to files, but it's a less than ideal solution. Xpra does exactly what I need and it's glorious. Many thanks again.


That came up in the article:

"We think it's going to be better at remoting than X," Stone said, or at least it cannot be worse than X.

That is encouraging. I was worried that they were going to simply drop support for opening remote windows altogether. It looks like they've learned from the behavior of graphical networking outside of X.


They have openly discussed their intention to build an X-compatible layer on top of Wayland for remote windows for years, it is really sad that FUD has prevailed about how they want to take our remote windows away.


XWayland exists, but it's not the issue. We want to run native Wayland apps remotely.


Maybe you do, but then, maybe you have no idea what you're asking for and why it makes no sense.


Does Wayland support sending only buffers of the particular window I want to see on my desktop?

As I understand it, it's going to only support forwarding of the whole desktop (like VNC). And this would be a huge functionality regression.



Wayland/Weston already is better. That's the infuriating thing. If you watch the video from one of the main Wayland devs, he calls out the absurd crap that gets posted on reddit and LWN and months later, the same ludicrous crap is being posted.


I really like the Wayland path (and as an old Sun guy that says a bit ;-) I expect the folks worried about "remote wayland" really should be thinking about browsers, not window systems. Seriously.

In my opinion a browser window running Javascript is a much better 'remote window' to an application on a server elsewhere than X ever was.


Except that there are people actually relying on remote GUI apps right now, that aren't web apps and won't be. Seriously.

This is one of the reasons why Wayland is, after 4+ years, still not seriously deployed anywhere. It's easy to sit back and pontificate about how things "should" be. It's a much more involved proposition to actually getting around to breaking people's software. No one wants to pull the trigger with Wayland.

And, I suspect, that's part of the reason Canonical went with Mir (and for the record: I completely agree that the technical justification there is bunk). Wayland is forever-evolving and never quite there. Shuttleworth wants something to ship. If your requirement is to pull a trigger, you at least want to know that you own the gun.

Is that good or bad for Ubuntu or the community? I don't know and won't try to guess. But I will say that at least some of the ire directed at Ubuntu might be better directed at the Freedesktop folks for not getting something ready years earlier.

Basically, if X sucked so much, why wasn't there more urgency directed at replacing it? Crying now because someone else got there first seems counterproductive.


I don't think X is going away any time soon, you your GUI apps are safe. I've observed that a number of things that used to be GUI apps for me have become web apps though, sometimes to dedicated controllers running embedded web servers but web apps none the less. I would be interested to hear about apps that are both "remote GUI apps" and there is no path to them becoming web apps. (not 'in the cloud' but driven by an application framework that replaces

"local X client executable" + "local X server" + "remote server"

or

"local X server" + "remote X client" + "remote server"

Which can't be replaced with:

"local browser" + "remote script" + "remote server"

There just seems to be a wealth of tools to support that.

That said, I am not sure that people using X11 is why Wayland hasn't really been present. There really is a bunch of things that all have to be true and getting all of those things true has always been difficult, and its even more difficult in open source.

My background is from Sun, where we had this cool set of applications and stuff called "SunTools" which were awesome but not widgety. Dave Rosenthal was a big proponent of X11 and after a few years it looked like it might be useful and Sun put a lot of effort around aligning the kernel the user land tools, the libraries, etc. We all worked for the same company and it was still a horribly arduous task. Because of that experience, my feeling is that Wayland's progress has been par for the course for something which changes as much of the underlying stuff as it does. There is a lot of change in there.

We also may disagree on Mir, I think Canonical is backing Mir because they "own" it, and got tired of waiting for negotiations to settle out before moving forward. I don't know of course, I don't have any inside knowledge, but I do think the rate of implementation Shuttleworth has pushed for is antithetical to something that needs as many players in the game as Wayland does and still leave it open to consensus decision making. I been building a Weston based application off and on the PandaBoard for a couple of years and have followed events around there a bit. A lot of strong, correct, and incompatible opinions makes for slow going. Part of the challenge is everyone brings their own requirements which makes their opinion more applicable. It looked to me like Canonical said "We're going to align all decisions on this to the point 'makes Unity Next work well'"

My guess, is that X has survived as long as it has because the pain of replacing it is great. However I predict that once either Mir or Wayland hit the tipping point people will abandon X rapidly and leave it in the dustbin of history. Only time will tell.


JavaScript is the new PostScript (how old a Sun guy are you?)


FWIW I joined Sun in 1986, my first day was the Monday after they went public. It had an impact on how they priced my options :-).


From TFA:

    > The first important idea is that in Wayland, every 
    > frame is regarded as "perfect." That is, the client 
    > application draws it in a completed form [...]
This is interesting, but also seems to run counter to recent work on the importance of very low latency feedback. See John Carmack's recent article on latency mitigation for VR headsets[1][2] for a very detailed example of this issue. Similar ideas also apply to touch[3][4] and even good old keyboard & mouse input schemes. There's a tradeoff between "perfect" frames and latency (see Carmack's post). From the quote, it appears that Wayland's design choice may limit achievable latencies for low-latency applications.

[1] http://www.altdevblogaday.com/2013/02/22/latency-mitigation-...

[2] #1 on HN: https://news.ycombinator.com/item?id=5265513

[3] https://dl.acm.org/citation.cfm?id=2380174

[4] https://www.youtube.com/watch?v=vOvQCPLkPt4


Low latency feedback is important for some things, but complete double buffering is the right default for a window system, because flicker is even worse than touch lag.

This is one of the reasons people think iOS is so "snappy." It goes to great lengths to never show you a partially-drawn frame. If you compare Safari to say Internet Explorer on Windows RT, you see that IE looks like ass when rendering complex pages, because it'll happily show you frames it's done laying out yet.



The talk is available as video here: http://mirror.linux.org.au/linux.conf.au/2013/ogv/


But somehow canonical doesn't like it and has to implement Mir.


You are literally the first comment in the entire thread and you have nothing to offer but to chide Canonical, who by the way, were not even mentioned in the article. Neither was Ubuntu. In fact, you have to go about 4-5 threads deep in the comments to see a mention of Ubuntu or Canonical (specifically).

This article is about Wayland. Do you have any thoughts on Wayland? Weston? The future? X, even? Maybe some specific question about Mir and how it relates to thing things Wayland wants to do as well? The advantages of one vs the other? No? You don't have anything constructive to add? Greeeeeeeeeaaaaaaaat.

It's times like these I wish I could downvote a comment more than once.


Given that the Mir discussion was on the front page some hours ago, this comment does have something _constructive_ to add.


There is literally _nothing_ constructive about the comment. Related to recent news? Yes. Topical? Sure. Snitty? Yup. Constructive? Nope.


Who said comments need to be constructive? We don't have to be working towards a better future every single second of the day, you know.


Welcome to HackerNews. Please read this: http://ycombinator.com/newswelcome.html

"The most important principle on HN, though, is to make thoughtful comments. Thoughtful in both senses: both civil and substantial."


Yes, that's great, but that's got nothing to do with being constructive. Constructive comments are great, but someone could publish a long and interesting comment criticizing wayland or X11 without suggesting ways to improve. As long as the points are cogent, then the comment should make for worthy material. At no point do such criticisms have to make suggestions on how to improve wayland or X11. Just that they are civil, and substantial. Like you said.

Or maybe you're agreeing with me? It seems strange to redirect me to the newbie guide then.


I took constructive as in constructive to the conversation, not to the person in general.

The definition of constructive is to serve a purpose, whether negative or positive it doesn't matter.


Tell fingerprinter this about being civil.


I hope you're happy when you watch a superior open source project stagnate before it had a chance to grow.


What make one project superior to the other, besides your opinion? Open source is darwinian. If one project proves its superiority, development will shift and other projects will change. I would think that, as a hacker community, we could accept that.


It's not /exactly/ darwinian when one project is being driven by an organization with clout and corporate partnerships. If you're Nvidia/AMD/Intel, which project would you be more receptive toward throwing your weight behind? The rinky-dinky band of Linux hackers with good intentions, or Canonical?

What the manufacturers decide to do is critical, and I promise you they aren't taking some kind of meritocratic open-source approach to evaluating where to place their resources.


First, I mean superior to X, not other hypothetical versions of wayland.

I am worried that the manpower will be divided and that minor decisions now will fuck up cross communal efforts. That's a reasonable belief.


It is a reasonable belief. And I'm not criticizing you for having it. Still, this process has repeated itself for a long time. Its not always fast and the best doesn't always win, but its how things seem to work.


The most likely outcome is the Canonical toils away themselves on Mir, and everyone else works on Wayland/Weston. Maybe at some point Canonical decides that it's better to just use Wayland, but that's about it.

Wayland is already at 1.0, and has support from Valve, Nvidia, and AMD behind it. I don't see it disappearing soon. Especially since the implementation of Mir isn't even usable yet (while Wayland is).


Sadly, it seems neither Nvidia or AMD have specific plans for this:

Nvidia http://www.phoronix.com/scan.php?page=news_item&px=MTE5M...

AMD http://www.phoronix.com/scan.php?page=news_item&px=MTE2N...

A great pity.


Wayland has support from NVidia and AMD behind it? That's news to me. Last time I heard NVidia announced that they will never support KMS.


Ok, I may have misread something, but I was going off of this[1], which was posted elsewhere. I could have sworn that a comment from one of the Wayland devs claimed that Nvidia, AMD, Valve were on-board (at least tentatively) with Wayland, but I can't find that post now.

[1] https://plus.google.com/100409717163242445476/posts/jDq6BAgd...


I agree with ginko, is there some supporting evidence you have that points to support from NVIDIA?

If so, that's a pretty interesting development.

---

EDIT: Thanks for the update ElliotH!


"Somehow"?

They've given a specific list of reasons. If you're going to complain about it, at least refute their specific technical reasons if you want your complaint to have any credibility.


They've given a specific list of reasons.

Reasons that mean nothing to those of us that don't understand display servers and/or composting.

If you're going to complain about it, at least refute their specific technical reasons if you want your complaint to have any credibility.

I can't, and I don't think any of us meaningfully can unless there are some X, Wayland or Mir developers lurking around HN.

But I think the Wayland dev's google plus post [3] mailing list post [2] and IRC log [1] all give the impression that that list of reasons offered up by Ubuntu is, at least in part, bunk or could be addressed upstream in wayland. An upstream project that Ubuntu was already involved in for years and had the power to shape but never actually voiced their concerns when wayland's architecture didn't meet ubuntu's requirements. Ubuntu is free not to reveal the real reasons behind their decision, but unless they do the whole thing is dripping in Not Invented Here syndrome.

In fact, it seems like from the Wayland community, the problem isn't that Ubuntu is striking it out on their own, its that they're distributing a bunch of miss-understanding about Wayland in the process.

    01:16 <RAOF [Ubuntu dev]> We're not forking wayland; that's part of what krh [Wayland lead] is annoyed with?
    01:17 <Prf_Jakob> RAOF: he said he was annoyed with you having a wiki page full of missunderstandings of how wayland work.
[1] http://pastebin.com/KjRm3be1

[2] http://lists.freedesktop.org/archives/wayland-devel/2013-Mar...

[3] https://plus.google.com/100409717163242445476/posts


specific? They are pretty damn vague, not to mention completely wrong. See e.g. the comments from X.org/Wayland developers at:

https://plus.google.com/100409717163242445476/posts/jDq6BAgd...


Yes, they got one thing wrong though it's already been corrected in Canonical's design document.

But it seems to me that the main problem Canonical had with Wayland was that they wanted to run their stack on devices that only had Android device drivers. As far as I can tell Wayland relies on things like KMS to function, and at the very least Firefox OS has no plans to use Wayland because they don't think they can get it to use the Android drivers they're planning on using.


> As far as I can tell Wayland relies on things like KMS to function

Is this a limitation of Wayland or the reference implementation? If I'm not mistaken the server needs a modesetting api, not necessarily KMS.

The server runs on top of a modesetting API (kernel modesetting, OpenWF Display or similar)

http://wayland.freedesktop.org/architecture.html


That seems like a very good and practical reason to me. As far as I could tell, Wayland is very much tied to KMS, and not interested in doing otherwise.


Wayland already had a proof-of-concept Android backend that worked with Android drivers.


So much the worse for using Android. It's past time that we have proper Linux on phones without interposing all the Google-Java stuff.


I believe this was referring to the Android kernel patches, not the Java-based userland.


Java, or rather Dalvik, has absolutely nothing to do with the kernel or graphics stack in Android.


Why is this a bad thing? Why is it not a cause for celebration that we have two, rather than one, parallel attempts to replace X?


It's not necessarily a bad thing, but it is an awkward thing. The problematic thing is that for graphics drivers to work on linux they need to interface with X.

This means that the closed-source drivers are tightly coupled with X and can only be made to work with Wayland by the Nvidia and AMD teams themselves.

Now Ubuntu comes along, looks at wayland and decides that it is not good enough for some reasons they _hopefully_ have thought long and hard about and starts working on an alternative.

But Ubuntu actually has enough clout to convince AMD and NVidia to work with them on this new system. This means wayland is effectively shut out and might as well call it quits.

So the awkward thing is that we were promised a clean, fast well architected system for years which after years of development finally reached 1.0 and seems to be quite usable. At that precise point the only company capable of making wayland real-world stuff changes his mind and decides on going all-in on some software we don't know if even exists yet and for some magical reason is better than Wayland.

Everyone is just stunned :P


1/ Mir is dependent on a proprietary Boost software license, and, should it follow Canonical's normal path, will require you to assign your work to them to contribute. Properietary dependencies and a requirement to hand over your code to a commercial entity can be considered open source, in much the same way that, say, OpenSolaris was, with similar pitfalls. For something so foundational, that's not great.

2/ NIH is a bad reason for parallel projects.

3/ The major reason that nothing has unseated X, despite its very longstanding, well-known problems, is because nothing has had momentum until Wayland. Canonical seem determined to deep-six that momentum with a piece of software that will require other Linux environments to buy into a company-owned replacement. This seems likely to fragment the effort it a toxic way, with two incompatible replacements splitting not just graphics development efforts, but splitting app developers.


Don't disagree with you overall, but I do have one nitpicl. There is nothing proprietary about the Boost license. Boost license is quite similar to MIT license.


Perhaps I'm misreading what appears to be the Mir license block:

GNU GPL v3, GNU LGPL v3, MIT / X / Expat Licence, Other/Open Source (Boost Software License - Version 1.0) Commercial subscription expires 2022-09-24


What is there to misread? Boost Software License is there?

https://www.gnu.org/licenses/license-list.html :

Boost Software License (#boost) This is a lax, permissive non-copyleft free software license, compatible with the GNU GPL.


Mir is likely to be influenced by Canonical's experience using Surface Flinger as a compositor for Ubuntu Touch.


In regards to X and it's growing pains, in the era of source control, why is backwards compatibility with ancient systems still a concern? If you're trying to put together an old OS for some old hardware, why not take it out of the source history and let the head progress forward unhindered?


I would guess it's because the moment you do that you push down the problem to the library/application programmers. They will still have to support old systems and suddenly it's no longer a handful X developers who have to maintain backward compatibility but thousands of application developers all over the world which have this task. And certainly not all application programmers will care so the problem will be pushed on further and hit some users.

The problem with downward compatibility never completely goes away. But the closer it is handled to the base the less people have to care about it.

Now there is on the other hand a point where you could say every application programmer has to do so much extra work because the protocols are outdated and overly complicated that breaking downward compatibility will make the life of the average application developer easier. Not an exactly defined point in time - definitely way less obvious than the moment where compatibility is broken. But I guess that's when the break should (have) happen(ed).


I get the impression that many Linux users have specific old versions of software (often a window manager, which complicates the issue) that they want to keep using forever, but want to simultaneously use the latest version of some other software (like a browser).


Linux is pertinent here because we're talking about X11, but it should be noted that this is by no means specific to Linux - the same could be said about any OS with widespread use by different groups of people.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: