Hacker News Reader

Comment by dijit | Hacker News Reader

Fractional scaling is kind of the most visible thing today. But to be clear, there’s a lot of benefits to wayland.

Mostly the issues could be hacked around. But let’s be absolutely clear with this: it is hacking around the issue.

Problem: tearing, solvable with double buffering, maybe.

Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.

Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program. Solvable by running a mini X11 instance for each program.

Problem: Xorg is a network system, meaning it is very inefficient. (Imagine using TCP to talk to your SSD)

Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features. Especially as the client may not be on the same machine as the server.

Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.

View on HN

I’d like to emphasize a major aspect that makes the switch a non-brainer: SECURITY.

The “good old days” of unencrypted Internet, where everyone could see your cookies, are no longer acceptable; the same is true of X11.

With X11, if you copy a password from your manager, you must assume all running apps now know it and transmitted it to a malicious server. There’s no way to tell.

With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.

With X11, everything displayed on the screen is compromised. Also, all inputs, keyboard and otherwise.

With Wayland, each app only sees their own pixels.

With X11, screen locking is pure hackery that doesn’t always protect the locked pixels and… login password.

Traditionally, you are meant to trust that process boundaries on Linux are sacredly secure, which is why Spectre was a big deal. But in practice, that is only true under Wayland.

X11 is also just a protocol and you can implement it securely and expose access control through extensions. In fact it already exists (XACE) just nobody is using it.

Exactly! It astonishes me that Wayland folks think that replacing the whole graphics stack is somehow easier than using an X extension that already exists. Really speaks to the profound immaturity of the project.

My god, those "wayland folks" were the same people developing X. They were not some unrelated people pushing an agenda. It's always fascinating to see all the arm chair experts saying things how things ought to be done without ever having written a X extension or anything of that sort.

So the fact that someone was a developer of X, means their resilient to following some agenda or non objective opinion? There's a really famous and often quoted talk about X vs Wayland from one of those developers and it was clearly made in a way to present Wayland in a better light by purposely portraying X11 in a bad way, for example by leaving out crucial details. Like in one example they picked on the slow startup time of applications and attributed it to the blocking calls made to X.org, without even mentioning that asynchronous alternatives are not only available, but toolkits like Qt were already using them exclusively at that time. The verdict of course was that X11 is broken and fixing that is almost impossible.

X11 was designed to everything like OS, it's display server, gui library, font manager, printing server and more, X11 was ment to be like qt or gtk, you tell it that you want to display input and it will draw it for you, the issue now it that basically every app now display every window as one bitmap, because we do not want to use 98% of the x11. Also why do you think there wasn't much development activity in X for years now? There is so much wrong with it's state that nobody wants to work with it. It's like talking: why someone would like to use rust or go or c# when we have cobol? why not just write cobol extension?

I'm not really sure what you're getting at. Like I never said there's no point in using or developing Wayland. I was addressing the statement, that Wayland was build by former X11 developers, which supposedly makes them purely objective authorities. Of course, that's not the case as, can be seen by the example I gave.

No, you're arguing a strawman. What I'm saying is, if you have never even tried writing an X extension, likely never properly looked at the X protocol (let alone it's implementation) you have no leg to stand on to make technical criticism of the people who did the work and then decided it was too much work and build something else.

And, have you written a Wayland extension and a X11 extension and learned the difference? No? Then why should we listen to you?

There isn't really much difference. It's about the same amount of work either way to ship an extension.

In Wayland, you make the extension, then you patch every compositor, every toolkit and every application.

In X11, you make the extension, then you patch the X server, Xlib, XCB, every window manager, every toolkit, and every application.

The question was related to the relative difficulty of replacing the whole graphics stack vs. patching in support for an X extension that has existed for longer than Wayland. One of these things is far, far less work than the other.

As someone who has done both, I respectfully disagree.

I call bullshit. If you had done so, you would have shared links to them to prove your point.

There's no code I can show you that would be any more convincing than just looking at the code to the X server and then looking at the code to any wayland implementation. There's not anything particularly special about these projects.

XACE is basically an extension of SELinux into userspace for X11. Given that today Fedora/RHEL are the only distros that enable SELinux out of the box, such an approach would have been doomed to failure (or doomed to provide a product differentiator for RHEL in the best case) - not to mention the sheer joy and excitement that debugging SELinux AVC denials would produce for end users and desktop application developers.

https://www.freedesktop.org/software/XDevConf/x-security-wal...

“With X11, everything displayed on the screen is compromised. Also, all inputs, keyboard and otherwise.

”With Wayland, each app only sees their own pixels.”

Out of curiosity, if this is true, how are screenshots / screen recorders implemented? Do they require some special permissions? And if this is the case, why wouldn’t any app be able to acquire these special permissions?

This is currently why a lot of people are complaining screen recorders do not work.

There are solutions to this, which allow finer grained access to screen recording in future, but there are a couple of competing standards right now.

> With X11, if you copy a password from your manager, you must assume all running apps now know it and transmitted it to a malicious server. There’s no way to tell.

With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.

Can you elaborate?

This sounds implausible, wishful thinking since key bindings are managed by individual applications. Whoever holds the clipboard must trust the application that claims to have received a paste command from the user. I don't see anything that could prevent spoofing without just blocking clipboard access entirely or making the usability a lot worse.

In X11, every client is equal.

In Wayland, the compositor has special standing. For instance, KWin will only allow the currently active window to paste.

There is more information here: https://phabricator.kde.org/T4449#192501

Leaving aside for the moment that this policy is only a partial protection against a malicious client, the same policy could well be implemented in X11. (The window manager is not fully equal.)

At a meta level, this is probably the most frustrating thing about Wayland: all of its benefits could be realized in the X context itself, even the getting rid of legacy baggage (deprecate parts of the protocol leading up to the definition of an X12).

People actively chose not to do this and instead delayed progress by at least a decade.

Ideally, Wayland would have just served as a tech demo to guide the evolution of X. But as a community, we give too much credit to people working on shiny new things.

X12 is simply called Wayland.

Again, long time Linux user and this really doesn't tell me why Wayland is good, it tells me that the Linux ecosystem is getting frog-boiled into accepting the same sort of frightfully dumb practices that the other operating systems have been doing for years? How did we get to a place where I have to pit the security of some of my apps against other apps?

You said Xorg is a network system twice and I don't think you did enough research once. Wherein client and server are local it doesn't doesn't communicate via the network stack. The problem you imagine exists only in your imagination not reality.

I don't care if xorg runs as root and I don't need to run an instance of xorg per application I simply install software from trusted sources and haven't managed to get malware between 2003 and now. I also didn't have issues with tearing in 2003 and I don't now.

Generally speaking QT and GTK and other toolkits must concern themselves with the details of X others concern themselves with QT or GTK as they would under wayland. It is extremely likely that all players in the overall ecosystem who never had to specifically worry about X in many years have had more issues, work, and tears from wayland development than they would have had for the remainder of the next century with X.

This is nearly entirely about presenting a saner stable base to improve the work for a tiny number of people actually developing the graphics stack in Linux to build upon and unfortunately they made poor design decisions at the start that have led to it taking 12 years and still not being ready for prime time in some ways.

After doing the necessary research to understand the topic you could construct another post about the shortcomings of X that is actually factually correct but it would still be beside the point. Wayland would still be a poor work that squandered a lot of the opportunity of a clean slate despite its authors being in perhaps the best position possible to do so. In 20 years Linux if it exists on the desktop will be a weird opaque overengineered system that works when it works and is impossible for an end user to understand why it is misbehaving when it doesn't.

On the bright side due to package management the windows solution of pave over the install and start over could probably be configured to automatically reinstall all your software for you!

After a few years of wondering about the "why," I find this comment very illustrating; it feels like Wayland is one of many Linux related efforts (like Gnome and KDE) that are not particularly interested in a high level of interoperability and/or long term durability. Instead, the goal is more in the direction of trying to make their preferred way of things more dominant in the ecosystem. Now, if those efforts are actually good at it then more power to them. But most of the time, that doesn't happen, and I think it harms the Linux ecosystem, one that I am a fan of, overall.

How does it harm the ecosystem to place the fundamental abstraction of the goddamn DISPLAY server over something that actually was created after GPUs was a thing?

The X server is maxed out, or as a core maintainer said, you can only apply this many lipstick to a pig. It is fundamentally broken. But the X api is not, it will be supported forever in terms of XWayland. Which is a net win, we get proper graphics, and apps will be backward compatible.

> It is fundamentally broken.

The Wayland developers disagree with you:

https://wayland.freedesktop.org/faq.html#heading_toc_j_5

"It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X."

They themselves say they could have fixed X. They just didn't want to. And now they've predictably just made a new mess.

https://www.youtube.com/watch?v=GWQh_DmDLKQ

Just watch it.

Did you watch and understand it? This presentation is nothing but a highly one-sided and subjective talk, which gladly bends the truth or leaves out crucial details to get a good laugh from the audience.

Take the whole part about "X terrible IPC" and slow startup time as an example. It's portrayed as if slow startup time is an inherent flaw of X due to blocking IPC calls. However he forgot to mention, that non-blocking calls had been there for years and big projects like Qt were using them exclusively instead of the blocking Xlib calls. Then he goes on to say that Chromium's startup time is so slow because at minimum it waits half a second for replies from the X server. So let's get some current numbers on a T420s for starting up Chromium and immediately closing it:

  Weston + Chromium (Wayland mode): 731.3 ms ±  39.4 ms
  Sway + Chromium (Wayland mode): 688.2 ms ±  22.7 ms
  Sway + Chromium (XWayland): 667.2 ms ±  16.6 ms
  X.org + i3 + Chromium: 661.3ms ±  17.2 ms

I was actually surprised to see how little difference there is, if there's any at all.

So either his numbers don't apply anymore and X.org is not a bottleneck anymore, or Wayland became a similar bottleneck, or his numbers never made sense in the first place, especially since he never bechmarked the Wayland part.

Edit: On GNOME Shell Chromium also starts slightly faster with X.org with 0.6 - 0.7s and > 0.7s in Wayland mode.

*updated benchmark results with the actual results from hyperfine (10 runs each)

The video is quite old. And I think you should add a compositor on top of i3 to measure the same thing.

The whole point of the talk was that when a compositor is used (which should absolutely be used because with increasing resolutions tearing will just get more visible), X has pretty much a useless role in the whole situation. That is, you’ve got yourself an architectural problem. Which is no surprise, X had been here forever. But maybe it should no longer the be the abstraction we build our graphics on.

With X.org + i3 + picom (GLX backend, animations and vsync enabled) I get: 665.8 ms ± 19.3 ms

So it doesn't seem to have any significant influence either.

Thanks for benchmarking, but as I mentioned, this was/is not a significant problem that would give way for Wayland. What I wrote in the second part of my comment is.

The problem with X11 was never that you can't add things to it, the problem is that you can't remove things from it.

First, this isn't true - watch the youtube the other person in this thread put where he tells a story about how they deleting about 1/3 of the code (15:19), but secondly even if they didn't, why is that a problem?

Breaking user's applications isn't actually a virtue.

If you have enough permissions to intercept keystrokes in X via network monitoring then most likely you have enough permissions to intercept keystrokes in wayland e.g. by ptrace.

You're not using TCP for local X, it's all Unix domain sockets and SHM. Hard to get any faster on Linux.

One could certainly implement feature emulation to preserve backward compatibility with evolving hardware. Or just deprecate feature, X over network was pretty much broken for a long time.

Not saying Wayland isn't an improvement over X but a lot of supposed limitations of X are often misrepresented and exaggerated.

Also, all the other “problems” with X have been solved for years. (No tearing, no root X1q on my box, in particular)

I very much agree with what you wrote. I'll just add a comment:

> Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.

This may seem like it's irrelevant for the user. It isn't. Lots of things us users want are much easier and more attractive for developers to add to the clean slate design that is Wayland.

For example: When I switched, an unexpected bonus I experienced was that my touchpad's behavior got orders of magnitude better. So I googled around a bit, and it turns out that almost all touchpad improvements just happen to occur on Wayland because the people who are interested in that aren't interested in wading through the X swamp in order to implement their stuff. (I mean, have you looked at the X code? Oh dear, oh dear, it's a daunting thing!)

> This may seem like it's irrelevant for the user. It isn't. Lots of things us users want are much easier and more attractive for developers to add to the clean slate design that is Wayland.

This is something I don't understand about Wayland. How is it possible that something that is supposed to be much easier and more attractive for developers after TEN+ years of development still has so many issues ?

On the other hand, a bunch of X11 issues were just listed, and X has existed three times as long. Some issues are architectural and thus probably not solvable, some are just persistent annoyances that must be difficult to fix and likely will not get fixed because X11 has so little active development anymore. X has enough issues that a good portion of the community said, "we've got to fix this". And frankly, I've used software from multi-billion dollar corporations that gives me more trouble in a day than Wayland does in a month.

The protocol had been in development for that long, most compositors for a few years, and clients change their implementation up to their own schedule.

I see it as a “failing” of the bazaar way of development, linux can’t just say we now use this API. So there is an inherent not enough user on the new API to bother porting, and due to not enough user it is not as streamlined/stable, and you have a vicious circle. But I have to say the issues with wayland are heavily overstated, and I think it is out of this cycle, and is getting quite a bit of steam.

Just a note: It is due to libinput, which as far as I know can be used with X as well, but I haven’t personally done so.

Libinput is not a Wayland thing, and it's actually the recommended solution on X11.

> Xorg is a network system, meaning it is very inefficient. (Imagine using TCP to talk to your SSD)

I am quite sure that there is something wrong with your system if your X clients run through the IP stack by default.

So, I see and understand these arguments in theory -- but, and I don't think I'm alone, none of them are actually pressing?

I'm running Openbox/Xubuntu on a 4K monitor, doing some awesome equivalent-of-4-monitors work, then playing all the steam games I want with the Proton and the decent AMD GPU, all under X. "Font size is a little weird sometimes" is my only gripe?

Put differently, I understand "hacking around the issue" criticism in theory -- but if you applied that sort of purity to, say, web programming -- step one would be, okay, first get rid of Javascript, an idea that I really do like in theory, but I know it's not happening.

I find it personally a bit hilarious - Wayland has been Going To Be Great Soon for over a decade.

I've never even had a reason to want to run it.

But I'm sure it'll be great, any day now.

I find Wayland is great already for my usage, and has been for the last two years. If Xorg works for you and Wayland doesn't, that's perfectly fine too.

Don't get me wrong - I would love to not deal with certain X warts. (I see substantially fewer warts than other people do, but that's just me.)

It just seems Wayland's combination of technical requirements and political entanglements make it a sort of Zeno's Project, doomed to asymptotically approach peoples' expectations and desires, but never reach them.

>I find it personally a bit hilarious - Wayland has been Going To Be Great Soon for over a decade.

So? The same has been the case for desktop Linux in general, for 2 decades.

> So? The same has been the case for desktop Linux in general, for 2 decades.

Some of us have been running Linux desktops for over two decades. Nothing more fun than setting Modelines manually for your VESA card:

* https://en.wikipedia.org/wiki/XFree86_Modeline

My Gentoo/Xfce multiple monitors with Nvidia has been great for at least 10 years.

Linux Desktop is Great. Wayland is still in the process of becoming great (I think it's making good progress too)

Linux desktop has been perfectly fine for at least 1.5 of those decades.

Desktop linux actually worked pretty well in 2003 for my purposes. I started on Fedora Core 1. I burned a dvd hit the magic key to select a boot target booted it up told the installer what time zone I was in and what disks it could use and such details and rebooted after a while.

Wine sucked and there was less software existed but it was perfectly possible to do the normal tasks one did with a computer.

Back on my IBM 386/75MHz (yes, really), linux could only boot at 25MHz, yet its desktop environment was faster, prettier and more featureful than Windows @75MHz

Edit: I guess it was a 486 in a 386 motherboard. Windows was definitely slower at 75MHz than Linux at 25MHz though:

http://ps-2.kev009.com/sandy55/Interposer/386_upgrade.html#R...

From what I gather its a chicken and egg issue. Wayland would get more attention and development if it had more users. It would have more users if it had more feature development. Although a lot of the bigger gaps are closed or closing now. OBS now works on Wayland as of 03/30/2021 and Fedora plans to ship Wayland as the default.

Fedora Workstation (i.e. GNOME) has already been shipping with Wayland by default. What's new is that Fedora KDE is also going to ship with Wayland by default.

Reference: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPl...

Maybe actually trying it and adding something to the discussion would be better?

> Fractional scaling is kind of the most visible thing today.

And also perfectly possible with X11 because the pitch information is exposed via the Xrandr extention

> Problem: tearing, solvable with double buffering, maybe.

Solved since ages. Just enable Tearfree in your Xorg.conf. That also shows how great X11 really is. It allows you the choice to turn it on or off. Because Tearfree comes at a cost of latency.

> Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.

OpneBSD solved that two decades ago. Also it perfectly possible on Linux to run X11 as non-Root.

> Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program.

This is a feature not a bug. The security paradigm is blacklisting (which means sandboxing untrusted apps) instead of whitelising (which means locking everything up and only allow the compositor to do stuff). Since the vast majority of Software on FOSS system is trusted X11 is the far superior solution here.

> Problem: Xorg is a network system, meaning it is very inefficient.

X11 runs even on 386's and beats Wayland in every performance metric, especially latency. After 13 years of development only some compositors come close to X11's performance.

> Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features.

Backwards compatibility is a major feature even 40 year old Software runs on current Xorg which is an impressive feat. As for the "hardware features": DRI3 uses the exact same buffer sharing mechanism as the major Wayland compositors do. Wayland offers zero advantage in exploited Hardware features. On the contrary X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.

> Overall, wayland is a good clean slate, it’s been in development a long time.

It is a clean slate, but a very bad one. The wrong philosophy ("every frame is perfect") and the wrong abstractions ("everything in the universe is a buffer made of RGB values") make it a major step backwards in computer graphics on Unix/Linux.

> The security paradigm is blacklisting [...]. Since the vast majority of Software on FOSS system is trusted X11 is the far superior solution here.

This is absolutely not a good solution. Even if you audited all your software enough to consider it trusted (which is unlikely if you're not a purist - see IDEs, browsers, widevine, Docker ...), it does not guarantee anything is secure. Anything that receives input from the outside might be vulnerable to an RCE. If you're running it under a different user or in a jail, the impact is limited - unless it can access your X server, in which case it can simply log everything you type and escalate.

Jailing an app is basically impossible under X. Yes, you can use Zephyr, but you're not going to be able to watch a video there and you're WM integration is going to be miserable as well. And realistically you'd really need to jail most apps.

X11 might work for a lot of things, but blacklisting is absolutely not a superior approach.

> it does not guarantee anything is secure.

Indeed. But looking at the state of the average Wayland compositor right now I trust all of my X11 software more than I trust Wayland. Especially when X11 and most clients have been battle tested for up to 35 years.

Besides that, you can also use Xpra for sandboxing which has better desktop integration.

> perfectly possible with X11 because the pitch information is exposed via the Xrandr extention

Only the "Windows" kind of scaling where the app works in non-scaled, real pixels and does everything by itself. Not the "Apple" kind of scaling that Wayland supports, where you have logical pixels backed by 2x/3x/… the physical pixels. (Like many things Apple does, this was invented for good reasons. Positioning a window to be on both a 1x and a 2x monitor just works with that kind of scaling, without the app ever having to consider the displays it touches.)

> Solved since ages. Just enable Tearfree in your Xorg.conf.

That's a driver-specific hack that kinda maybe works sometimes. Sometimes you need to juggle compositor options combined with that and nothing works anyway.

> X11 runs even on 386's and beats Wayland in every performance metric, especially latency.

Any composited X11 desktop is slower than a Wayland one, with the Xorg server acting as a bloated IPC broker in between the compositor and the client.

Yeah, you can get really low latency if you just don't composite at all. Go back to Windows 95 if you think that's acceptable :)

> X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.

I'm sure pretty much all production Wayland compositors use the cursor layer. wlroots for sure does. (But I don't think it's a big deal under heavy load, there the problem is the display server even processing the mouse events at all first.)

Weston goes further and can use HW layers for actual surface compositing when possible. wlroots is going to gain that power soon-ish with libliftoff.

> The wrong philosophy ("every frame is perfect")

Again, feel free to use Windows 95.

For anyone used to current commercial desktop and mobile UIs, any imperfect frames are unacceptable, artifacts like tearing make your system look like a complete joke. Apple computers didn't show imperfect frames since the early early 2000s PowerPC era. Not matching that is a complete shame.

> logical pixels backed by 2x/3x/… the physical pixels.

This is not fractional scaling. Fractional scaling has to be done by the application itself (even on Wayland).

> That's a driver-specific hack

It is not a hack. It is a solution and a very good one because DDX drivers can make use of vendor specific 2D acceleration and therefore achieve much better latency with the tearfree option on X11 than Wayland ever will where everything runs through the 3D pipeline by default.

> Any composited X11 desktop is slower than a Wayland one

If you enable Tearfree you don't need a compositor if the driver works properly. Of course X11 compositors with fancy blur effects have bad performance. I always turn them off.

> Go back to Windows 95 if you think that's acceptable :)

Why don't you switch to Android? Android already does everything that Wayland fans want and better.

> I'm sure pretty much all production Wayland compositors use the cursor layer.

I get severe mouse stuttering on high CPU or GPU load. A problem that was solved on X11 20 years ago. I have no idea what wlroots really does but it does it definitely wrong.

> Go back to Windows 95 if you think that's acceptable :)

The value of X11 is the ecosystem and platform it provides. If you want Linux with a compositor switch to Android. There you also have your sandboxing and whatnot. Don't turn the Linux Desktop into a Phone OS. As Desktop OS I genuinely prefer Windows 95 over Android.

> Apple computers didn't show imperfect frames since the early early 2000s PowerPC era.

Ever used OS X on those? They are barely usable because of severe lag and stuttering. But yeah the frames were so perfect that most people decided to switch back to MacOS 9 to do real work.

> Fractional scaling has to be done by the application itself (even on Wayland).

No, fractional is handled by applications just rendering at 2x and getting downscaled to 1.5x or whatever.

Yeah, the "Windows" way looks sharper on fractional, but the "Apple" downscaling is easier to handle and it looks fine – there were iPhones that did everything like that.

> DDX drivers can make use of vendor specific 2D acceleration

Ah, I remember Intel's various native 2D accelerations (UXA, SNA) – each with its own unique horrific bugs (artifacts all over the screen, all text turning into junk), all eventually sorta deprecated in favor of glamor (OpenGL) with the generic modesetting driver.

There's not much to 2D accelerate with modern applications that all do their own rendering. Compositing acceleration is possible in a vendor-agnostic way via KMS planes and we'll have that in wlroots.

> Ever used OS X on those? They are barely usable because of severe lag and stuttering.

I have an iBook G4 :) Leopard runs perfectly smoothly. Yeah, the very first generation of hardware when OS X was just introduced wasn't ready. The next one was.

> There's not much to 2D accelerate with modern applications that all do their own rendering. Compositing acceleration is possible in a vendor-agnostic way via KMS planes and we'll have that in wlroots.

It's even more fun when your realize no GPU in the last decade has shipped 2D acceleration capabilities. Wayland uses 3D acceleration because that's what GPUs offer, because that's what the other platforms exclusively offer now.

Reply on news.ycombinator.com