
Exposing the Wayland lie (2018) - ubercow13
https://catfox.life/2018/07/31/exposing-the-wayland-lie/
======
ddevault
I am the maintainer of the most influential library in the Wayland ecosystem,
forming the foundation of a strong majority of Wayland compositors, and the
author of a popular Wayland compositor on top of this still. Last week I asked
the author of this article to issue a full retraction, because every point is
a blatant falsehood. Here is my appeal to the author, with some edits for the
sake of general audiences:

>I'd like to ask you to update this with a retraction at the top. I'm not sure
if you recall when we spoke about this on IRC a few months ago, but each of
these points is entirely false, and the article is a dishonest smear on
Wayland (though I assume you only had the best of intentions). To recap:

>1 - recording events from libinput only works if you're root, and if you're
root, you can do whatever you want. This is hardly a valid criticism of
Wayland. LD_PRELOLAD hacks don't work if the compositor launches the programs
- some simple .bashrc trick won't work, and getting the LD_PRELOAD into
.bashrc requires being unsandboxed, which itself opens up a wealth of side
channel attacks. None of this is a mark against Wayland - it's only one part
of a secure system, and the other parts are mandatory.

>2 - Wayland is a protocol, not its implementation. And many implementations
are widely supported by older hardware. wlroots, which is the dominant Wayland
ecosystem with over 75% of all compositors using it for their rendering,
requires only GLESv2, which is the most broadly supported OpenGL standard.

>3 - The headline doesn't match the body, but both are wrong. The design of
Wayland and its implementations is indeed much simpler than X11/xorg-server.
As for the use-cases brought up in the body of this point, the caracatures of
Wayland developers are rude and incorrect. For network transparency, it
wouldn't be difficult but no one who cares has stepped up to do the work.
Multiple clipboards are now supported. Many of the pieces of remote desktop
are in place, and again someone who cares needs to step up to implement the
rest and tie it together. We are ready and waiting to support anyone who wants
to step up to complete this work.

>4 - A bug in xorg-server will similarly bring down your X session. Driver
bugs affect both. Bugs are addressed when they're found, what more do you want
from us? Regardless, restart protocols are in the research phase and your
comments about the security holes implicated are blatant speculation.

>Support whatever you wish in your distro, but please don't publish dishonest
articles.

~~~
CyberShadow
> Last week I asked the author of this article to issue a full retraction,
> because every point is a blatant falsehood.

That doesn't sound reasonable.

> LD_PRELOLAD hacks don't work if the compositor launches the programs - some
> simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc
> requires being unsandboxed, which itself opens up a wealth of side channel
> attacks.

This lists quite a few assumptions. Are there many distributions that provide
these assumptions out of the box (specifically, the compositor running all
applications, and all applications being sandboxed)?

> >4 - A bug in xorg-server will similarly bring down your X session.

A Xorg server needs to implement:

\- the display server

A Wayland compositor needs to implement:

\- the display server

\- the window manager

\- the compositor

\- the hotkey daemon

\- the screenshotting tool

\- everything else that is now unimplementable in Wayland, but needs to be in
the Wayland compositor because users need them and Wayland compositor
implementers have no choice but to provide the features as API extensions.

I'm not really sure what's XWayland's story security-wise, but from my limited
understanding, it is a component that is not going away soon, and allows
bypassing some limitations of Wayland's API in order to accommodate X11
clients.

~~~
ddevault
>This lists quite a few assumptions. Are there many distributions that provide
these assumptions out of the box (specifically, the compositor running all
applications, and all applications being sandboxed)?

It's not the Wayland compositor's responsibility to provide an entire security
solution, just like it's not the deadbolt manufacturer's responsibility to
install an alarm system and security cameras. This isn't a criticism of
Wayland, at best it's a criticism of your Linux distro.

Flatpak does answer this question, but fwiw in the Sway camp we're still
looking into lighter-weight solutions.

>A Wayland compositor needs to implement: - the display server - the window
manager - the compositor - the hotkey daemon - the screenshotting tool -
everything else that is now unimplementable in Wayland, but needs to be in the
Wayland compositor because users need them and Wayland compositor implementers
have no choice but to provide the features as API extensions.

This is only partially true. wlroots implements screenshots the same way that
xorg-server does: by providing an API for exporting pixels to clients. The
actual screenshot tool is a standalone program which can crash without
affecting the compositor. This design is virtually identical to X, except
easier to secure. The same can be said of many of your other points.

~~~
nurettin
Let's say every attack vector exposed by wayland involves user being root or
somehow having sudo access or somehow being exempt in pam or somehow having
special access to input devices or being promoted through an ssh config or
being promoted through a vpn config.

That is still a huge attack vector considering that the userbase is desktop
users and not companies with security teams.

~~~
coldtea
> _That is still a huge attack vector considering that the userbase is desktop
> users and not companies with security teams._

Because the default in Linux is for Desktop users to login as roots?

Where have you seen that?

~~~
nurettin
Because after you use linux for a couple of years you become dangerously
knowledgeable and apply workarounds to make things more convenient, such as
allowing no password with sudo. Surprised I had to explain this, though.

~~~
coldtea
> _Surprised I had to explain this, though._

I'm surprised you even think taking such shortcuts has any bearing to wether
Wayland is secure.

People that "become dangerously knowledgeable and apply workarounds to make
things more convenient, such as allowing no password with sudo" should not
have much expectations for security.

The same way if you leave your front door open in a street level inner city
apartment, don't be surprised to be robbed.

~~~
nurettin
sudo or root is not the only way you can read someone's logs, which I tried to
explain above, so the whole point is moot.

------
Spivak
> Wayland is impossible to keylog.

This is an incorrect assessment of the claim which is, "with Wayland it
becomes possible to build a system where applications cannot record each-
other's events." To the best of my knowledge the only approach with X11 that
actually works is running each app with a separate X server. The author points
out that being able to register global handlers or programmatically interact
with other apps is useful which is why it's possible by asking the compositor
nicely. The trick with libinput requires that the system already be pwnd.

Another way of saying the same thing, "you cannot meaningfully sandbox
applications that talk to your X server."

> Network Transparency

Is a bad thing and a poor remote desktop solution. Let's say you have a
desktop with an Nvidia graphics card and you've installed their drivers. Your
laptop is using the OSS Intel drivers. You forward an OpenGL app from your
desktop to your laptop -- it will crash. Why? Because Nvidia's libGL expects
to talk to a server with Nvidia's GLX extension of the same version.

However, a ton of work is going into getting screencasting and remote desktop
working under Wayland in a manner that will let you implement whatever
protocol you care to speak on top RDP/VNC.

And VNC currently works on Mutter so I'm not sure why the author is bemoaning
it's loss. It's the feature that's getting the most development time right
now.

> Multiple clipboards

That's up to the implementor, Wayland had a very general API that's used to
exchange data between clients that can be used to implement clipboards in any
way the compositor sees fit. Just because GNOME/KDE don't want to maintain it
doesn't mean it's not there.

> Restarting ends your session.

If your X server crashes it ends your session too. So this is really an
argument that X.org is more stable than Mutter/Kwin. I don't think the devs
will argue with that but the point is that they'll get there.

~~~
patrickg_zill
Trusted Solaris had fine grained X Windows security.

In the Year 2000...

[http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec12-...](http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec12-solaris.pdf)

~~~
hedora
Yeah, but it’s not CADT-compliant:
[https://www.jwz.org/doc/cadt.html](https://www.jwz.org/doc/cadt.html)

------
CyberShadow
Thank you.

From what I've seen, Wayland seems to follow a very narrow set of use cases,
and willfully ignores others outside its philosophy, no matter what their
practical applications might be.

From what I remember reading previously:

\- Wine is unimplementable in Wayland. By design.

\- Programs cannot set their own hotkeys in Wayland. You must use the desktop
enviromnent's hotkey tool to set global hotkeys. (Desktop enviroments may
provide APIs for this, but then you get the foreseeable issues with using e.g.
KDE apps on Gnome. And what if you don't want a desktop "environment"?)

\- Screenshotting and screen casting tools are unimplementable in Wayland, by
design.

\- Some Wayland implementations provide additional features, like
screenshotting / hotkey registration, anyway, as API extensions. These
extensions are not standardized and require individual support for each
Wayland implementation in each program, thus causing further fragmentation.

\- I use the X forwarding feature so often that I have a hotkey on my laptop
to open an Emacs frame running on my desktop (on my laptop's screen). Being
able to jump between machines while keeping the entire session, incl. open and
unsaved files, is pretty great.

I can certainly think of situations where Wayland's advantages greatly
outweigh its drawbacks, but its philosophy seems so much at odds with at least
the way I interact with my computer, that the idea of switching to Wayland
seems completely unfathomable. As far as I can see, at this rate, Xorg will
live forever.

I've been instead working on my own little tool to fix the few annoyances in
Xorg clients that I ran into (the ease with which I've achieved this and the
flexibility of the tool speaks further in Xorg's favor):

[https://github.com/CyberShadow/hax11](https://github.com/CyberShadow/hax11)

~~~
emersion
>Wine is unimplementable in Wayland. By design.

This is false. Wine could be implemented, it would just be less easy than on
X11 because it uses relative coordinates for everything. But it's totally
possible to convert absolute coords to relative coords and use e.g.
wl_subsurface.

>Programs cannot set their own hotkeys in Wayland. You must use the desktop
enviromnent's hotkey tool to set global hotkeys.

Yes. This is by design, because it's very easy to turn a global hotkey
mechanism into a keylogger mechanism. Also it's not clear how hotkey conflicts
should be handled.

Note that there are protocol proposals for global hotkeys.

>Screenshotting and screen casting tools are unimplementable in Wayland, by
design.

They already work. See xdg-desktop-portal.

> Some Wayland implementations provide additional features, like
> screenshotting / hotkey registration, anyway, as API extensions. These
> extensions are not standardized and require individual support for each
> Wayland implementation in each program, thus causing further fragmentation.

That's how it works. Wayland doesn't have the magical power to make everybody
implement a common interface. For an interface to be implemented, compositor
writers and desktop developers have to agree on a design. Drew DeVault said on
IRC something that sums up the situation quite well: "Asking wayland for
hotkey management is like asking the HTTP standards group for a new HTML
element".

~~~
CyberShadow
> This is false. Wine could be implemented, [...]

Is the information in this bug outdated?

[https://bugs.winehq.org/show_bug.cgi?id=42284](https://bugs.winehq.org/show_bug.cgi?id=42284)

> Yes. This is by design, because it's very easy to turn a global hotkey
> mechanism into a keylogger mechanism. Also it's not clear how hotkey
> conflicts should be handled.

It doesn't change that this impacts usability, and a lot of software will need
significant updates to accommodate these limitations.

> They already work. See xdg-desktop-portal.

As I understand, xdg-desktop-portal is one competing mechanism among several.

> That's how it works. Wayland doesn't have the magical power to make
> everybody implement a common interface.

I don't understand... by "a common interface", how would that differ in
concept from the X11 protocol?

~~~
emersion
> Is the information in this bug outdated?

This comment suggests the same thing as me:
[https://bugs.winehq.org/show_bug.cgi?id=42284#c8](https://bugs.winehq.org/show_bug.cgi?id=42284#c8)

> It doesn't change that this impacts usability, and a lot of software will
> need significant updates to accommodate these limitations.

Yes, software needs to be updated to work with Wayland. Though, I'm not
personally using a lot of software having global hotkeys, and I can configure
global hotkeys in my compositor when needed.

> As I understand, xdg-desktop-portal is one competing mechanism among
> several.

It's the most widely supported mechanism. Works on GNOME and KDE, and support
for Sway (and more generally wlroots) is WIP.

> I don't understand... by "a common interface", how would that differ in
> concept from the X11 protocol?

In the X11 world, all WMs didn't have to agree on a screen capture protocol.

Note that there are discussions in progress to improve communication between
Wayland compositor writers.

------
lewiscollard
Regardless of the merits of the article, I don't like "lie", because it
implies people deliberately spreading falsehoods, and the comments here so far
reflect that tone which makes everyone's life a little worse. We're all in
this together; can we please be nicer to each other and not assume bad faith?

------
dooglius
> wl_proxy protocol can be LD_PRELOAD to own the entire system without any
> privilege required

I don't understand this claim. LD_PRELOAD doesn't allow you to do anything you
couldn't normally do. It sounds like the claim is if you run Wayland with
LD_PRELOAD set, it's vulnerable, but this is a case of what Raymond Chen would
call being on the other side of the airtight hatchway.

------
codedokode
Not being able to make a keylogger is actually bad thing.

Both X11 and Wayland have poorly designed keyboard events handling (which was
defined in XKeyboard spec in 1995). For example, you want to use Ctrl + Shift
keys to switch keyboard layouts on release. Simple thing that is working in
Windows. You cannot do that in Linux, because:

\- if you assign Ctrl + Shift to switch keyboard layout then when these keys
are pressed, the event will be consumed and you cannot use combinations like
Ctrl + Shift + F (this will be interpreted as Ctrl + F or Shift + F depending
on what key you have pressed earlier)

\- you cannot make a separate program that would monitor all key presses and
releases and switch layout without breaking other programs. In the X server
and extensions there is no such feature as "monitoring pressed keys"

The only way to do it reliably is to have a privileged program that would
listen to events in /dev/input.

By the way this bug hasn't been fixed for 14 years [1], and instead of fixing
it the distributions have been using different hacks and workarounds. Also,
they don't warn user that using Ctrl + Shift to switch layout will break
hotkeys using these modifiers.

Another issue is remote control programs like VNC. In both X11 and Wayland to
emulate user input VNC server muss pass a key number to the X server or
Wayland compositor. Not a keysym, not a unicode codepoint, but rather a number
of the key on a physical keyboard. Now guess what happens if VNC client's
machine has a keyboard layout with characters not present in layout on VNC
server's machine? Everything gets broken. Typical solution for this is to find
unused key number and patch current keyboard layout before sending a key press
event to the X server.

Because of the same reason on-screen keyboards on Linux cannot produce
characters not present in keyboard layout. Emoji, for example.

[1]
[https://bugs.freedesktop.org/show_bug.cgi?id=865](https://bugs.freedesktop.org/show_bug.cgi?id=865)

~~~
emersion
>For example, you want to use Ctrl + Shift keys to switch keyboard layouts on
release.

This is possible in Wayland, it's up to the compositor.

>Now guess what happens if VNC client's machine has a keyboard layout with
characters not present in layout on VNC server's machine?

This seems pretty normal to me. Remote keyboards are just like physical
keyboards. Just configure VNC's keyboard to use the correct layout.

(BTW I'm not sure I understand what you mean by "Everything is broken")

>Because of the same reason on-screen keyboards on Linux cannot produce
characters not present in keyboard layout. Emoji, for example.

I don't know about X11's status on this, however in Wayland on-screen
keyboards _can_ send unicode to the compositor via the standard text-input
protocol [1].

[1]: [https://github.com/wayland-project/wayland-
protocols/blob/ma...](https://github.com/wayland-project/wayland-
protocols/blob/master/unstable/text-input/text-input-unstable-v3.xml)

~~~
codedokode
> This is possible in Wayland, it's up to the compositor.

Typically compositor uses libxkbcommon which suffers from the same problems
that X server had.

> Remote keyboards are just like physical keyboards. Just configure VNC's
> keyboard to use the correct layout.

It is inconvenient and I don't think it would work. There is no such thing as
"VNC keyboard". VNC client sends keysyms over the wire, so the VNC server has
to convert them back to a key number, switch to necessary layout if there are
several of them, turn off modifiers like Shift if necessary. This is too
complicated. For example, x11vnc server doesn't support non-latin input
correctly.

> (BTW I'm not sure I understand what you mean by "Everything is broken")

That many VNC servers cannot handle non-latin input correctly.

> however in Wayland on-screen keyboards _can_ send unicode to the compositor
> via the standard text-input protocol

This looks like an extension for implementing IME. You can see that there is
no key press or key release events. These events are defined in wayland
protocol spec [1] and they still use a key number. So you cannot send key
press/release events for characters not present in current keyboard layout.

[1]
[https://wayland.freedesktop.org/docs/html/apa.html#protocol-...](https://wayland.freedesktop.org/docs/html/apa.html#protocol-
spec-wl_keyboard)

------
ken
> Multiple clipboards provide flexibility and power. I will be the first to
> admit that a great deal of people don’t know about this feature, and it is
> entirely possible to use a computer without it (look at Windows or the Mac
> OS). That doesn’t mean that I would enjoy losing it, however.

macOS _sort of_ has multiple clipboards, if you squint just right, but they
aren't all equally supported.

Select "aaa", command-C, then put your cursor at the front of "bbb",
control-K. You can paste the former with command-V, and the latter with
control-Y (just like Emacs). The kill buffer is just for text, and has
basically no API, so third-party programs can't (easily) use it.

There's also the search selection (command-E), which is pretty much only
usable for moving the selection to the search box. It's another semi-
persistent way to save some text, though.

The situation reminds me of the 6502 (which has 3 registers, each with
specific duties), or the 3 robots of Robot Odyssey.

~~~
panic
_> There's also the search selection (command-E), which is pretty much only
usable for moving the selection to the search box._

In most apps, Command-E followed by Command-G will search for the selected
text without even going through the search box!

------
mnd999
I can absolutely relate to 4). Getting kicked out of the graphical environment
every time sway crashes is frustrating enough for me to abandon it at least
until 1.0.

The Nvidia issue is also annoying, why it has taken so long to resolve is hard
to comprehend.

~~~
mbrumlow
They say and wlroots off master. I have only had a single crash, and that was
many months ago.

I do keep it fairly updated.

~~~
lapinot
I do have a sway crash every week or so, next time it happens i'll try to
investigate. Nothing unbearable tho, the upside of running new software is
seeing the edges getting softer (and sometimes helping with that process).

------
rwmj
Until Wayland supports X-style remoting of applications, I literally can't use
it, so here's hoping X remains an option for a long time to come.

(Edit: Or Wayland implements X-style remoting which would probably be the
preferable option since in other respects such as client-side rendering using
the GPU Wayland is cleaner)

~~~
Sir_Cmpwn
>Until Wayland supports X-style remoting of applications, I literally can't
use it, so here's hoping X remains an option for a long time to come.

Xwayland supports X forwarding, so your existing forwarding setup will work
fine OOTB. What's missing is forwarding native Wayland applications, but if
everything you use today works on X11, it'll work on a Wayland compositor via
Xwayland too.

------
IshKebab
> Network transparency allows you to run an X11 application from any computer
> on your network and display it on your local computer.

This is a rubbish point. Remote X may work OKish over a wired LAN, but over
anything else it sucks. Not even NX uses the X11 protocol any more.

Honestly the only reason people even use it over a LAN is because VNC is so
archaic and nobody has written a modern version. Wayland actually makes that
_easier_ though.

The point about crashing compositors is good though. Windows can handle a
crash in the graphics driver seamlessly. I don't think any Wayland compositors
can come close to that.

~~~
welterde
Applications that use X11 properly don't just work OKish over wired LAN, but
work good enough that you can't tell it's not running locally..

One usual workflow is to ssh into a data reduction machine, do some reduction
task and inspect the data products without having to copy them to the local
machine or use NFS or the likes to access the files.

~~~
delian66
What is a data reduction machine?

~~~
welterde
In my case a few beefy servers (lots of cpu cores, ram and disk) that are
dedicated to the purpose of running data analysis/reduction on them.

------
crsmithdev
> You can achieve pretty much the same isolation as Wayland on X11 with
> cgroups and Xephyr.

Wait, you mean I could get something _almost_ as good just by adding in two
additional technologies to the mix? Amazing!

~~~
giornogiovanna
Adding just one application (Xephyr) is a whole lot easier than replacing X,
though. It's probably worse for isolation, but it's also probably good enough.

------
Hello71
Several points made in this article are false, misleading, or complete
horseshit.

1\. > Except the fact that Wayland is based around libinput, which is trivial
to record key events from.

This is complete horseshit. You cannot "record key events from libinput",
because libinput merely _processes_ key events from evdev in the kernel,
received via /dev/input/event*. This is exactly the same as on X.

2\. > Wayland’s compositing protocol is basically designed from the ground up
to require the kind of closed-source, blob-filled graphics driver from AMD or
Nvidia

This is malicious FUD. sway's authors have specifically and repeatedly stated
that they explicitly do not support AMD and nVidia proprietary drivers.

3\. > Network transparency ... allows you to run something like a Web browser
on a more powerful device while running X11 locally

This is true but misleading. If you actually try to run a modern web browser,
you'll find that the experience is usable but extremely poor. The graphics are
ugly, it's slow to respond, and videos don't work properly.

~~~
swiley
Re: 3

A lot of people keep saying this about X apps but anything written with GTK
will be awful because (from what I understand) it’s just paints everything
itself and then uses X11 to actually display what it draws. Plus if you run
anything over the network like that GLX doesn’t work.

My main two personal complaints with wayland is that writing simple programs
without widget libraries is much harder and that the window management is
handled by the app (which IMO makes absolutely no sense but maybe there’s
something I’m missing, which isn’t crazy since the last time I messed with it
was a year or two ago.)

Until those two things get dealt with I’m unwilling to use it.

~~~
jcelerier
> A lot of people keep saying this about X apps but anything written with GTK
> will be awful because (from what I understand) it’s just paints everything
> itself and then uses X11 to actually display what it draws. Plus if you run
> anything over the network like that GLX doesn’t work.

I don't find that to be true, e.g. I've used pavucontrol (a GTK3 app) over the
wifi X11 networking and it worked fine - the very nice thing with X11
networking is that it will use your _client_ DPI for rendering / Xresources /
etc... so you can have both lo-dpi and hi-dpi clients connecting to the same
machine and it works for both without any configuration.

~~~
posix_me_less
Wow, you got audio playback working over network X11? How did you do that?

~~~
jcelerier
no, i'm running on my laptop a remote instance of pavucontrol which controls
the volume of my mediacenter (on which the process effectively runs) - no
sound data is being transferred, only volume changes. (though I've also used
pulseaudio-dlna to cast audio over the network from linux very easily)

------
est31
So wayland is just a waste of time or what? Why are the Wayland maintainers
doing it then? To hurt users? I don't get it, sorry.

~~~
Hendrikto
Obviously not, but it is not the solution to all problems, that people make it
out to be, and still needs a lot of work.

~~~
sverige
And really, X11 isn't that bad. Or at least xenocara on OpenBSD, which is what
I'm most familiar with and which has addressed some of the more glaring
problems.

------
ryu2k2
Why do we need the power of GPUs meant for fast and complex 3D graphics
applications to draw 2D text, lines and icons?

~~~
pasta
Because 3D is just an extra dimension for the same calculations?

The GPU does not accelerate 3D, but the computations (so 3D can be much
faster).

~~~
zozbot123
Many graphics cards/chipsets/etc. do accelerate 2D operations, unfortunately
there's no feasible _unified_ model of a "2D hardware accelerator" the way
there is with 3D, so there's no unified support for it in kernel, either. The
whole thing is inherently hardware-dependent.

~~~
vetinari
Not anymore; at least not like they used to in 90's and 2000's. Today, they
expose some overlays (and some limitations, how they can be used) and that's
it.

There is a Nvidia OpenGL extension NV_path_rendering that was intended for
accelerating 2d, but it wasn't widely adopted.

------
7e
The most glaring deficiency so far is lack of support for the binary NVIDIA
driver in most implementations. The whole affair is rather childish.

~~~
ddevault
The lack of support for standard Linux APIs in the NVIDIA driver, you mean.
You're asking compositors to implement this:

    
    
        if (nvidia proprietary driver) {
           /* thousands of lines of code */
        } else {
           /* thousands of lines of code */
        }
    
    

We cannot debug the proprietary driver. We cannot fix bugs in the proprietary
driver. We cannot read the code to understand it's behavior.

Our answer: "no".

~~~
nmikhailov
> Our answer: "no".

Good thing you are not speaking for KDE and Gnome then.

~~~
lasagnaphil
But KDE and GNOME are quite large organizations which gets financially
supported by many tech companies. And they seem to have closer connections
with NVIDIA engineers compared to sway and wlroots. I've even heard that
NVIDIA was directly contributing the EGLStream backend code for Gnome and KDE
(see the links below)

[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-B...](https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-
Better-EGLStreams-Mutt)

[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-K...](https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-
KDE-KWin-EGLStreams-POC)

It's pretty sad that compared to this, sway and wlroots are being completely
neglected by NVIDIA. And I think that is precisely why the sway project
decided to ditch proprietary NVIDIA driver support.

------
zozbot123
So far, Wayland is removing legacy cruft and replacing it with newfangled
cruft. The Wayland protocol itself is not even well specified in the way that
X is - the whole thing is _very_ far from true maturity. Just like, e.g.
Pulseaudio, which is apparently now getting replaced by Pipewire.

------
cat199
... beware the GNUluminati

