> A unified way to change applications settings.

This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings

> because the X server takes care of most of the stuff. ... , unless using a big library like wl_roots.

So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing?

> A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps.

I don't get this point. You can still use Cairo or similar graphic libraries on wayland too.

- I've never seen xrdb used outside of terminal configuration

- You have to link against X11, dwl (dwm for Wayland) implemented in 2500 LOC [1]

Plan 9 /dev/draw is simpler yet, somehow it was not reason against X11.

[1] https://github.com/djpohly/dwl

> The simplicity of the window managers, hotkey daemons and other X clients. You can implement a functional wm in a few hundred lines of C[1] because the X server takes care of most of the stuff. In comparison a compositor has much more work to do and it's difficult to implement one, unless using a big library like wl_roots.

This sounds like they simply extracted some of the work X used to do into an external library. That sounds like an excellent choice with no particular downside IMO?

The beauty of free software is that X will always be there for anyone who wants it, just like you can still get great distros without systemd.

I am a happy Wayland user, and have been for a long time. There are many more out there. You don't often hear us because we don't spend every waking hour shitting on Xorg and praising Wayland for how good it is (maybe we should?)

>I wonder if it will ever reach the adoption level of x11

It will, considering that Xorg is effectively no longer maintained and its developers have switched to working on Wayland protocols long ago, which they have stated on multiple occasions.

Somehow I doubt that the loudmouths you often hear will step up to maintain X.

> and I haven’t heard anyone singing it’s praises yet about how happy they are to use it

As is often the case, people are much quicker to go to forums to complain about issues than to sing praises so I'm here to add a data-point trying to balance the scale.

I've been using Wayland for a few years now and it does everything I need it to do. I understand that everyone has different needs and maybe it doesn't work for everyone, but then again, neither did X11.

Some of the things that work out of the box in Wayland which didn't work in X11:

- proper HiDPI and mixed DPI support (e.g.: you can finally move windows from one screen to another in mixed DPI setups and everything scales properly)

- variable refresh rates/FreeSync (for all apps and all screens)

- no more tearing

- no more hot-plugging issues

Besides security concerns, mixed-DPI setups are such a major pain point with X11 that many people who use a laptop with additional screens would probably switch to Wayland just for that alone. That's a large demographic.

> I don’t know how I feel about Wayland.

Me neither. On the one hand I switched over 2 years ago and it worked fine for the most part, there a still a few things missing. One of the things were headless displays and it seems like there will be something like that in GNOME 40 - though probably experimental.

What bothers me most is that innovation is so difficult. Everything needs to be standardized first and then implemented in all different desktops like KDE and GNOME each in their own way. And this process is extremly slow. Back in the Xorg days many cool programs were made by independent users (for sceensharing, automation etc.). Writing a new Desktop or porting over one from X is almost impossible, were it not for wlroots. I wonder if we are not sacrificing too much in the name of security (OK an evil program can not keygrab and control other windows, but it can still read all my SSH keys etc.).

If Wayland doesn’t replace X11, then something else needs to show up, or we drop the idea of a Linux/BSD desktop. X11 is pretty much abandoned as this point. It’s only a few RedHat engineers who are doing minor patches and no one want to manage the future releases.

I've been running Wayland for a few years now, and while I wouldn't say I've had a _perfect_ experience, I don't think I've had a time when logging out and trying an X session worked any better.

X has always had niggles, which I don't miss.

So right now, it's very much at the same level as many other system features: consistently works, and maybe the reason I'm not singing its praises more loudly is because I've come to take that for granted.

> I haven’t heard anyone singing it’s praises yet about how happy they are to use it

to benefit from every feature one has to run current software, as the ecosystem catches up. And as others write, AMD/Intel gfx have a better time than if you're on Nvidia.

Wayland as of writing has my use-cases covered: hw accelerated video decode in Browsers (FF and Chrome), Browser screensharing (via pipewire) and via VNC (conveniently surfaced to gnome-settings if gnome-remote-desktop is present). Most current distributions do not carry all necessary packages in their defaults last I checked, so one had to have some interest and flip one or two browser config flags.

> I haven’t heard anyone singing it’s praises yet about how happy they are to use it.

I'm no expert on either X11 or Wayland. But I can tell you that happy people are usually silent while unhappy people are noisy.

> they more than anyone else know why they would need to start from scratch over improving x11.

That's not what they actually say though:

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. "

Again, they literally say "It's entirely possible". They just didn't want to.

> ... over improving x11

They have literally been improving X11 for several decades.

What's with IBus and IBus-centric IME switching being sub-optimal for better part of past decade or so[1], yet being pushed from non-CJK regions? Usually I don't even GNOME and just go with whatever fcitx plays with, so not an issue for me, not angry or anything but curious what's happening "up there" consistently[2][3][4].

1: https://cpplover.blogspot.com/2013/10/ibus-15_21.html

2: https://uwabami.junkhub.org/log/20210224p01.html#p01

3: https://uwabami.junkhub.org/log/20210312.html

4: https://lists.debian.or.jp/pipermail/debian-devel/2021-Febru...

ibus works with Gnome out-of-the-box. On sway/wlroots, you will have more luck with fcitx. I don't know which tool works best with KDE.

It's not a Wayland problem, ibus does not work in KDE even on X11.

re:ydotool. More than risks, I would say the author constantly changing things without testing and breaking the tool is what made me stop using it. I wrote my own version using evdev and never looked back.

Yes. I currently run it besides Pulse for screen sharing and there are no issues. I haven't replaced Pulse yet because it didn't work right away, but plan to try again eventually because Pipewire supports HFP, the less terrible Bluetooth headset profile.

The next version of fedora uses pipewire instead of pulse audio. From all the people I have seen test it, they said it works much better than pulse.

I've replaced pulse with pipewire and that has been seamless. The experience is generally determined by how well the distro supports moving from one to the other rather than any maturity issues with pipewire.

I've retained jackd instead of using pipewire's implementation because I don't think the pipewire version supports transport control or timecode.

It's not perfect but mostly works.

The question is flawed, but I get what you mean.

Wayland the protocol has very little to do with graphics drivers (it's just about getting window content to compositors). It's just that the display server (X server or wayland compositor) uses a set of agreed upon kernel APIs (DRI) to render and display things on the screen, which Nvidia refuses to fully implement (GBM vs.EGLStreams). The X server has extra code to support this, but many wayland compositors don't. Semi-recently Nvidia (in the form of Erik Kurzinger) has started contributing such special treatment code to Gnome and KDE. A major hold out is wlroots, the maintainer of which refuses special handling code for proprietary components (https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html), but recently there has been a 3rd party contribution for an EGLStreams backend.

Additionally the Xwayland team are right in the middle of merging code to allow specific acceleration of XWayland windows and Nvidia and the wlroots team are working on building a new memory allocation solution based on Vulkan that will hopefully finally solve the EGLStreams debacle once and for all.

So: It kind of works and is improving fairly rapidly.

Yes, but the patch by Erik Kurzinger from Nvidia may soon be merged [1].

It still requires changes to Nvidia's proprietary drivers that I think have not been done, but it maybe that this year it will be settled.

Edit: Also it maybe that the Ubuntu choosing Wayland maybe what pushed the Nvidia forward? [2]

[1]: https://www.omgubuntu.co.uk/2021/01/ubuntu-21-04-will- use-wayland-by-default

[2]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

The short version is "it depends". Essentially, each separate Wayland compositor needs to add support for the nvidia driver (or the driver needs to support more standardized APIs).

Gnome and KDE support Wayland on nvidia hardware (though it's a bit rough around the edges). Wlroots (and therefore Sway) doesn't because they don't want to have a separate code-path for one driver which doesn't want to support standards and because the APIs the driver does support wouldn't work well with the code model of wlroots.

I don't expect them to ever work properly. Basically, if you care about good Wayland user experience and proper desktop integration, you should be using AMD or Intel GPU already.

Waiting for Nvidia to fix this mess is pointless. Nvidia will be DOA as long as they refuse to upstream their driver or to support Nouveau to begin with. And they didn't show any interest for years.

I believe with the 470 driver series that's coming out soon things are looking a lot better[1][2].

[1] https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...

[2] https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...

Not exactly. I m successfully using Fedora SilverBlue with proprietary nvidia in Wayland. In the official docs it's not supported but Mutter (from Gnome) has the pieces in place to do so. However I don't use anything too specialised that would force me back to Xorg. For example I did revert to Xorg while I played around with lutris a bit. Still as long as distro maintainers don't declare official support, be ready to expect surprises.

It works but the experience was suboptimal. Usable but much slower than x11.

Nvidia is basically dead at this point, no support for standards that have been around for years. And now they are including malware in their cards to slow down unapproved calculations.

Flameshot for screencapture and the standard gnome extension clipboard manager work pretty well for me on Wayland.

Cant say anyting about screensharing with Screens.so. Zoom works though.

Ive been a happy Wayland user since 2017 or 2018, not entirely sure.

Here you go: https://kurisu.shibumi.dev/share/img-2021-03-27-21-02-41.png

This is a screenshot from my current system.

* btw it's my first post on ycombinator lol..

Of what would you possibly want a screenshot here?

It is about the under the hood plumbing so take any screenshot from the last years, copy it and write "this is what it looks like under wayland".

Unsure if this is a low key jab at Wayland breaking screenshot tools ...

The book has no pictures?

It's sway. So that's what it looks like.

And the content is much deeper than showing off the color scheme you chose.

It fits with the culture of working in VT-100 in the 21st century.

Yes, there is: Through Pipewire (xdg-desktop-portal), wlr-screencopy (wlrobs) or a virtual webcam (wf-recorder) :-)

Pipewire has the brightest future long term, but wlrobs seems to be the easiest to get started with if "Wayland" means wlroots based compositor (Sway, Wayfire, etc) in this instance.

OBS is working already with wlrobs.

https://hg.sr.ht/~scoopta/wlrobs

I'm using https://github.com/greshake/i3status-rust which also works well with Sway.

I use Waybar.

You can run applications over the network with (edit: waypipe, not pipewire, I mix up the names every time), which works quite well. Technically it's not "transparent", but it isn't on X either because pretty much 0 UIs today draw themselves using X11 primitives, they just draw their own buffer and get X to display it.

This isn't really an answer to your question, but under Gnone3+Wayland "ssh -X" works as you might expect. Which amazed me at first, because I wasn't expecting it.

Turns out it's because most applications are X11, Wayland supports X11 applications via XWayland, and X is doing network transparency like it always does.

I don't think network transparency is a goal for Wayland. X11 network transparency was awesome in the late 80s and early 90s. In many universities, there would be rooms of X11 terminals that connected to the "big machines" in the server rooms- and you could have each of your applications, even even the window manager itself, all being run on different machines.

This made sense when an institution would license software for their big iron, and when desktop computers weren't nearly as powerful as they eventually became during the 90s.

But most people gave up on it right around the time that Netscape Navigator, with its very bitmap-heavy UI gained traction. The X protocol really wasn't designed around this. Extensions helped, but not enough.

I bet the vast majority of people using X11 today have never run a remote X11 client.