Wayland 1.18 Planned For Release Next Month

[phoronix]

Phoronix: Wayland 1.18 Planned For Release Next Month

Without seeing a new release of Wayland itself in nearly one year, a plan has been rolled out for having Wayland 1.18 in mid-February...

http://www.phoronix.com/scan.php?pag....18-Next-Month

[Nuc!eoN]

A zero output refresh rate for use-cases like virtual outputs

Stuff we had always wished for X11, great job!

[royce]

Good to see the sway / wlroots core devs involved in wayland directly. They've really been pushing the envelope on missing protocols to support actual desktop use cases, like layer shell. They have by far the best, most stable wayland implementations in the ecosystem.

[royce]

Weston is not used anywhere in the wild other than as a reference implementation. Mutter is behind wlroots / sway in terms of protocol support (wlroots / sway support a whole bunch of wlroots protocols proposed but not yet accepted into wayland), performance and stability. It's not mutter's fault, of course, since it needs to support X11 as well as a load of legacy features whereas wlroots / sway don't carry that baggage and benefit from a wayland only, clean design.

Edit: Kwin has the same problems, but is much later to the wayland party than mutter and that shows on just how glitchy it still is.

[royce]

I do not underestimate it, and I've said as much on my post above. I use both wayland compositors daily on non trivial setups (multiple displays of different scales, refresh rates and connection types) and wlroots / sway simply outperforms mutter on everything. Just to put you an example, mutter is unable to handle that set up above ([email protected] on edp, [email protected] on vga, [email protected] on hdmi) without frame rate drops or dpms issues.

[Britoid]

I do not underestimate it, and I've said as much on my post above. I use both wayland compositors daily on non trivial setups (multiple displays of different scales, refresh rates and connection types) and wlroots / sway simply outperforms mutter on everything. Just to put you an example, mutter is unable to handle that set up above ([email protected] on edp, [email protected] on vga, [email protected] on hdmi) without frame rate drops or dpms issues.

Mutter has some technical issues, especially when dealing with multiple displays.

I think the big issue (shared clock between multiple displays) should be fixed for 3.36. I'd like to see it fixed because this one affects me.

[royce]

Yeah, me too. Single display performance in gnome 3.34 is actually pretty decent, but as soon as you connect external displays it's a lagfest. Is it this ticket? https://gitlab.gnome.org/GNOME/mutter/issues/3

[Rexbron]

Wayland is broken at a fundamental level for color management. See Graham Gills efforts on the Wayland-dev mailing list. They just don't get it, and worse think the people who actually know what they are talking about are fools.

Sigh, any color critical work will stay on X11 or migrate to MacOS.

[Britoid]

Yeah, me too. Single display performance in gnome 3.34 is actually pretty decent, but as soon as you connect external displays it's a lagfest. Is it this ticket? https://gitlab.gnome.org/GNOME/mutter/issues/3

Yeh, that's the one.

[ascent12]

Wayland is broken at a fundamental level for color management. See Graham Gills efforts on the Wayland-dev mailing list. They just don't get it, and worse think the people who actually know what they are talking about are fools.

Sigh, any color critical work will stay on X11 or migrate to MacOS.

Feel free to contribute.

Colour management has been "neglected" because it's not the kind of expertise that Wayland compositor developers have, including myself. What we need and are waiting for are for some colour management experts to review the proposed protocol and improve to it.

It's just at the RFC phase at this point, with no real implementations. The protocol can still be entirely thrown out and changed; it's not "fundamentally broken".