Hacker News new | comments | show | ask | jobs | submit login
An introduction to Wayland (drewdevault.com)
192 points by Sir_Cmpwn on June 11, 2017 | hide | past | web | favorite | 86 comments



> Wayland is the new hotness on the Linux graphics stack

Use wayland (with gnome) everyday myself but wanted to point out that wayland started almost 10 years ago :) The adoption has taken forever though partly because of the infinite legacy of X11 and lack of support from big players like nvidia.


Adoption has taken forever mostly because it's a solution in search of a problem, at least in terms of how it's been sold to users. The main user-visible difference is "lose the ability to run remote programs on your local display" - you can understand why users aren't lining up for that.


For what it's worth, I might be a more-obsessive-than-average user, but it kills me when I see tearing and flickering in X11 windows. "Every frame is perfect" is a super visible change :)

Btw, am I right that tearing in a video in VLC is an X11 interaction, or is that purely a VLC thing that I should expect to keep happening with Wayland support?


> but it kills me when I see tearing and flickering in X11 windows

Honestly don't think this will ever be solved in the open source world. It rarely even gets solved in the commercial world unless there is an internal design team involved who have enough power to force the dev team to solve these things. Win 10 for example has some silky smooth transitions but then you resize an explorer window and it flickers black.

So many people don't even seem to notice it but for some of us it's nails on a chalkboard.


VLC is notoriously buggy in general. I'd put a lot more stock in how mplayer (or whatever the popular option is these days), xine or even ffplay behave.


The classic tragedy of Linux-on-the-Desktop: trying to gain traction by removing perceived "warts", all the while alienating user and developer communities alike. Result: more cluttered landscape that is even less of a target platform for desktop software.


> removing perceived "warts"

Unfortunately a lot of people look at large projects full of difficult to understand, ugly, inelegant code and see a pile of spaghetti and warts that is hard to maintain. In many cases - especially mature projects that are widely used - the warts and inelegance are bugfixes, the piles of spaghetti are the compromises needed in complex interdependent systems and the workarounds/patches that handle the messy problems of real life.

As Joel Spolsky famously explained[1], a lot of those "warts" are the most valuable part of the software. They represent an incredible amount of programmer time and effort. Throwing them out and starting over sounds nice because the clean, elegant replacement is solving a far simpler problem. The replacement is usually missing features and bugfixes. When you finally update the new version to be an actual full-featured, bug tested and fixed replacement, you've probably re-added most of the messy "warts".

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...


A lot of warts in software come from legacy constraints - both I'm terms of backcompat, and HW/design constraints that are laughably irrelevant - throwing out warts and starting simpler is how you got ZFS for eg.


> HW

I'm only talking about software.

> legacy constraints

Those "legacy constraints" are often being used. Backwards compatibility is very important, because throwing out decades of development efforts involving millions of man-hours. Supporting legacy interfaces can be annoying and in some situations it gets in the way of newer features, but it's incredibly rare

> ZFS

Nothing needed to be thrown out to implement ZFS. More than one software interface can exist at the same time. ZFS development didn't use some of the features used by traditional filesystems, but it's "rampant layering violations" didn't require the removal of UFS, RAID, or older volume management drivers. The fact that it's always been possible to mount ZFS and older UFS disks at the same time should make this obvious.


Or maybe X11 is actually useful to many people... I regularly run expensive commercial software remotely on a beefy server and access the GUI locally via X forwarding. I suspect among professional desktop use of Linux (besides software development) this a fairly common scenario.


You can still have X-forwarding (by running a Xwayland server) while having all the benefits of Wayland for all the other desktop apps you run.


Only for now, only X applications. If they end up migrated to Wayland this will be gone.


And at that point he may as well get a Windows box and use Putty...


And at that point better advise would be to use DOS


Does anybody know what happened to "Wayland Over Wire" which was supposed to solve this?


It was never more than one guy's idle experiment.


I think that's how all software starts. Well, replace "one guy" with "someone".


Not just that. It took major DEs a very long time to get to some level of readiness with Wayland (KDE is just getting to it). And some major applications aren't event close yet. Firefox seems to be in progress for years, and Wine didn't even start moving to Wayland, because of various difficulties.


One of the reasons why Wine worked in the first place is because GDI primitives map nicely to X11 drawing primitives. Wayland developers made the Yao Ming "bitch please" face and told us "no one uses those dusty old primitives anymore! Here, have a bare framebuffer and render everything yourself!"


Or they could just use Cairo, which will do that for them.


Yeah, that's what I've heard, that one of the hard parts was mapping positioning of windows.


I think that's less "hard" and more "impossible by design" - that is, Wayland intentionally doesn't give applications any way to know or control the absolute positions of their windows, and of course Windows applications expect this.


They can use a virtual desktop sized as screen itself, and position windows that way.


It's a complicated software in a complicated world. It takes time.


I have to agreee with you. How many look at the current situation and compare to a realistic best case?

If wayland were adopted as fast possible without breaking a bunch of things for people how long would it take? Much longer than it is now, or just slightly longer?

Even if every body wanted could we have gotten this done in 5 years without breaking a ton of stuff?


Interesting article, nice to see some more practical examples.

For those unaware, SirCmpwn is responsible for sway - https://github.com/SirCmpwn/sway - which aims to be an i3 compatible compositor for Wayland. In my experience it's not production ready yet, but it's definitely a pretty cool project to keep an eye on if you do use i3.


Out of curiosity, when was your last exposure to Sway? Many people use it as their daily driver and would agree that it's production ready (even if it's not done). Can you report any bugs you find?


Not OP but I'm using sway when I'm on Linux, too. The only annoying thing is, that the mouse cursor is laggy when the system is under load. Apart from that I think it is pretty good! A systray would be nice of course but that is not a deal breaker. Thanks for the amazing work!


>A systray would be nice of course but that is not a deal breaker.

You can actually expect that to ship in the upcoming release :)


You've just made my day :D


The most annoying thing is the mouse lag and higher resource utilization compared to i3.

Aside from that, it's great though. I used it for a month before going back to i3, you've really put a good amount of work into the project.


That's fair, it definitely has inferior performance.


What are the reasons? Is there any problem that cannot be solved?


A lot of it comes down to the choice to use wlc[1], a library that provides some of the low-level plumbing for Sway. It was great for getting Sway up and running quickly, but it's not very flexible for the directions we want to go. Most of Sway's performance issues are due to WLC or decisions Sway had to make to accomodate WLC.

Currently most of the work on Sway is being done on wlroots[2], with the goal of replacing wlc. The design is much more flexible and should have better performance and should avoid imposing constraints on Sway that impact its performance. A lot of Sway features are also currently blocked by wlroots, since wlc isn't flexible enough to allow us to implement them. I'm actually lucky enough to be working on wlroots full time at the moment, thanks to a generous commercial sponsor[3], along with some support from Patreon[4]. The future is definitely bright for Sway :)

[1] https://github.com/Cloudef/wlc [2] https://github.com/SirCmpwn/wlroots [3] https://nyantec.com/ [4] https://www.patreon.com/sircmpwn


A few months back, and then again today.

> Can you report any bugs you find? Perhaps, but I'm not convinced they're bugs in your code.

When I said it wasn't production ready, I was referring to the ecosystem (using xwayland, GTK apps etc). In my experience this isn't quite as good. As an example: searching in Firefox is glitchy (dropdown menu), resizing apps (even apps such as urxvt) in Sway is a bit glitchy during the resize etc. I'm not sure how many of these things have been reported. The default mouse wheel speed and mouse speed seems to be odd, I think I need to read up on the documentation to fix this.


Thanks for clarifying, that makes sense! Those Sway issues are known, but no one really thinks they're dealbreakers.


I spent some time recently trying it on my XPS 13 and I noticed that the mouse would freeze sometimes as well. Also there are some weird glitches when using apps like Steam, but that's not a major issue really.

Probably the two things (which aren't sway issues) that kept me from continuing to use it are that wayland doesn't work properly with Synergy (which I use a lot) and I'm not an i3 user and I'm a lot more comfortable and familiar with XMonad but I'm sure I could configure it to my taste given enough free time.


I used Sway for a while, and remember it being pretty stable.

I switched from Wayland back to X due to bugs in other applications, such as Firefox.


Last I saw, it broke when trying to use multiple monitors. This was a few months ago, 3 monitors, Fedora 25 I think.


Please come around the IRC channel and ask for support or report the problems you encounter on GitHub. Multiple monitors should be totally stable.



There's also the full fledged OS/Desktop Environment called Liri https://liri.io that was a pivot from papyrus using Wayland.


Fun fact: Wayland is supported on ChromeOS versions 50 and above for the supported Android applications.[0][1] Consequently, you can run Fedora with Wayland on a supported Chromebook using crouton.[2]

[0]https://bugs.chromium.org/p/chromium/issues/detail?id=549781

[1]http://www.phoronix.com/scan.php?page=news_item&px=Google-Ch...

[2]https://nmilosev.svbtle.com/crouton-fedora-wayland-yes-pleas...


nice, i've actually reset my chromebook (removing crouton) a few month ago because the constant context switching annoyed me... i think ill reenable it later today and try that out


If I recall correctly, one major catch is that wl_shell has been feature-frozen since 2012 and lacks newfangled features like the ability to minimize windows. For newer functionality you need to use xdg-shell instead, which regularly changes in backwards-incompatible ways and there's no guarantee the version your application implements (or any version of it) will actually be available.


I don't follow Wayland closely but there's a thread proposing stabilisation from a little while back https://lists.freedesktop.org/archives/wayland-devel/2017-Ma...


I was hoping for a somewhat broader and more abstract discussion of the concepts used in Wayland (and not C structures).


A question that may only be of interest to me: is anyone looking at getting Wayland running on Windows? In particular, interacting with the new WSL stuff?


I imagine it's possible, but complicated. You'll likely need a custom backend for your compositor - I doubt WSL implements DRM (display resource management).


WSL doesn't support the graphics stack at all. But it is possible to VNC or RDP (with xrdp as a server) into an X11 session running inside WSL, so that's what people do.

You wrote below that Wayland supports RDP. If so, it sounds like that should work?


I wrote below that Weston (a specific Wayland compositor) supports RDP and that Sway eventually will. But yes, Weston might work on Windows in that case.


Why does this remind me of CORBA?


It's definitely using the same IDL->language dependent API as CORBA, but that doesn't mean it has to be an out of control garbage fire.


doesnt mean it won't either.

minimize is already shoved in the debug api. sigh, in the end I really hope nobody but qt/gtk/sdl devs are even getting close to this.


On that note, Torvalds rants about some missing functionality in some G+ comments i came across.

https://plus.google.com/+KeithPackard/posts/azxz8ZPKght

Sadly it seems impossible to link to individual comments.


Is something like VNC or some other way to remotely view a desktop or an app going to be possible in Wayland?


Weston supports RDP and in the future Sway will as well.


Last time I tried, weston-rdp was unusuable: slow, high bandwidth usage and had trouble with key repeat (pressing a key even for a short while resulted in multiple characters).


Has anyone been able to run Chrome (or anything Electron based) on Wayland in a virtual machine? I just a black rectangle instead of Chrome/VSCode/etc.

Disabling GPU acceleration for Chrome via command line flags or for the VM entirely seems to fix it, but that's obviously a non-solution.

I'm running Fedora 25 in a VMWare Workstation 12 with a Windows 10 host.


Are there any decent, minimalistic tiling WMs for Wayland yet? IIRC awesomewm wasn't planning on supporting Wayland.


Sway (basically i3) I actually used for quite a while as my daily driver and it works great. Another one I want to check out soon is Way Cooler.

https://github.com/SirCmpwn/sway https://github.com/way-cooler/way-cooler


I'm surprised to see XML. Wouldn't JSON or some other format be a better choice?


XML has several advantages over JSON: it's much better at self-documentation and the schema validation tools are more powerful. Namespaces compose elegantly. XML has a bad reputation due to enterprise-y abuse of the technology, but that does't mean it's a fundamentally bad idea.


I never saw a nice use-case of namespaces. Maybe you can show me one?

So far I have only seen namespaces used by Inkscape to state that a SVG is a still image using 3 different name-spaces in one hierarchy. Does it not just add complexity to need to support different standards at the same time


> I never saw a nice use-case of namespaces. Maybe you can show me one?

Basic example: If you want to mix data from several formats in one document.

Let's say you want to create an RSS-feed which contains information about "new stuff" whatever that new stuff is. This "new stuff" may actually be other XML-data which can be parseable and processable by other tools (like for instance new builds, deployments, whatever). This data probably has a format of sorts individually, independent of the RSS-feed itself, which has its own well defined format.

Now let's say both the RSS-feed and the custom-data contains both a "link" element and a "title" element. Without namespaces, these are bound to collide.

Some examples of problems which then arises:

- How can a RSS-library validate that the feed format itself is correct?

- How does a RSS-feed library know which "link" elements it should process and display, instead of only ones which belongs to the feed definition?

- How does the RSS-processing library know that it should most definitely ignore that title which belongs to the deployment metadata?

- Etc etc

Namespaces allows you to combine data from different formats without ever running the risk of the data getting mixed up by whoever consumes them.

It's a really basic feature, and it's at the core of the whole eXtensible bit of XML. I'm honestly surprised by both the amount of people who find this confusing and how few people are able to realize the value of such a simple construct.

I guess too many "1337 HTML ninja rockstars" got introduced to XML as "just another angle-bracket markup format" and never actually bothered to learn anything about absolutely foundational XML basics.


> Basic example: If you want to mix data from several formats in one document.

Can you get more concrete on why you would want to mix formats? So far what I have seen namespaces were used just to extend one format.

> Now let's say both the RSS-feed and the custom-data contains both a "link" element and a "title" element.

Easily avoided if you just extend one format, but can happen if you would want to mix existing formats because of some reason.

> - How can a RSS-library validate that the feed format itself is correct?

You still need some code that parses the non-RSS part anyway, which can validate it. Don't you usually have just one parser that parses RSS and the non-RSS at the same time? If not, how are you passing your non-RSS XML tree-parts from the RSS-only library to the "new stuff"?


> You still need some code that parses the non-RSS part anyway, which can validate it.

Provenly incorrect.

How many RSS validators validates the contained HTML (as HTML, not as per XML well-formedness)?


If you ever have to annotate one tree using a completely separate tool, you need to do something to ensure the names you choose are different from the ones used by whatever produces the tree. You can choose odd names, but there's no guarantee. Namespaces can provide that guarantee, via uniqueness of URIs, ultimately relying ICANN.


Almost certain this doesn't qualify as "nice", but: Namespaces make XSLT more powerful than one might think at first, because they allow you to write XSLT that generates XSLT (and so on...) by switching a namespace to a different one upon output generation.

Of course, the result is often barely readable anymore, so there's that.

Edit: On the other hand, the difference between XSLT-namespaced elements and all the others in a stylesheet is the one thing that makes basic XSLT readable, since you don't have to use a full meta-language just to create simple elements.


> XML has a bad reputation due to enterprise-y abuse of the technology, but that does't mean it's a fundamentally bad idea.

The fact that the Javascript-world is still copying XML-techcology and ideas which was formalized, standardized and ready for use over a decade ago, should pretty much be all the proof you need for that statement.

But hey. JSON is new and shiny!


Do you or Sir_Cmpwn have a small, real-world example of elegant XML namespace composition in the context of Wayland?

I didn't see XML namespaces used in the example given in the article, so I'm curious how Wayland leverages them.


Not to mention XML supports comments.


Oh, just put an object key named "//" with your comment as the value, and change the software to ignore such keys! /sarcasm

My rage over JSON not supporting comments grows every time I have to write some config file in it. Crockford tells you, "Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser."[0]... 99% of the usecases for JSON offer no way to insert a preprocessor into that pipe.

[0] https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...


It doesn't matter; it's just a machine readable protocol description.


Why?


Json il less verbose and is the de facto standard for the web, json is easier to parse by javascript (by the browser or node.js), and a serialization/deseriazation is unique, in xml you could put some infos on the attributes oand other on tags or as parameters. instead of <event name="gamma_size"> <arg name="size" type="uint"/> </event>

{"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" }


>Json il less verbose and is the de facto standard for the web, json is easier to parse by javascript (by the browser or node.js)

Wayland is not the web. None of these technologies are involved in Wayland.

>{"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" }

Your example is more verbose and harder to read... XML is definitely misused in many applications where JSON is appropriate but this is not one of them.


JSON has problems, but that's why we have TOML:

    [gamma_size]
    type = "event"
    args = [
       { name = "size", type = "uint" }
    ]
XML isn't what I would choose here because there's no need for text markup. TOML is both simpler and friendlier than XML in this case.

I do agree that it doesn't matter much.


We have TOML in the sense that TOML is currently v0.4.0 and bears an explicit warning that the specification is unstable should be treated accordingly.


That's unfortunate, but there are a lot of projects out there that depend on TOML, and it hasn't changed since 2015. It's de facto stable at this point.

The author has said as much: https://github.com/toml-lang/toml/issues/330


Wayland predates TOML, and I think TOML would be worse than XML for this use case.


I'd be happy to know your reasons why.

Overall, XML is too verbose; in particular, the text markup features of XML are needless complexity.


It's not. It's barely more verbose than JSON and a hell of a lot more readable. JSON is appropriate for machines to talk with. XML is appropriate for writing documentation or API specs.


Thanks for the insight. Some of the comments revealed why xml was picked. I personally agree that depending on the problem you must pick the right tools and what might be a good suit in a context it might not be the best fit in another. Moreover, there are probably more mature and performant parsing libs in c for xml than for json.

However, XML might be overkill as it might be too complex for this particular scenario. XML parsing it's complicated and from time to time there are bugs in those parsers. A simpler format might also get the job done and might be safer. However XML might provide flexibility to scale.

Finally, this is what Torvalds said about XML when someone suggested to use it in git:

> XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.


Relevant xkcd: https://xkcd.com/927


It's USB-C ;)




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

Search: