So let’s talk about this Wayland thing | Hacker News Reader

So let’s talk about this Wayland thing

pointieststick.com

96 pointsaquova130 comments

I've been using Wayland for about 10 years now, mainly because of superior hi-DPI support. If you have multiple monitors with different scale factors, X11 is just awful. Not to mention I usually have laptops with not-quite-4k displays that need to be scaled 1.25x or 1.5x in order to look reasonable.

That kind of stuff basically all works fine on Windows, and yet a lot of core Linux desktop devs seem to have an ideological distaste for fractional scaling. Sway supports fractional scaling, but it's not recommended because "your display does not have fractional pixels". I realize that is literally true, but Windows and Mac support it and it looks good. Feels like Linux is full of this kind of stuff, and the result is the mess you see today. Sad part is that Windows is starting to degrade so bad that Linux is starting to look better just due to that. Hopefully Valve and friends can apply some competitive pressure on Windows, and in the process make Linux much nicer.

As Microsoft lost the grip on Desktop, and Desktop became less important, and they moved more and more into cloud and services biz, etc. you can expect Windows to atrophy even more.

Try using KDE, instead of Sway? If you look trough issues and discussion on https://gitlab.freedesktop.org, you get the distinct impression that the Sway/wlroots lead devs have very firm ideological commitments about absolutely everything. From non-open source drivers, to "every frame is perfect", to, as you point out, fractional scaling.

If you don't fit into their ideological commitments, you shouldn't expect to receive any support.

>Sway supports fractional scaling, but it's not recommended because "your display does not have fractional pixels".

Sway's reasoning is completely wrong and ignorant.

The characters (glyphs) and other elements on this page (e.g., the reply button, the rounded corners of the TEXTAREA) are stored as mathematical descriptions of curves (cubic Bezier curves usually for the text). There is never anywhere where a framebuffer or grid of pixels is scaled up or down from one size to another to introduce blurriness into the final image. The Y logo in the top right corner of this page used to be an exception because a PNG file is a grid of pixels, but about 2 years ago the PNG was replaced with an SVG file, so now when you pinch-zoom this page in mobile Safari, everything always looks non-blurry.

Well, when an app is using the Wayland protocol (i.e., when XWayand is not in between the app and the display server), the same thing applies.

Actually, pinch-zoom is the wrong analogy. Both Firefox and Chrome have in their "hamburger menu" a line named "Zoom that has "+" and "-" buttons. If you use those buttons to change the scaling factor, most things reflow (adapt so that nothing "falls off" (is partially obscured by) the right edge of the viewport). Fractional UI scaling in Gnome (when XWayland is not in the picture) works like that more than it works like pinch-zoom in mobile Safari where nothing ever reflows.

Note that in order to be able to use (the "Displays" pane of) the Settings app in Gnome to change the scaling factor to a value other than 1 or 2 (i.e., to a fractional value) you have to say

  gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

I still don't quite understand why Android and ChromeOS have seemingly good display systems on Linux with no drama or even any real identity to the display system, while X11 and Wayland have been churning on this stuff for so many years and don't seem to be at the same level of quality.

I know I'm missing something... but I also suspect it's the sort of something that's worth missing.

Wayland works completely fine. The issues come from legacy applications and hardware vendors who refuse to work with it. Android solves these problems by telling software and firmware makers that they either get with the program or not have access to half the mobile phone market. As well as just saying no to all the absurd requirements like being able to stream the protocol over the internet or track exact XY inputs absolute to the screen outside of the apps own window.

Desktop linux doesn't have this sway.

>> As well as just saying no to all the absurd requirements like being able to stream the protocol over the internet or track exact XY inputs absolute to the screen outside of the apps own window.

Which is a security hole along with being able to read keystrokes meant for any app, grabbing pixels that aren't yours, etc... the features people complained were missing from Wayland for the longest time were often security issues that X could never solve by design. But hey, fuck security I want to run Xeyes!

Times my system was hacked via x or xeyes since I started using Linux in 95... zero

It is not just about hacking your system. It's also about programs being able to hack into your accounts by keylogging you or stealing passwords from your clipboard. If you use cryptocurrencies malware can replace addresses on your clipboard with similar looking addresses while it's completely hidden in the background. Desktop Linux's security is usually like swiss cheese, so if you haven't been hacked it has more to do with you not encountering malware than your system protecting against it.

General purpose Linux distributions whether using Wayland or X don't meaningfully protect you from compromised software running on your system. Traditionally on all systems 99.9% of the game has always been and remains not installing malware or compromising your data or credentials.

This means 99.9% of actual threats to your security remain the same.

If you want actual isolation you need to run something like qubes which ironically actuality uses X

Wayland is simply one piece in the puzzle. Flatpak, PipeWire, etc are the fixing the other parts. Things are very slowly moving in the right direction though.

Unfortunately most linux distros and users do not take security seriously unless it's in a server environment. Desktop linux is awfully far behind systems like MacOS.

>Traditionally on all systems 99.9% of the game has always been and remains not installing malware or compromising your data or credentials.

This is a doomer mindset that ignores the advances the rest of the industry has been making. There is a big difference from malware having to find a 0day in order to cause harm to the user and malware developers being able to do exactly what they want without even a permission dialog box showing up.

It's a practical mindset concerned with actual not hypothetical risks and actual not hypothetical costs and benefits.

> Traditionally on all systems 99.9% of the game has always been and remains not installing malware or compromising your data or credentials

I won’t debate whether that’s true (it probably is, given that “not compromising your data or credentials” is close to a tautology “if you don’t let your stuff get stolen, it won’t get stolen”), but focus on

> This means 99.9% of actual threats to your security remain the same.

I don’t see how that follows because we’re not living in “traditionally” anymore.

IMHO, if iOS and Android had run “traditional X Windows”, the number of successful over the air attacks would be way higher or nobody would use smartphones out of fear of getting hacked.

> It's also about programs being able to hack into your accounts by keylogging you or stealing passwords from your clipboard

Honest question: why does this matter? If you end up with running malware as your user haven't you already "lost" in any of a wide variety of ways that Wayland does nothing against?

Or is it that Wayland is trying to bring the mobile security model to the desktop with partially untrusted apps?

>Honest question: why does this matter? If you end up with running malware as your user haven't you already "lost" in any of a wide variety of ways that Wayland does nothing against?

The security benefits of wayland are useful when you're also using other things like namespaces/seccomp (with bubblewrap/flatpak), and pipewire which I believe has a similar access control mechanism.

>Or is it that Wayland is trying to bring the mobile security model to the desktop with partially untrusted apps?

I trust my programs, but they can have bugs when parsing untrusted content. (ffmpeg, browsers). Although I've never been hacked, I'd like my systems to have defenses against this (without going full mobile security mode and giving up functionality and user freedom, or running everything in inconvenient isolated boxes with VMs).

Also, I'm not sure if I'd trust proprietary games, so preventing them from doing naive things (I don't expect them to exploit kernel vulns) like snooping on files by using namespaces is nice.

I think untrusted user input can exclude maliciously crafted urls and other ways where the user is not you.

Building one wall doesn't keep you dry in a house when it rains. You need 4 walls and a roof.

But the Linux ecosystem builds up to things bit by bit. So in this case, Wayland is progress towards a goal where untrusted apps can be run and are limited in what they can do by design. It doesn't matter at the moment, but one day it'll be an important brick in a secure system.

So, it will really matter when everything runs in a container or AppArmor or something like that. I wonder if that will ever be made convenient and "it just works" without having the impression of having apps being on somewhat inconvenient silos.

>bring the mobile security model to the desktop with partially untrusted apps?

That isn't a mobile security model. It's a good and more modern security model. Desktop operating systems are moving this way too but it's harder due to apps not originally being designed for it.

>> Honest question: why does this matter? If you end up with running malware as your user haven't you already "lost" in any of a wide variety of ways that Wayland does nothing against?

No. Your web browser does a pretty good job of not storing your login info (if you tell it not to) locally. Under X, malware can monitor everything you do and log your credentials. Under Wayland it can not. Simple as that.

Malware will still try to exploit bugs and CVEs to get access, but finding a hole in a wall is entirely different than not having a wall in the first place. Holes can be patched.

People run untrusted code on their machines every day. Most of it is in the browser (which has walls) and is written by advertisers that are not well scrutinized by the sites people visit. Then there is the whole trend of containers which put more walls around native apps.

So in your question, replace malware" with "untrusted code" and it becomes more realistic.

If you have malware running with your user permissions, your entire browser can be swapped out with a hacked version that keylogs you. The entire GNU/Linux desktop security model falls to pieces the moment you have malware running with your user permissions, there's a sword of Damocles hanging above you by a meter long thread of silk and Wayland proposes to replace one centimeter of that string with a steel cable. Great, 99 cm of that string is still silk thread so nothing has changed.

Anyway to echo beanjuiceII's point, number of times I've been pwned by an X keylogger: Zero.

> number of times I've been pwned by an X keylogger: Zero.

(That you know of). Number of times I've been pwned by any technical vector (that I know of): zero. The fact it hasn't happened to you does not imply that defending against it is pointless. Early in my computing career I used the same weak password for everything. Never had an account takeover. That does not imply that using different secure passwords for each site is pointless.

> (That you know of).

The number of ways I might have been pwned and not known about it is basically infinite. Why should I prioritize replacing X11 over any other hypothetical threat for which I have no evidence that I'm at particular risk of? Nobody has photographed my house keys and made copies that I know of. Should I re-key all my locks just to be extra safe? I could replace my front door with an armored door too.. but a burglar would just come in through a window instead so what would be the point?

There's no point armoring your front door unless you also put bars on all your windows, and there's no point adopting wayland for security unless you fix all the other security problems with running malicious software on the GNU/Linux desktop too. And miss me with the QubesOS/flatpack/etc suggestions, my days of playing amateur sysadmin are over I just want to use my computer, not tinker with experimental desktop administration.

I guess we might as well not bother with passwords either or disk encryption either. After all other exploits exist and there's not point protecting against any attack vector unless all are covered. Security comes from many layers, and is a constant and incremental process. "Someone might get in by breaking a window" is not a reason not to install locks on your doors.

>> If you have malware running with your user permissions, your entire browser can be swapped out with a hacked version that keylogs you.

That's not true either. The malware would require privilege escalation to co-opt my browser. Even if you weren't wrong about that, I don't know why you complain about both weak security models AND a very big improvement in Linux security (Wayland).

Oh right, on X the malware could just wait for me to type in my password for something I wanted to do and grab it. then it could sudo just like me.

> That's not true either. The malware would require privilege escalation to co-opt my browser.

Does it? Sure it can't replace /usr/bin/firefox, but what's stopping the malware from writing a fake shortcut to ~/.local/share/applications/malwarefirefox.desktop and waiting until you click the fake shortcut? Or kill the running firefox and start the malware version? Or add some malware extension directly to ~/.mozilla/firefox/profiles? Or something else?

Or are you assuming the malware is running in a sandbox like AppArmor?

Exactly. A program running as the user can change the user's desktop configuration to launch a hacked browser instead of the browser installed by the system. It can also edit PATH and then wrap sudo and get root access the next time you use it, or fuck with you a thousand other ways.

Apparently you weren't on our university, being a victim on unwanted content when the teacher would be going to look at your screen.

>> Times my system was hacked via x or xeyes since I started using Linux in 95... zero

Ummm right. The point wasn't that Xeyes is a security threat. It's that Xeyes is only possible because X is insecure by design, which is what allows the eyes to literally monitor what you're doing. Mouse, keystroke, screen grab. Hey go ahead and do your online banking with X. Just remember the real malware is headless, not literally displaying eyes to let you know it's watching.

Sure, but there are also legitimate uses for things like that, otherwise people wouldn't want them. How you build screen-recorders for example without "grabbing pixels that aren't yours"?

Clearly, something is missing here. Why not a permission system like browsers do? A little popup that asks "X is requesting access to your full screen" rather than this "convenience VS security" black and white view most people seem to take a stance at?

The answer is that these need to be special privileges controlled by the OS. Which is exactly how wayland manages it.

Discord capturing the screen is a valid use case, but it should be approved by the DE and it should be possible to block this request.

Currently the mainstream DEs just approve the request by default but in the future I can see a permissions dialog asking the user if they want to allow access to screen recording, and maybe a small icon in the top bar to show when recordings are happening.

Yup, or with your own scripts managing bwrap and security-context if not using a DE/Flatpak.

That answer sucks so much that after nearly 15 years of Wayland evangelism KDE e.V. Directors are writing blog posts with "Wait, that sounds like it sucks" as a heading and talking about how the issues have been resolved to the point where it is just "ready enough for Plasma and KDE apps", with some reasonable paraphrasing. That is not a history to be proud of, for all that even Wayland is a big step up from X and we're all grateful for the efforts these people go to.

This idea that screenshots require special OS-level privileges has been tested and, in practice, does not work. Literally nobody wants compositor-specific screenshot applications. It should have been addressed in the Wayland standards in the early drafts.

Fair enough unrestricted access to any pixel is a security problem. But banning all access to pixels other programs control was an unworkable position that, in hindsight, didn't work. Telling people that the process that merges all the pixels together needs special OS-level support for reporting on what the merged output look like is just not sane. Something went wrong in the design process.

This discussion IMHO shows why it's been so contentious. Wayland started from the secure end without having answers to questions like screen grabbing/sharing or GIMP eye dropper. They figured there would be solutions down the road. On the other side a bunch of people complained about shortcomings like these, but rather than offer solutions they just wanted to stick with X.

IMHO the right answer might be a GUI toolkit (out of process) that has an API for system resources. Permission would be either granted by the user (a file dialog already indicates what files an app should have access to) or set at the application level at install time. The failure to develop solutions like this is why browsers have taken it on by themselves, because they are constantly running untrusted code.

The right answer is this repository:

https://gitlab.freedesktop.org/wayland/wayland-protocols

They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful.

You can see the docs in pretty form here: https://wayland.app/protocols/

Only took 15 years. Pay special attention to the name of Drew DeVault who has been one of the major heros in the story. The Wayland devs apart from Drew do deserve serious kudos, moving away from X was never going to be easy. But copying pixels into a shared buffer as some sort of challenge is just hard to overlook.

>>They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful.

Dude please. Wayland has been 100 percent usable FOR ME for years. Plain Wayland is not "crippled" for MY use case. It may be crippled for YOUR use case, and that's a legitimate concern, but don't broad brush Wayland as not usable and crippled in general. For many of us it's already where it needs to be. That said, I do hope those remaining things get sorted out soon.

Compositors that don't support Wayland protocol extensions are in a tough spot. They are likely on the road to being seen as toy implementations for aforementioned reasons.

The de-facto Wayland standard is not going to be the core protocol, in the same way that the core X protocol is woefully insufficient [0] for actually running a modern linux system. It needs extensions. The core protocol just isn't featureful enough - as has been clearly demonstrated by a decade lost in the woods not supporting basic desktop functionality. If a design goal was to delay adoption by 10-15 years while they think about things then I suppose it could be considered a success. Other systems have managed to move much faster than that without doing much harm.

The sticking point is that at least the core X protocol didn't need a decade of R&D for a screenshot extension [1]. I suppose people could claim with a straight face that screenshots and streaming are unforeseen use cases, but they would be excellent poker players. It was a design mistake not to explicitly address that up front. An honest one, made by very competent people, but nevertheless a mis-step.

[0] https://wiki.gnome.org/GraphicsRequirements

[1] I'll admit this is before my time - maybe it did? But the X protocol is a hot mess and Wayland is inching towards the point where it's release is closer to the birth of X windows than the present day.

But this happens with Wayland nowadays (at least on Gnome). When you try to take a screenshot or share your screen, a popup appears where you can select the monitor, area, window, etc, before sending the image to the software. If you close the screen, the software fails. Try to use Flameshot or Google meet on Ubuntu to see that behavior.

Screenshots work fine for me on Fedora Wayland. Just like you say, except for the failing.

> Wayland works completely fine.

Agreed. What's the missing feature? Screen sharing? Remote sessions? Overlapping displays (doesn't work in Android BTW)? We've had all of these for years.

Even fractional scaling on hiDPI monitors has been good enough for me to not care for at least 5 years.

It's like systemd; the people bitching either want to sound contrarian or actually know enough to roll their own down to the low level. At which point I must say; show me the code. Open a PR or give it a rest

For me, personally, this was the year of Wayland... but that comes after years of checking every few months whether it was ready.

My last-resolved reason not to switch: Popular compositors didn't support scaling for XWayland on par with how it works when X11 controls the screen right up until this year.

This meant that you either had to opt out of scaling in Wayland (horrible on high dpi displays) or accept super blurry XWayland windows.

Of course, it would be great if we didn't need XWayland but... That's not going to happen until more users have Wayland desktops and users like me weren't about to accept Wayland desktops while this type of problem existed.

Color management is an obvious one. There's a merge request, but still in progress.[1] Linux isn't particularly suitable to photo editing anyway, but it'd be nice to at least display colors properly!

[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

When you launch a device in the Android or ChromeOS ecosystem the specific {motherboard, graphics card, cpu, etc} combination gets tested by the manufacturer before launch and drivers written/updated to make sure they work well together. In the Linux world, this is not possible as there is a combinatoric explosion of possible configurations.

On top of that, in the wider PC system, hardware routinely launches without dev/test in the Linux world. Drivers often work for a whole chipset, so may often be running a specific device within that chipset that was never tested or seen by the developer of the driver at all, let alone in the hardware combination.

android didn't gain official mutliple on screen windows until relatively recently, and even so they're still only in some fixed sizes. It also helps that any changes are tied to released by one company (google), while the linux stack is made up of stuff by tons of differnet people with different moving parts, and then distributed at various versions by various people on various distributions at different release cadences. There's no one group controlling any of this

A sibling comment also mentioned hardware. There's certainly a lot less driver and hardware variance as well.

When it comes to chromeOS, I think they are switching to a wayland compositor, and it'll be a lot easier for them because there they control everything.

ChromeOS is migrating to Wayland as part of the "Lacros" project.

(And the Linux environment and the Android environment in ChromeOS are already using Wayland.)

> Standard protocols now exist for just about everything anyone needs.

I have been OOTL with the Wayland ecosystem for a few years. Does it provide a way for users to create and use input macros (similar to Autohotkey and xdotool) yet? That (in addition to remote desktop and screen casting) was one of the main blockers for me in daily-driving it.

There's ydotool, but as far as I tested with it, the only movements that work are relative movements. You can't tell it to a click a specific x/y because it will fumble badly (Nobara / Fedora 38 )

iirc ydotool just whips a relative device into a corner before trying to position it, which gets it extra wrong if there's mouse acceleration. It's one of the reasons I wrote dotool (https://git.sr.ht/~geb/dotool): echo mouseto 0.5 0.5 | dotool

I use Espanso for this; it has worked well on Wayland for some time.

yes, you need root and a different implementation than with xorg, but yes you can

I can bag on Wayland for days for being broken at an architectural level ...

However, the real root problem is that the number of people who really give one iota of damn about "desktop interaction semantics" is vanishingly small.

Developers who want Unix and want their display to "simply work" switch to Apple. Consequently, the only people left behind are the very fractious minority on Linux who care about a zillion different edge cases.

I really don't see a good way to fix things.

The fractious minority is here, yes, but also a large number of people like me who don't care about display quality, "desktop interaction semantics," or surface consistency at all, but care deeply about being able to use their computer as they please.

Unless you please the computer to have some display quality

I'm very happy with my Linux desktop. I think MacOS looks like a child's toy and Windows looks like it was created by 100 different people who hate each other. Each to their own.

I used MacOS for a few years but when it came time to get a new computer I switched back to Linux because nothing actually worked better in MacOS, and a few things worked worse. I think the best advantage to MacOS is knowing you'll have drivers, but that's a moot point for me because I buy hardware I know will work well with Linux. The "switch to Apple for things to work" narrative is a big meme.

Great article, thanks. Until now did not understand why W was so slow to be accepted while systemd and pipewire took over quickly.

Personally hadn’t tried it until recently, though nothing against it. Had an extra laptop and wanted to try some new stuff so installed Fedora KDE on it.

Works quite well but unfortunately synergy/barrier doesn’t work and folks don’t seem to think it ever can. That’s a deal breaker for me at my desk. Will be going back to mint/cinnamon/X shortly, and leave fedora as a travel laptop.

Kinda disappointing after so many years… fifteen! and still second fiddle.

i tried to see what was synergy/barrier and for what i read i don't see any reason to for it to not work on wayland, it just need to accept the correct protocol and portals

This will take at another decade at least.

Right. I use x2x which is kind of like Synergy so I’m staying with xorg for now.

i used to be upset that they took away x remoting because it was a cool party trick but then they gave me the ability to have monitors with different dpis and that's how i learned to stop worrying and love the wayland.

When I first learned about X forwarding we had a modem, and X was responsive. I also played CivII over remote desktop and it was...less responsive.

With Wayland, have you tried out waypipe yet?

https://gitlab.freedesktop.org/mstoeckl/waypipe/ is a great replacement for X remoting.

It is unfortunate but forced vsync means I will never adopt Wayland. I do not want a frame+ delay when I'm gaming. I do not want v-sync lag when my framerate occasionally drops below my 240hz refresh rate.

I don't even especially like X11, I just don't want vsync forced on me.

I'm not sure how widely supported it is, but Wayland has a protocol to support turning off v-sync.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

I believe that Mesa has just recently added support.

Wayland doesn't actually add an additional frame of latency like you'd expect by just saying "vsync" in a normal context. https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-...

In cases where your game occasionally dips below 240hz enabling VRR will prevent additional latency without requiring you introduce tearing in the display pipeline.

> If you require the absolutely lowest latency possible though and don’t care about screen tearing then X without compositing, with VSync disabled is a better fit for you. You can re-evaluate once the possibility to have VSync disabled is implemented in your compositor of choice and the measured increased volatility in latency (99th percentile) with immediate mode is fixed.

I enjoyed the post, thanks. I suppose I'll wait then and re-evaluate when Wayland's 'immediate mode' is fixed and it is roughly comparable to X11 without a compositor. I go to great lengths to minimize my latency so this is really the only factor that matters to me.

tearing can be optionally enabled via recent protocol extensions, but I'm not sure how widely implemented it is yet.

My latest Wayland issue is devices that generate a lot of input events causing apps to crash.

https://bugzilla.mozilla.org/show_bug.cgi?id=1743144

Also https://gitlab.freedesktop.org/wayland/wayland/-/issues/159

Wayland works fine for me but it doesn't seem to allow many applications to take screenshots or recording the screen, so I had problems with PyAutoGUI and Discord and I switched back to X11, if anyone knows a solution I would appreciate.

The only proper solution is e.g. Electron add the support and Discord then updates the base version of Electron. I remember reading somebody was working on a bridge for X11 apps to get Wayland screenshare access but I don't know if that actually became functional/usable. Wayland itself has had all of the bits for years at this point but it just doesn't have official bits for apps still running X11 style screensharing only.

It's like GIMP still using GTK 2, it has no idea of Wayland at all so there's not much Wayland can do beyond run it an an XWayland island. Unfortunately there is no easy universal fix to that kind of gap beyond updating apps.

Edit: a sibling comment linked to the project I was remembering - xwaylandbridge

>It's like GIMP still using GTK 2, it has no idea of Wayland at all

Oh I remember now, I was using GIMP and I couldn't figure out why the color picker was not working, I think that I understand now what was the reason.

"Simply add screenshot and screen capture functionality to your favorite compositor and add a code path in your app to detect what compositor you're using at runtime and call the right methods" - Wayland developers

Better hope the compositor of the week you're using that hasn't yet been abandoned is based on wlroots so you have some chance of it working.

The actual solutions here are XDG Desktop Portals or Wayland protocols, the former of which are commonly used (<https://flatpak.github.io/xdg-desktop-portal/>) and the latter of which are unstable proposals (<https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/...>). Wayland clients don't do compositor detection like you're describing, to my knowledge.

For Discord you can try XWaylandVideoBridge.

https://invent.kde.org/system/xwaylandvideobridge

I don't think there is any solution for PyAutoGUI at the moment. Likely would require a lot of changes to their code.

wayland allow, discord just need to fix their application(if you open discord on chrome or firefox it work fine)

I’m having nice time with waylaid, have used it with plasma for a year, and a couple of weeks ago I re-emerged everything with -X -xorg etc and can’t compla

I love X and find it being in maintenance a good thing? It seems to work all the time and stays out of my way. That’s what I want.

> The fact that Wayland’s minimal core protocol made it unable to fully replace the thing it aimed to replace was a bad architectural design decision on the part of its authors that crippled the prospect of its rapid adoption when it was released in 2008.

Maybe I missed it in the article, but what was this decision?

The decision to leave basic necessities to the compositor, it's discussed in the "How is Wayland any better?" and "Wait, that sounds like it sucks" sections.

That section seemed light on details of what was missing though.

>Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work–such as screen locking, screen sharing, cross-app window activation, non-integer scaling, and so on.

Seems enough to show why it's a contentious decision.

That'd end up being a longish explanation of what wlroots is, and I think that'd detract from the post. Noting the vacuum exists and linking to the emergent library that filled is sufficient, and gives the curious reader something they can follow up on.

The subject is well documented by now.

Doesn't switching to Wayland also implicitly mean losing any input system other than libinput? Like Wayland libinput also does not currently have feature parity with the other input configuration tools that are available for X.

Wayland was working fine on Fedora 38... until I switched to Nvidia. Had to go back to X11. It seems their driver was developed for X11 and the Wayland support is a hack on top and has many issues.

nvidia moment

https://arewewaylandyet.com/

We are still not Wayland yet. And my setup is personally blocked by both Xs.

Personally not blocked at all as those two are things I use in a professional setting related to graphics work, and then I'm forced to use Windows regardless of what I think.

Mine is amateur framing so I get to choose OS+compositor. But I had to migrate back to X11 to do photography work. Color management also helps professionally when communicating with designers, but isn’t necessity. The dock I picked up, I didn’t realize DisplayLink was something I would need to worry about since they have Linux drivers--and if there isn’t already patched flag available in Nixpkgs, I could add it if the color management ever makes progress after years of development.

Unfortunately, this site is outdated.

> Last updated: 31 October 2022

? The two Xs are still open issues.

Wayland is nice and all, but I haven’t seen an end-to-end solution for “headless” remote login yet. Until there’s a working Xrdp replacement, I don’t have much use for it personally.

> end-to-end solution for “headless” remote login

like ssh?

or maybe like this? https://gitlab.freedesktop.org/mstoeckl/waypipe/

No, with RDP.

I've been a big fan of wayland until a few months ago when I tried to put my friend on KDE with a nvidia card. It was still completely unusable as a daily driver.

Whenever nvidia is involved you know the culprit. Linus flipped them off for a reason.

Does Wayland on Ubuntu work with NVidia GPUs yet?

the correct question is "nvidia work in wayland yet?" and the answer is "it depends" arewewaylandyet.com/

Note that page was last updated in 2022, and one of the pages it references was last updated in 2019. I went round and round with this on the Ubuntu bug report system. On many machines, you can't run Wayland even if you want to. Oh, the excuses: "you should patch this shell script to let you run Wayland".

Wayland just doesn't work with modern NVidia cards. I just tried on a machine with an NVidia 3070. Current Ubuntu 22.04 LTS, updated. The installed NVidia driver is the "recommended driver", NVidia-driver-535 (proprietary, tested.) The system will run in Wayland mode, but the 3D graphics hardware isn't used. "glxgears" reports that it is using Mesa 23.0.4. Programs that use Vulkan won't even start.

Back to X.

Found workaround: install libnvidia-egl-wayland1, and reboot.[1]

"I wonder why that library is not installed by default with the NVIDIA driver..."

That's so Linux.

[1] https://ubuntuforums.org/showthread.php?t=2490293

Can we please just get to what OS X had twenty years ago. Please.

Including color management. Please.

Can you be more specific? I'm a 10-year MacOS user who now uses desktop Linux ~80% of the time and I can't think of any glaring issues.

I see people reporting that apps such as Zoom and Discord can't do screenshots or screen recording/sharing with Wayland.

That's a glaring issue for many users these days.

That's been fixed (although it was fixed years later than it should have been).

Not being sarcastic. But the way we work in Linux community is tell people everything works and it's all awesome, windows sucks. Then you format your disks with Linux, we disappear when you realize most things you do on a computer don't work and we move on to the next person..or we tell you to crack open an editor and get coding

The long tail of features required by everyone is huge these days and a different subset needed for each person.

I tried to shut off USB wake on MacOS tonight. Nope. Does not support, goodbye.

So that's a tough "bug". Wayland provides the API, and they are enabled in KDE/Gnome/etc, and Electron is wired up for it.

However, how do you convince Discord to update their bundle version of Electron?

Let's not

Has Wayland adoption really been so slow because of technical reasons, or because of its developers and advocates observably abysmal social skills?

Edit: I know that could kind of sound incendiary, but let's consider the facts. We're talking about a project that has been competing with a dead competitor for 15 years and is still struggling to get mainstream acceptance. There's something seriously dysfunctional going on.

I'm not using it because Cinnamon doesn't support it. When it does I guess I'll switch.

Although the egl requirement has proven troublesome the times I've dipped my toes in, previously: if I have an NVIDIA or AMD GPU in my machine, I do expect to not get told it's unsupported.

It's been a few years since I've worked with the cinnamon team, but their 2019 sentiment was basically "ignore Wayland and hope it dies".

I don't know. I'm willing to give them another 10 to 15 years.

You're missing the most obvious reason. Wayland adoption has been slow because nobody cares that much about the Linux desktop because it's not profitable, so it's at best a hobby project of a couple of dozen people. It's hard to make sweeping changes with such a group. A lot of the work has actually been done by companies like Red Hat and Collabora and Igalia doing drive-by enablement work on a bunch of open source projects.

That manifests in a bunch of different ways. Lots of desktop software is still using the likes of Gtk 2 and obviously won't get Wayland support without being ported first. Desktop Environments like XFCE and Cinnamon are, again, basically hobby projects and re-architecting them for Wayland is a big ask for non-professional maintainers. And then you have stuff like Zoom and other Electron apps that take their time adopting Wayland simply because Linux was always an afterthought to them anyway.

This sort of thing makes Wayland less defensible to me then - why fragment the user and developer base even further?

Because Xorg is broken and Xwayland works well enough as a translation layer to tide everyone over even if it's not ideal.

You are free to develop an X11 subset that is easier to maintain and convince existing Xorg users to switch to your subset.

Arcan ( arcan-fe.com ) looks like it could fill that niche, but its developer has gone out of his way to avoid attention and is primarily focused on getting the core protocol right, rather than trying to drive adoption.

I'm personally hoping that, come ~2025, Arcan v1.0 is released, the WM crowd largely switches to Arcan-based systems, and Wayland becomes the new JACK (with X being the new ALSA, I guess?).

Mostly technical. But, I'll try to be a bit charitable.

1) A lot of architectural decisions that made sense in 2008 are less optimal today.

Everything language-wise was C/C++ while today lots of different languages want to interface to your display system. The input system was completely hamstrung--things like gestures and multi-touch and things like that just weren't in anybody's brain yet. (Wayland started just after the first iPhone was introduced). And RT_PREEMPT still isn't a thing for Linux while both Windows and macOS underwent major surgery to allow real-time paths for things like audio and interaction.

2) Desktop composition semantics are not exactly easy to define.

Windows has certain definitions, but even it falls back to pure CPU software rendering in a lot of cases.

3) Weak support from graphics card companies

Windows relies on a LOT of driver hacks so everything goes through the compositor on really fast paths. That's a lot of work that nobody really has the bandwidth to do on Linux.

No wide support for nVidia binary drivers either

FWIW I don't think this is an issue anymore, nVidia began implementing the necessary APIs - it was more a situation of nVidia not supporting Wayland, not the other way around - a couple of years ago.

https://www.nvidia.com/download/driverResults.aspx/181159/en...

>it was more a situation of nVidia not supporting Wayland, not the other way around - a couple of years ago.

Do not forget the era where compositors were choosing not to support an open standard of the EGL_KHR_stream extension. Instead they preferred a proprietary solution using Mesa's GBM API.

For good, functionality-related reasons at the time[0], and everyone in the Wayland space had been using the mesa library except nvidia with their own proprietary libgl.

[0]: https://github.com/swaywm/sway/issues/490#issuecomment-47174...

>For good, functionality-related reasons at the time

Having it work surely is better than those drawbacks. Things can be improved and iterated on over time.

Wayland adoption was damaged by this.

>and everyone in the Wayland space had been using the mesa library

They chose to make themselves compatible with a single graphics driver. GBM ended up having to be rearchitected so that Nvidia could create a backend for end.

I think it is a little of both, and this issue might be a pretty good example: https://gitlab.gnome.org/GNOME/mutter/-/issues/217

Basically, the GNOME devs refuse to provide default window decorations (title bars, etc), forcing all Wayland app devs to draw their own title bars and "X" buttons for their windows. This is a bit silly since some desktop envs do provide default decorations, and 99% of the time you probably want your app to have native-looking title bars.

So now we have 1) ugly window decorations on some apps because that's "according to the Wayland spec", and 2) windows with no decorations at all, but only when running on GNOME. End result is ugly inconsistency that makes it very hard to compete with the likes of macOS and Windows on a visual level. And it's all due to a mixture of human stubbornness and arguably an architectural blunder on Wayland's part (but maybe mostly the former, to further your point...)

Maybe a dead competitor, but one that 15 years ago still had a 25 year head start.

Reply on news.ycombinator.com