- A unified way to change applications settings. All old X apps used to read the X resources database (xrdb): you could set a global color scheme, fonts, window geometry and what not, all in one place using a simple but powerful text format.
- 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.
- A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps. This would make writing a simple application without importing huge frameworks feasible again. Also sending the drawing calls over the network would probably be less bandwidth intensive.
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.
There is big difference in responsibility w.r.t. users in Xserver vs wl_roots case.
In the X11 case, relations are:
wm - user - X11
(Users choose to use Xserver and WM independently, if there is a bug in Xserver, then it is outside of responsibility of WM developers.)
In the Wayland case, the relations are:
user - wm/compositor - wl_roots
(Users choose wm, wm developers choose to use wl_roots to implement wm features instead of doing it themselves, but that is just internal implementation issue of that wm and wm developers are responsible for wm behavior/bugs including ones inherited from wl_roots.)
That's why I said Wayland and the modern desktop in general.
> So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing?
You're kind of right: conceptually it's not much different, except that a wm is not a full-fledged server, but simply a client talking to the X server. If I'm sloppy and my wm dies, it's not going to take down the whole desktop with it, contrary to a Wayland compositor.
> A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps.
Of course, but the rendering happens on the client (with client-side fonts, images, etc.) instead of the server, which makes the protocol use a lot of bandwidth.
- 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.
Terminal and Emacs are the two I'm using it for.
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?
I understand apps are breaking because they relied on features of x that were security risks but it doesn’t seem like Wayland provides a safe or convenient alternative to the way apps were doing things before.
I wonder if it will ever reach the adoption level of x11
>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.
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
I mainly use Linux so I don't know, but one of my work laptops have windows on it and it freaks out every time I connect it to a 4k monitor.
At least in linux I can use triggers and xrandr [1] to manage it even if it's not pretty, never figured out how to do it automatically in windows.
Edit: I am using KDE/Qt apps for 99% of my gui stuff. Gnome etc might be worse.
[1] http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/#therandrway
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.).
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.
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'm no expert on either X11 or Wayland. But I can tell you that happy people are usually silent while unhappy people are noisy.
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.
They have literally been improving X11 for several decades.
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...
But the truth is that I don't have time for all that in 2021. When XFCE supports Wayland and I get a good experience out the box, I may stop using X11.
Pipewire is showing up all over the place. I've been reading a little about it, but I finally got a comfortable setup of jackd and pulseaudio and am worried it might interfere with my stable setup.
Am I being paranoid?
I've retained jackd instead of using pipewire's implementation because I don't think the pipewire version supports transport control or timecode.
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.
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...
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.
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.
[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...
As of this morning's Nvidia's market cap ($320B) is bigger than AMD's ($100B) and Intel's ($255B).
Cant say anyting about screensharing with Screens.so. Zoom works though.
Ive been a happy Wayland user since 2017 or 2018, not entirely sure.
This is a screenshot from my current system.
* btw it's my first post on ycombinator lol..
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".
I adopted most of my tools by looking at other people setups and customizing them to my use case.
It's sway. So that's what it looks like.
And the content is much deeper than showing off the color scheme you chose.
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.
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.
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.
