Hacker News Reader

Comment by xvilka | Hacker News Reader

Would be interesting to know also the current status of Wayland development in NetBSD, since the last blog post about it was quite a while ago.

View on HN

I came to the conclusion a while back that Wayland just doesn't matter very much.

As long as Chromium and Firefox plus the GUI mode of Emacs works under X11, that is all 90% of users need/use.

I doubt it

I really, truly suspect Wayland is the future

We have had like one hundred X11 replacements between 1990 and now, and at least half a dozen have caught on with the open source community

What makes Wayland different is that it has attracted multiple vendors supporting it. Most notably IBM/Redhat, Intel, AMD, and, to a lesser extent, nVidia.

I am posting this message from an X11 environment, because I need X11 for a lot of things, home and work both, but, I can at least imagine a world where Wayland is the new default. That is not something I could say about the last hundred attempts to replace X11.

Edit: Again, this is just a suspicion. A notion. I neither hope for Wayland's success nor failure. I just keep my finger to the wind.

Wayland might be the future (though I'm personally a bit skeptical). It is already the default on many distros. At the same time, X11 is very unlikely to just stop working or disappear, since there's really no good reason to kill it.

My skepticism should be quite obvious: I am still posting through an X11 system.

But, Wayland is far and away the best and most serious attempt to replace X, ever, in thirty years and more.

If there is gonna be an X11 replacement, ever, Wayland is the most credible attempt in decades

Agreed that it’s made the best show of attempting, but Wayland’s only got about nine years before it’s as old as x11 (the protocol) was when the Wayland showed up.

If it’s gonna mostly displace x11… man, it’s sure taking its time.

It’s older than xfree86 was when the xorg fork occurred.

> If it’s gonna mostly displace x11… man, it’s sure taking its time.

Yes, and I'm fine waiting 5, 10, or 20 years. It's natural that such major shifts take a long time in an already mature ecosystem.

I'm also using X11, even though I've attempted to switch to Warplanes twice and had to switch back due to screen sharing and remote desktop being trash or just breaking after some update or other (most recently, browser). It's a work machine and I simply can't waste an hour fucking around with it. Aside from those issues which are deal-breakers in work, there's a bunch of minor annoyances I won't go into, thrust not deal brakes but they're "there". With X11 everything I need just works. I'm on a bleeding edge distro (OpenSUSE Tumbleweed) so I'll probably try it out on a weekend every few months to see if it's better. But in fairness I did that before, made the switch and then lost screen sharing after some random update...

Screen sharing was the final hurdle for me. I switched to running Slack in a Chrome tab and it works better than it ever did on X11 for me. I've used it on both my work computers for a few years now and it's been totally solid.

I've done screen sharing for years on X11.

Me too. But Wayland is just better for everyday use.

I will certainly switch when the things I use daily will work on wayland as well.

Tons of X11 infra will have to remain for a long time to support X11-only "legacy" apps that can't easily be updated. There's a long tail of that from games to scientific software to just unmaintained software that still works and is used.

The major bit will be when and if toolkits like GTK, Qt, SDL, etc. drop X11 support and applications update to X11-less versions. AFAIK there are no plans for that and is still years away (there was some talk about GTK 5, but nothing firm and no one even started work on GTK 5).

I also think Wayland will eventually replace all of X11, in the same way as IPv6 will eventually replace all of IPv4.

> Tons of X11 infra will have to remain

As XWayland. XWayland will be the new X.

Well, also libX11 and all of that type of stuff. And as I understand it XWayland shares a lot of code with the regular xserver (it's built from the same repo).

Yes, it just sits in a Wayland "container". So we can have security/fractionalScaling/modernMultiMonitor by default and X.oldness when required for that last bit of stubborn software.

What I mostly meant was that for people who prefer to use X11, that will probably remain viable for a long time, without any Wayland. There's this notion that X11 is "deprecated" and that "no one is maintaining it", but the reality of it is far more nuanced. The main "flag day" will probably be when toolkits start shifting away from X11 to Wayland only, and applications start using them (there's usually big lag between release and widespread adoption of new GTK versions and such).

Some qualified language in all of the above, because hard to predict the future etc. etc.

RedHat pushes hardest, they basically do GNOME, GNOME does GTK. So GTK will be first --my prediction-- to drop X11 support.

People that prefer X11 is not what I'd optimize for. To me X11 is deprecated, unmaintain{ed,able}. It became too much of a stumbling block for Linux and other opensource OSes. It's painful, but we have to move on. Wayland is not perfect but it seems to be doing the job lately. In two year --my prediction-- it will be more stable than X11 in all aspects.

> People that prefer X11 is not what I'd optimize for.

I wouldn't either, but that doesn't mean it won't work.

both Wayland and X11 are fairly stable AFAIK. For my part I'd rather not rewrite all my X11-specific stuff. For some I probably need to have direct compositor support as you can do less with scripts, so that's not so easy. I'll probably have to spend the effort at some point, but until I don't have to: why bother?

> What I mostly meant was that for people who prefer to use X11, that will probably remain viable for a long time, without any Wayland.

Or, if necessary, with just a tiny bit of Wayland; XWayland rootful mode lets you run a full X stack with Wayland as little more than a shim to the graphics driver. As a worked example, Puppy Linux implemented this: https://github.com/puppylinux-woof-CE/woof-CE/pull/2265

X11 will stop working if things stop supporting it.

Stuff might eventually decide to render directly to Wayland only APIs or something.

I'm actually not a very big Wayland fan, I prefer the single implementation model rather than all the different implementations of Wayland.

But I'd rather have just only the Wayland fragmentation mess, instead of the Wayland mess plus also X11, so I'm glad Pi OS and Ubuntu(Right now the only distros I pay much attention to) have switched.

Security is a good reason to kill it.

Well, the main reason why Wayland even exists is, that the X11 maintainers got fed up with a design from a time when graphics cards were not even a thing yet and decades of patchwork. They wanted to move on to something that has way less technical debt. Sure, X11 won't go away anytime soon, but finding people who actually want to work and maintain that codebase will be more than a little difficult.

This article is literally about a team that is actively maintaining the codebase

Likely the only team that isn't trying to spend all their time on wayland and touching x11 only when forced.

No, they mention that they work closely with the OpenBSD team, which maintains an explicit fork ("xenocara") that maintains the NetBSD ABI. It was OpenBSD that added wsdiplay and wsinput, which are frankly better in a lot of use cases than Wayland.

wayland's main purpose is to isolate ~~malware~~ proprietary software running in a container, which Xorg doesn't allow (unless of course you run nested servers).

It wouldn't be too bad of a goal if it had feature parity, which it still doesn't have.

X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.

Eh even if you secure the X11 API itself, the Xorg server still is a 33 year old (!) c codebase.

Linux is 33 years old as well. Let's stop using it to be secure?

Linux is not as secure as most tech people would assume at first glance. The monolithic kernel with all device drivers in ring0 is, let's just say, not the best approach if one were writing a new OS from scratch.

It is mostly "secure" due to it being used in practically every server and billions of devices, so there is an active maintainer community around it. Xorg has none of that.

It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.

There's nothing that forces a Wayland compositor to be written in C. I've seen ones written in C++, Zig, and Rust, but you could really use any language as long as you can still call the appropriate system/kernel APIs

Nothing preventing you from writing a X11 server in something else either (and people have done so!). But fact is, most wayland compositors right now are either pure C or C++ (and I think the rest uses at least wlroots?). Many X11 window managers are written in non-c languages too and I don't think I am too far off the mark when I say that a decent fraction of wayland compositors would just be external window managers if there existed a standardized interface for window managers when they were written (I think some compositors have an interface for external window managers now, but is there a standard interface by now?).

I far prefer one 33-year-old to four (and counting!) newer codebases that all try to do the same things slightly differently.

Eh, wlroots is in C. Tons of the Wayland stuff is in C. There's a bunch of good reasons to prefer Wayland, but this is probably the worst reason I've seen yet.

Wayland was started in 2008; the same year that Sun was already shipping Trusted Extensions for X11 that allowed per-window security controls.

Trusted Solaris 7 had shipped in 1999; 9 years BEFORE Wayland ever existed.

https://en.m.wikipedia.org/wiki/Solaris_Trusted_Extensions

I hope not.

The core wayland protocol have so many missing piece and many extension are not standardized nor well defined. This is basically killing the interoperability between UI toolkit for non-trivial cases.

Good enough for Gnome.

Well.... yeah? GNOME doesn't care about interoperability; they're the ones known for ex. suggesting that applications remove features for other desktops because GNOME doesn't use them ( https://trac.transmissionbt.com/ticket/3685#no1 ).

games, blender, audacity, gimp, mpv, eclipse, prusa slicer,...

IntelliJ IDEs.

They are working on it though:

https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland...

https://wiki.openjdk.org/display/wakefield/Known+problems+an...

If I use X11, I have to live with screen tearing, which Wayland doesn't suffer from.

Unless your application use GPU for rendering and you have more than one GPU involved, or have GPU driver that doesn't implicitly serialize events behind the scenes (as it should NOT), and your display stack has not yet migrated to experimental extension that patches Wayland with actual support for synchronized rendering (explicit sync).

If any of the above applies, tear-free behaviour is accidental, because Wayland protocol design fucked up synchronization primitives from day 1.

Could you expand on what is wrong with the synchronization primitives in Wayland protocol?

tl;dr the core protocol only lets you inform the compositor that the surface object is "ready" - which turns out to work effectively only for software drawing, or waiting possibly entire frame for your image to show up on screen.

That's if you're careful about calling "commit" on the surface only after whatever GPU draw calls you executed on it finished and the surface has been fully rendered to memory.

Turns out it somewhat works even if you're not properly careful because a lot of drivers (especially Mesa) had unspoken, implicit serialization happening in the drawing pipeline.

One issue is when you have more than one GPU (common on higher-end laptops). Even when you're rendering application surfaces on one GPU, they will often have to be synced to another GPU's memory to render them, because it's common to have some video outputs on iGPU and some on dGPU (example from my 2023 laptop: internal screen is behind mux that allows either GPU to exclusively write, but USB4 DP is iGPU exclusive, and separate USB-C DP is dGPU exclusive).

But with increased use of asynchronous rendering APIs (OpenGL AZDO patterns, Vulkan) and with variable refresh rate screens becoming more common (even if you don't have physical one, RDP/waypipe/etc are possible users for that) you can find out a situation where compositor will start drawing a window using a surface that is not yet fully rendered, bringing back tearing. It also means it's harder to properly utilize VRR in cases where applications render at different speeds (which is fine - not everything has to render at highest possible FPS), possibly locking you down to slowest rendering element.

So, the new extension, available if you ride latest patches on linux (the final part missing is new nvidia beta driver release, but not because nvidia lagged on the issue - nvidia apparently spearheaded it because their driver internals had no implicit synchronization), compositors are able to synchronize their rendering at the GPU level, getting fence objects for DRM buffer based surfaces. Meaning compositor can attempt to prevent drawing an unfinished surface, nor will application have to add extra waits in its display code.

Is there any definitive documentation regarding what causes X11 screen tearing? I've never seen it personally and most of the complaints I see on the internet are very vague.

I too have never actually seen this "tearing" despite being a Linux user for nearly 30 years. I am charitable enough to believe it is actually a thing, but somehow it has never impacted my life, so I'm kind of skeptical about arguments based on its alleged existence.

Reply on news.ycombinator.com