Hacker News Reader

Comment by AtlasBarfed | Hacker News Reader

How old is Wayland?

I'll be reading a dream of spring in my grave at this rate.

I understand I'm complaining about free things, but this is a forced change for the worse for so long. Wayland adoption should have been predicated on a near universal superiority in all input and display requirements.

Intel and AMD and Nvidia and Arm makers should be all in on a viable desktop Linux as a consortium. Governments should be doing the same because a secure Linux desktop is actually possible. It is the fastest path to showcasing their CPUs and 3d bling, advanced vector /computer hardware.

Wayland simply came at a time to further the delay of the Linux desktop, at a time when Windows was attempting to kill Windows with its horrid tiles and Apple staunchly refused a half billion in extra market cap by offering osx on general x86.

View on HN

Wayland is a protocol. The problems people complain about are generally implementation details specific to GNOME or KDE or (in general) one particular implementation.

There's rarely any such thing as "universal superiority", usually you're making a tradeoff. In the case of X vs Wayland it's usually latency vs. tearing. Personally I'm happy with Wayland because there was a time when watching certain videos with certain media players on Linux was incredibly painful because of how blatant and obtrusive the tearing was. Watching the same video under Wayland worked fine.

Early automobiles didn't have "universal superiority" to horses, but that wasn't an inhibitor to adoption.

I mean most of the things are the fault of a badly designed or non existent protocols:

-Problems with non western input systems

-Accessibility

-Remote control(took around 2 years to be stable I think?)

-Bad color management

Then there's the things that did work in x11 but not in wayland:

-Bad support for keymapping(the input library says keymapping should be implemented by the compositor, gnome says not in scope, so we have a regression)

-bad nvidia support for the first two years? three years?

While these things are compositor/hw vendor faults, the rush to use wayland and nearly every distro making it as default, forced major regressions and wayland kinda promised to improve the x11 based experience.

Yes, and to the parents point it was a CHANGE in protocol.

I get there was cruft in x. But the moment selected was a barrier to Linux desktop adoption precisely when the greatest opportunity in decades was present.

And the desktop was reimplemented.

Now in this period kde and gnome both decided to do rewrites, Ubuntu did their own desktop, got it up to snuff, and abandoned it. The lunacy wasn't just Wayland.

If we are complaining the gnome compositor sucks... I mean , should that be the goddamn reference implementation? What percent of desktops are gnome, 80% at least? If the gnome composting ready for primetime, then Wayland isn't ready for primetime.

>If the gnome composting ready for primetime, then Wayland isn't ready for primetime.

I use Sway, which uses a different compos[i]tor than Gnome. I would like to see similar results for wlroots, Sway's compositor, though I'm not actually interested enough to do the experiment (I guess that would be comparing Sway with i3). Cursor lag in Sway is not enough to bother me. I have on occasion used Gnome on the same machine(s), and never been bothered by lag.

As others have pointed out, Wayland is a protocol, not a compositor.

"As others have pointed out, Wayland is a protocol, not a compositor."

But the Wayland protocol requires a compositor, so here we are.

I have no idea of the difference(s) in performance between wlroots and Gnome's compositor. Protocols do not have performance, implementations do. If someone can prove that the Wayland protocol, on a certain set of tasks, and in a certain environment, has a better or worse performance than the X11 protocol, then it might be possible to make abstract comparisons on protocol.

Given that Gnome runs on both X and Wayland, it might be interesting to hear from the Gnome authors on the performance differences.

I have run Wayland since it was available for testing on Fedora Workstation and I have had zero problems inputting Japanese and Chinese.

With regards to accessibility, what problems have you had exactly?

> With regards to accessibility, what problems have you had exactly?

Fedora shipped a broken screen reader for 8 years.

Is there a bug report for this anywhere? Does everything work now?

I vaguely remember someone made a blog post about it and got piled-on. I think it's now fixed or being fixed.

Edit: Found it https://ar.al/2024/06/23/fedora-has-been-shipping-with-a-bro...

I think that gnome has had built-in IME, but at least for a long time, it wasn't possible to use a third party system with gnome, or use gnome's with other compositors. And I'm pretty sure the situation was the same for sreen readers and on-screen keyboards. The wlroots project created their own protocols to support external applications to provide such features, since that is out of scope for a compositor like sway, but there are still missing pieces.

2 finger scroll doesn't work on my thinkpad model.

Not a bug, apparently. https://gitlab.freedesktop.org/libinput/libinput/-/issues/10...

> I have had zero problems inputting Japanese and Chinese.

That may be fine.

Neo2 does not work. Neo has 3 modifier keys, Gnome/Mutter/Wayland/Whatever does only support two. Neo2 has a compose key, Wayland does not honor it.

https://neo-layout.org/

I use mod4 for navigation (arrow keys, site up) and compose for Slavish (read Polish) input (źżąę)

> the rush to use wayland and nearly every distro making it as default,

Which rush? It has been done by only a small fraction of distros like Fedora, after years of development of the first wayland compositors. Fedora main purpose has always been to implement bleeding edge tech stuff early so that bugs get found and fixed before people using more stable distros have to suffer from it.

Nobody has been forced in any regression and x11 has continued to be available until now and there is no sign that the most conservative distros will drop x11 support anytime soon.

Nvidia support is still poor (at least on latest cards), I'm forced to use X or I get tons of glitches. I need the proprietary drivers for machine learning.

Not that I mind particularly, X is fine and everything works as expected. I can even have the integrated (amd gpu) take care of the desktop while the Nvidia gpu does machine learning (I need all the vram I can get, the desktop alone would be 100-150mb of vram) - then I start a game on steam and the nvidia gpu gets used.

Funnily enough I had wayland enabled by default when I installed the system and I didn't understand why I was getting random freeze and artifacts for weeks. Then I realized I was not using X11

Isn't this an issue with Nvidia not releasing open source drivers ?

nvidia has been great on wayland since 550; Everyone running CachyOS is on 570 now

I've used Wayland on Fedora for 16 years. Had to disable Nvidia GPU on laptop And use Intel GPU for first 11 years. Now have been using AMD GPU smoothly for 5 years. But I hear Nvidia is slowly getting back on the game. Let's hope they get stable support less than 20 years of wayland being in use on major desktop Linux distros.

> Wayland is a protocol. The problems people complain about are generally implementation details specific to GNOME or KDE or (in general) one particular implementation.

I feel like at some point this is a cop-out. Wayland is a protocol but its also a "system" involving many components. If the product as a whole doesn't work well then its still a failure regardless of which component's fault it is.

Its a little like responding to someone saying we haven't reached the year of linux on the desktop by saying: well actually linux is just the kernel and its been ready for the desktop for ages. Technically true but also missing the point.

Wayland. Solving yesterday's problems, tomorrow.

unlike x which couldn't solve yesterdays problems.

X is fine, most of the problems people bring up are niche and minor. Meanwhile, Wayland induces problems of its own, like breaking all sorts of accessibility systems and multi-window X applications with no solution in sight.

    > multi-window X applications

I believe you. Can you share an example? To be clear, I'm pretty sure this can be done with Gtk and Qt, but maybe you are talking about older apps written directly in Xlib or Xt?

It's not the toolkit (as they work on X11 and other OSes with the existing toolkits), it's Wayland that's the issue (there are a series of Wayland protocols to implement this, but they are being blocked).

To be fair this wayland issue is also niche. Author of the linked article wrote that this is reported by really small percentage of users most of the people do not notice it.

What components? Wayland is literally an XML protocol that turns an XML file into a method of communication. libwayland-server and libwayland-client only handle communication and the internal event loop. Its completely up to the developer to write the implementations of these functions and register them in the server.

Then a client is going to query the server and ask request to do stuff via a unix socket. In fact, you don't even need libwayland, you can raw dog it over sockets manually. The idea is that there are standard protocols that can be queried and used,and you can implement this in any environment you want to. You could write the "frontend" in html and JS and run a wayland compositor on the web (which has been done [1]), you could do it with text or anything really, most people use some graphics stack.

[1] https://github.com/udevbe/greenfield

Nit: Wayland isn't an XML protocol. The "calls" and their arguments are described in XML, but the data is transmitted in a fairly simple binary encoding.

The components are:

- the compositor, of which there are multiple implementations (gnome, kde, all the wlroots compositors)

- the client, which often uses one of several toolkits (gtk, qt, several smaller frameworks, or even directly using the protocol)

- the wayland protocol (or rather protocols, because there are several extensions) itself

- other specifications and side channels for communication, in particular dbus.

Many issues (although I don't think the one in OP) are due to the protocol being underspecified, and so the client and compositor disagree about some semantics, or doesn't even have a standard way to accomplish something across all compositors.

The key detail in the “Wayland is a protocol” is that there are several other implementations, some of them extremely mature. The implementation being tested here isn’t exactly know to be a good one.

If there were a single Wayland implementation in existence, I’d agree with your sentiment.

It's the implementation backed by Red Hat, which is probably the largest company in the Linux graphics space and the one employing the most experts.

It's also the implementation most unsuspecting users will end up with.

The author was using Gnome, which is meant to be the most mature Wayland implementation given its developed by Redhat which is also the same company that is the biggest driver of Wayland protocol.

"Wayland is a protocol" is exactly the problem. Protocols suck; they just mean multiplying the possibility of bugs. A standard implementation is far more valuable any day.

With X11, it was simple: everybody used Xfree86 (or eventually the Xorg fork, but forks are not reimplementations) and libX11 (later libxcb was shimmed underneath with careful planning). The WM was bespoke, but it was small, nonintrusive, and out of the critical path, so bugs in it were neither numerous nor disastrous.

But today, with Wayland, there is no plan. And there is no limit to the bugs, which must get patched time and time again every time they are implemented.

X had garbage handling of multiple monitors and especially multiple monitors with different DPIs, and there was "no plan" to deal with that either. Nobody wanted to work on the X codebase anymore. The architecture bore no resemblance to the way any other part of the desktop stack (or hardware) works.

Most of the garbage aspect is because toolkits refuse to support multiple monitors on DPI with X11 with the argument that "Wayland is just around the corner", for decades now.

For example Qt does per-monitor DPI just fine on X11; it's just that the way to specify/override the DPI values just sucks (an environment variable).

This stupid decision is going to chase us until the end of times since Xwayland will have no standardized way to tell its clients about per-display DPI.

It's not useful if you have to specify a scaling factor before the application has started, when the application can move monitors.

This is something feasible on Wayland, X draws one large wide screen display.

Yes. It just proves that all you needed is a better way to specify the per-monitor DPI, one that can be updated afterwards, or even set by the WM on windows.

X11 used to provide separate displays, but at some point due to hardware changes (and quite probably due to prominence of intel hardware, actually) it was changed to merged framebuffer with virtual cut out displays.

In a way, Wayland in this case developed a solution for issue its creators brought into this world first

It can still provide seperate displays. The problem is you couldn't do something like drag a window from display 1 to 2°. IIRC it's also annoying to launch two instances of a program on both displays. The hacky merged framebuffer thing is a workaround to these problems. But you can have independent DPIs on each display.

° For most programs.

Yeah there were certainly tradeoffs. It's much harder to use separate displays now, though - last time I tried, I could address the two displays individually (":0.0" and ":0.1") if I launched X on its own, but something (maybe the display manager?) was merging them into a single virtual display (":0") as soon as I tried to use an actual desktop environment. (This was was Mint 20, MATE edition, a few years ago - I gave up and reverted to a single-monitor setup at that point.)

X could do seveal different screens I did have this working once. However then moving an application to a different display was impossible (an app could do it but it was a lot of work so nobody bothered). I few cad programs supported two streens but they were seperate and the two didn't meet.

Most people want to drag windown between screens and sometimes even split down the middle. One large display supports that much easier so that is what everyone switched to in the late 1990

I was using it that way until about 2020. (Mint 13 MATE supported, but it seems that capability was lost somewhere along the line. Shame, because I have a dual monitor setup where the second monitor is often displaying the picture from a different device, so in that situation I absolutely cannot have applications deciding to open on the busy-elsewhere screen. I miss being able to set a movie running on one monitor and have it not disappear if I flipped virtual desktops on the other!)

Yes, separate screens would be a much better model for me as well. Much better than KDE randomly deciding to show KRunner on the turned off TV for some reason unless I manually disable the output.

X11 does a lot of things that are outdated now, and multiple independent screens is one of them. Ideally, you'd be able to select either independent screens or one big virtual screen, and still have a window manager be able to move windows between independent screens. I don't know how that would be achieved though.

X's "mechanism, not policy" has proven to be a failure. Without a consistent policy you end up with a pile of things that don't work together. "One big virtual screen" is a policy and it's one that works well enough.

Deciding what needs to be in the protocol and what should be in the application is never easy. It's important to be able to iterate quickly and avoid locking in bad practices. I think that's what Wayland tried to do by making everything a fine-grained extension, but it doesn't really work like that as the extensions become mandatory in practice.

> It's not useful if you have to specify a scaling factor before the application has started, when the application can move monitors.

Windows does this. Try to use in Windows 2 monitors with 2 different scalling factors. It is hit or miss. 100 and 150 works. 100 and 125 doesn't.

For the record: you can specify a different DPI _for each monitor_ for Qt X11. You just cannot change it after the program has started, which is exactly the limitation I was referring to.

But you can definitely move windows to another monitor and Qt will use the right DPI for it. It is the same behavior as Wayland. "One large wide screen display" is exactly how Wayland works...

This is not "just fine" in my book: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input...

>Nobody wanted to work on the X codebase anymore.

That, i think, is the main issue. Nobody wants to work with GTK1, or GTK2, or GTK3 anymore. Nobody wants to work with QT1, or QT2, or QT3 or QT4 anymore. Everybody wants the new shiny toy. Over and over again.

It is CADT all over. Earlier X was developed by an industry consortium. Now Wayland is a monopoly pushed by RedHat.

> Now Wayland is a monopoly pushed by RedHat.

Pushed but still it seems it flails and takes too long to do the basic stuff

RedHat is still mostly a server side company isn't it?

Can we trust them to "care" about desktops?

Oh wait. There is no more RedHat. There is IBM.

They care about applicances and phone-likes. Which is what Wayland is geared towards. Desktop is just there to do the free testing for them.

Exactly, same situation as with audio. Instead of improving the OSS API we got ALSA, PulseAudio, and now PipeWire (and a bunch of less mainstream alternatives) -- all with their own weird issues. And of course it's application (or at least toolkit) developers that bear the cost of this churn, not the developers that get to work on their fancy new NIH tech that they'll then abandon before being 100% stable for yet another reimplementation.

Software has bugs and water is wet. Wait til you hear about HTTP, TCP, UDP, IP torrents, etc... and "simple" is not really a term I would designate to X11. I mean, its fine, but even just the ecosystem surrounding X is convoluted, outdated and absurd. Things like xinit, startx, .Xauthority, xresources, xhost etc... are all a mess.

> there was a time when watching certain videos with certain media players on Linux was incredibly painful because of how blatant and obtrusive the tearing was

It was because of the crap LCD monitors (5 to 20 ms GtG) and how they are driven. The problem persists today. The (Wayland) solution was to render and display a complete frame at a time without taking into account the timings involved in hardware (you always have a good static image, but you have to wait).

I tried Tails (comes with some Wayland compositor) on a laptop. The GUI performance was terrible with only a Tor browser open and one tab.

If you do not care about hardware, you will, sooner or later, run into problems. Not everybody has your shiny 240 Hz monitor.

Tearing hasn't been a thing under X.Org for me since the introduction of Option "TearFree".

> How old is Wayland?

About 16 years old, for comparison, X is 40.

Hm, X works fine since 20 years. Wayland is still a protocol after 16. /s

> Wayland adoption should have been predicated on a near universal superiority in all input and display requirements.

Totally agree. The people saying "Wayland is a protocol" miss the point. Wayland is a protocol, but Wayland adoption means implementing stuff that uses that protocol, and then pushing it onto users.

Measure twice, cut once. Look before you leap. All that kind of thing. Get it working FIRST, then release it.

You have to releaseethings like this in parts because it needs too many external people to do things to make it useful. Managing those parts is something nobody has figured out and so people live you end up using it before it is ready for your use and then complaining.

When I say "release" I mean "release to users". You can release stuff to other developers, no problem. But it should all come with large warnings saying "This is not for daily use". The failure is when distros like Fedora start not only shipping it, but then saying they're going to drop the working alternative before Wayland is actually ready to do everything that X does.

(Also, I don't use Wayland. I mean I tried it out but don't see any real benefit so I don't use it regularly.)

> You have to releaseethings like this in parts because it needs too many external people to do things to make it useful.

30 years ago X came with a server and some clients. Why it is so hard to do this, for wayland, today ?

This would be best solved by maintaining support for old protocols instead of reinventing the wheel. There is no chicken/egg problem when you have proper backwards compatibility.

> Wayland simply came at a time to further the delay of the Linux desktop

I can't tell if you are serious or not.

Serious

I don’t really agree, because I think there’s something of a chicken-and-egg effect here.

With complex projects like these that have to work well on such a wide array of hardware and configurations, lots of real world usage is required to achieve any level of refinement. Without widespread adoption, Wayland likely would have been stuck in experimental/toy status for much longer than it will as things are going currently.

>How old is Wayland?

This argument don't make sense because Wayland started as a hobby and not to replace x11, was after it got traction, other people/companies started contributing that it matter

>but this is a forced change for the worse for so long

Can you explain who is forced to do what in that context?

AMD states that bugs only get fixed for Wayland.

Coincidentally I have got a graphics driver that likes crashing on OpenGL (AMD Ryzen 7 7840U w/ Radeon 780M Graphics)

You're arguing against Wayland, but for a more secure Linux desktop? I recommend you spend more time getting to know the X11 protocol then, because it has plenty of design decisions that simply cannot be secured. The same people who used to develop XFree86 designed Wayland to fix things that could not be fixed in the scope of X11.

> the X11 protocol [...] has plenty of design decisions that simply cannot be secured.

I've been hearing this for over a decade now. I don't get it. Just because xorg currently makes different clients aware of each other and broadcasts keypresses and mouse movements to all clients and allows screen capturing doesn't mean it has to. You could essentially give every application the impression that they are the only thing running.

It might seem difficult to implement, but compare it to the effort that has gone into wayland across the whole ecosystem. Maybe that was the point - motivating people to work on X was too difficult, and the wayland approach manages to diffuse the work out to more people.

I was really bullish on Wayland 10 years ago. Not so much any more. In retrospect it seems like a failure in technical leadership.

X always had the capability to isolate clients, but it is not used it would need some work which nobody does because of Wayland.

Some aspects of the client isolation are used by default when doing X11 forwarding via SSH. A remote keylogger will not work for instance.

It'll be challenging to even figure out which one of the things connecting to $DISPLAY is the real window manager. Good luck on your lonely[1] journey!

[1]: The people who actually developed Xorg are now working on various Wayland-related things.

> It'll be challenging to even figure out which one of the things connecting to $DISPLAY is the real window manager.

I suspect it would be less challenging than writing a whole new wayland server.

Off the top of my head, I'd use a separate abstract domain socket for the window manager including some UUID, and then pass that to the window manager when launching it.

You could create these sockets on demand - one for each security context. On linux typically a different security contexts will either have different UIDs - in which case filesystem permissions would be sufficient - or they have different mount namespaces - in which case you make different sockets visible in different namespaces.

For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients.

> Good luck on your lonely[1] journey! > > [1]: The people who actually developed Xorg are now working on various Wayland-related things.

This is what I mean by a failure of technical leadership.

"You could create these sockets on demand - one for each security context. On linux typically a different security contexts will either have different UIDs - in which case filesystem permissions would be sufficient - or they have different mount namespaces - in which case you make different sockets visible in different namespaces."

This is reminiscent of how Trusted Solaris[0] implements Mandatory Access Control (MAC) a la Orange Book[1].

[0] https://www.oracle.com/technetwork/server-storage/solaris10/... [1] https://public.milcyber.org/activities/magazine/articles/202...

> For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients.

SSH pretty much already does this. Per default (using -X) X11 forwarding is in untrusted mode, which makes certain unsafe X11 extensions unavailable. So remote clients already cannot snoop the whole keyboard input.

> Off the top of my head, I'd use a separate abstract domain socket for the window manager including some UUID, and then pass that to the window manager when launching it.

And then the window manager spawns whatever programs the user wants, and they end up sharing that $DISPLAY.

I'm not trying to claim that X is secure as is. The claim I'm making is:

1. There is nothing fundamentally insecure about the design of X that couldn't be fixed with a bit of effort.

2. The effort required would be significantly less than what has gone into Wayland over the last 16 years.

Fixing the security of the system certainly would involve changes to more than just xorg. Anywhere there is a security boundary you'd need to make modifications - but that's OK, most of these security boundaries are younger than wayland anyway.

This discussion of $DISPLAY seems like distracting minutiae. Sure it's a medium size problem that would need solving, but that's all it is.

To address your specific point: it could be the responsibility of the window manager to set $DISPLAY to a less powerful socket when starting processes. Ultimately it doesn't matter though, because if the display server isn't doing some sort of sandboxing then the spawned process can just ptrace xorg and do whatever it wants. X being secure only matters in the presence of a security boundary and in that case it would be the responsibility of whatever is setting up that boundary to create a less privileged socket. Whether that be ssh or flatpak or whatever.

So now we've reached the point of "you could secure X11 if you changed everything". Sure, fine.

Once again, for emphasis: nobody has stepped up to do that, in the history of X (outside of proprietary products, of unknown quality).

Wayland is not some outsider project competing against X11. It's the people who were developing Xorg, saying they're fed up with X11 and need a clean slate to fix its problems.

Here's my unpriviledged user trying to ptrace my Wayland compositor running as me:

    strace --syscall-limit=1 -p 697351
    strace: attach: ptrace(PTRACE_SEIZE, 697351): Operation not permitted

Nearby, I have a Chromebook where a potentially hostile virtual machine can display Wayland windows seamlessly on the host. The worst the VM can do is fill bitmaps with offensive imagery.

In a world where the people doing the work switched to developing the Wayland ecosystem, arguing about a "could" that requires changing every window manager seems like a guarantee X11 will not get improved. Feel free to put effort into it...

> You could essentially give every application the impression that they are the only thing running.

> It might seem difficult to implement

This is exactly what OS did (my daily driver): https://forum.qubes-os.org/t/inter-vm-keyboard-isolation/315...

> I understand I'm complaining about free things, but this is a forced change for the worse for so long.

Then write code.

Asahi Lina has demonstrated that a single person can write the appropriate shims to make things work.

Vulkan being effectively universally available on all the Linux graphics cards means that you have the hardest layer of abstraction to the GPU taken care of.

A single or small number of people could write a layer that sits above Wayland and X11 and does it right. However, no one has.

Reply on news.ycombinator.com