Hacker News Reader

This a Linux thing.

Essentially, in an operating system you need a way to "draw" things on the screen. And a way to properly "move" the boxes "draw".

Previously, the usual* way to do that was using XServer (XOrg). Now you would imagine that the server would take commands from applications, and would draw them. But it was the inverse (for various historical reasons)! However, the most egregious thing was that it ALWAYS ran as root. And while tries had been made to reduce the attack surface, it had to fundamentally change (I am skipping over other parts related to performance, scalability, or future proofing).

And that's where Wayland comes in, and literally flips the whole thing on its head. Now the issue is XOrg has been around for maybe 40 years or more ! And that was not going to change easily. Distros did their absolute best to allow double use, but adoption grew very slowly. Eventually, supporting and testing for two envs will grow complicated.

Anyway long story short, almost everything about Wayland is better IMO, actively supported and is the future. But migrating to it has been complicated because they were undoing 40 years of habits, hardcoded bugs that grew into features, and had to come up with new testing.

This is something I typed up rather quickly so please take a peek at the Wiki page for Wayland you will find a much more complete history

> However, the most egregious thing was that it ALWAYS ran as root.

That hasn't really been a thing for over a decade now. As a decent metric, https://wiki.ubuntu.com/X/Rootless says Ubuntu switched to rootless by default for most drivers in Lucid==10.04

This is about how Firefox, KDE, any app you run draws to the screen.

In the old world, they talked to an X server that implemented the X protocol. It's not KDE drawing stuff to your screen, it's X, but KDE is a little special in that it can move windows around and draw title bars and borders. This is called a window manager.

Two big issues with X, this was defined in the early 90s by a consortium of Unix vendors and is somewhat of an overly complicated nightmare.

It's also a security nightmare, any app can snoop on any other app.

Wayland is an attempt to simplify things. The server, called a compositor, is much simpler and is implemented as a library, usually by former window managers that now actually handle drawing stuff to the screen. Applications can no longer snoop, they must ask permission.

If you run an older app designed for X, it uses an almost invisible compatibility shim called XWayland, basically a tiny X server that takes in X draw commands and converts them to Wayland ones. Firefox enabling Wayland support means that on most modern systems, it no longer has to use this shim.

Wayland is a step forward for desktop Linux, but like any big change there are some annoyances. The asking for permission model means things like screensharing tools or apps that do weird shit like macros or capturing keystrokes need to be updated to ask permission. Nvidia didn't really support Wayland well until very recently because they got into some weird argument about driver APIs that took years to resolve.

Wayland is a piece of the linux desktop software stack. If you're on a Mac or Windows, it won't mean anything to you. Linux historically has used X11 for drawing the desktop. Wayland is a replacement for X11. It's big news because it's been a long time coming, and fixes a lot of longstanding issues. Unfortunately it also creates some new issues (screen sharing, hot key apps, etc), but they're being actively worked on and are very close to being completely solved.

> it also creates some new issues (screen sharing, hot key apps, etc), but they're being actively worked on and are very close to being completely solved.

I swear I've been reading this for a decade.

Screen sharing has been solved for years. Just some apps didn't bother with updating.

To offer the opposite viewpoint, I swear I've been reading for decades that X11 would fix old issues. My last experience of X11 (less than a decade ago) had me using vi to edit a configuration file to add a line of text to enable some sort of magical feature to stop screen tearing. I've been using BSD/Linux since the late '90's and this issue has persisted for over 25 years.

Wayland meanwhile actually has 99.9% of what you need working today not 25 years from now. There's some bits and pieces already progressing well and likely to be fixed in the next few weeks/months/years and not 25 years in the future. Very different situation to X11, IMHO.

At least screen sharing has been solved. We are mainly waiting for apps that use sharing to implement the Wayland compatible to get access to screen recording.

I only know it as the thing that broke all my screen capture tools because none of them had implemented the necessary changes the last time I tried, admittedly small N years ago.

This is how most of us casual linux users learned about Wayland.

To be fair, for such a huge change to how we use Linux on the desktop, worst things could have happened.

Yeah while Wayland still has some warts it seems like people say "I don't have proper color management on Wayland" with the same enthusiasm "This GNOME Wayland session crashes on boot" from a nearly a decade ago.

This Plasma Wayland session crashes (in my GPU driver):

- 3 years ago

- 1 year ago

- 6 months ago

The biggest issue I have with Wayland is that it requires a lot more out of a GPU than a framebuffer, and my experience with video drivers on Linux is that they are very buggy and not maintained for very long.

I have an older computer that I can run Xorg with compositing disabled and firefox with GPU rendering disabled. As far as I can tell I will never be able to run Wayland on it without changing the GPU.

Similar issues with some ARM based SBCs; they have varying levels of stability in their graphics acceleration capabilities, and often only on a very old kernel, but I can get a reliable framebuffer on mainline.

Wayland in itself has no special requirements on the GPU; it needs standard kernel support (KMS, dmabuf). EGL is optional, for both compositors and apps. Mutter and Sway can both happily run in QEMU framebuffer.

Is it possible to force wayland to not use EGL on a card that ostensibly supports it? That would fix so many of my issues.

Have you tried LIBGL_ALWAYS_SOFTWARE?

I have not; thanks that works, I'm writing this reply from Wayland right now!

Screen capture works with the built in tools. What isn't guaranteed to work out of the box is screen sharing apps.

I think this is a problem with any highly specialized or technical topic. I vaguely recollected what wayland was, but I didn't know why I would care about it and ended up doing similar googling before realizing this news will not matter to me outside of a general technical curiosity.

I encounter the same thing when dealing with code reviews as well - people love to document the WHAT or HOW of things, but rarely if ever consider talking about WHY it matters, or WHO it matters too.

To borrow from a favourite corpo speak: answer the "so what" for the reader to make something actually useful to more people.

Wayland is a replacement for X11 which is now ten or more years old and still not feature complete. It will be the future of all graphical interfaces, or maybe we will still be running X11 with extensions in 2050.

I remember when GGI[1] was the future of all graphical interfaces. Remember GGI? 1994-2007 RIP.

Wayland looks a bit more likely to achieve its goal, but we'll see. For my part, it'll take a long time yet before it's worth the hassle to consider switching.

[1] https://en.wikipedia.org/wiki/General_Graphics_Interface

On a modern computer, programs that wish to draw on the screen do not interface with the hardware directly (aside from games). Instead, they communicate with another program that does the drawing on their behalf. This other program is called a "display server", a GUI program such as Firefox is a "client", and the details of the mechanism by which they communicate is called a "protocol".

Until recently, "Xorg" was the main centralized implementation of a display server on unix-likes, and any program wishing to display graphics had to speak its native protocol, "X11". Now many systems run display servers which speak a new protocol, "Wayland"[note]. While a compatibility shim does exist (XWayland), ideally a program wishing to display graphics on such a system should do so using the new protocol directly, for better performance and features.

Porting an application to a new graphics backend obviously requires some effort and testing. Until now, out of an abundance of caution, Firefox simply spoke the old X11 protocol by default, even when running on a new Wayland system, relying on the XWayland compatibility shim. Now Firefox is essentially announcing that they believe their Wayland backend is robust and complete enough to enable by default.

I hope this helps!

[note] the nature of Wayland is such that there are many implementations of such servers, not just one main one like with Xorg. This is because the semantics of the Wayland protocol have taken over some of the functions previously handled (on X11) by a separate piece of software, called a "window manager", which contributed heavily to the look, feel, and behavior of a particular desktop GUI. Thus, while Xorg was agnostic and could be shared by different GUIs, with Wayland each GUI system must implement its own display server.

Thank you!

>This is because the semantics of the Wayland protocol have taken over some of the functions previously handled (on X11) by a separate piece of software, called a "window manager", which contributed heavily to the look, feel, and behavior of a particular desktop GUI.

Window managers can be separate with Wayland too. It just seems like the Wayland people don't want to unify under one implementation and have separate window managers.

In practice, I'm not aware of anyone trying to write a compositor for wayland that doesn't include the window manager (other than xwayland, I guess).

This is because unifying the display manager, compositor, and window manager allows for each implementation to be far more integrated. For example, this opens up the door to virtual-reality or mixed-reality Wayland display managers, that can run desktop apps without the usual overhead of screen capture. Xorg can't do that. Trying to make Xorg do that will only end in misery.

Being much more integrated isn't actually that valuable. VR compositors already render a full screen frame that goes straight to the display. The window manager for VR is typically in a separate process from the compositor.

You could add Wayland support to an existing VR compositor, but that wouldn't force you to combine the window manager into the same process.

Excuse me, but try to actually use any VR window manager, today, on an OS like Windows. It will bog down and eventually crash your GPU when you open too many windows, because it has to capture those windows from the regular desktop. A Wayland display manager on Linux would not have this issue, because it would already be the window server, so it wouldn't have to perform any extra captures. I only know about this because I have experience trying to do this exact thing.

Wayland would have the same exact problem as you described if it was implemented by copying a window's surface to the surface you are submitting to the compositor.

The solution in both cases is to just submit the original surface to the compositor.

>I only know about this because I have experience trying to do this exact thing.

Did you use Windows Mixed Reality? If you want deep integration with the operating system, you should use the implementation that is part of the operating system.

> Wayland would have the same exact problem as you described if it was implemented by copying a window's surface to the surface you are submitting to the compositor.

Sure, but as far as I can tell, Wayland seems to be the only architecture that would allow you to not do this. Windows does not hand you the original surface. Xorg does not hand you the original surface. But if you are the Wayland display server, you have the original surface because you're the one who created it. So if you start drawing to an HMD, you can place existing windows on it with no extra overhead.

> Did you use Windows Mixed Reality? If you want deep integration with the operating system, you should use the implementation that is part of the operating system.

Yes. I do use Windows Mixed Reality. Which does not support opening desktop windows into the virtual space; it only supports mirroring an entire display onto a surface, and not even capturing individual windows. For that purpose I tried XSOverlay and OVR Toolkit running on SteamVR, which have that capturing issue.

>Wayland seems to be the only architecture that would allow you to not do this

All modern operating systems use this same architecture where apps render into a texture which the compositor can use. Wayland is not unique in having applications just render to a surface which the compositor composites into the final ouput for the display. We have been doing things this way for decades. Saying that xorg cannot do it doesn't mean much because xorgs design is bad and decades behind. This ability has nothing to do with why wayland compoaitors have a wm built in instead being able to easily interface many different ones.

>Which does not support opening desktop windows into the virtual space

Look at this video. He has blender open without mirroring a display.

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

> All modern operating systems use this same architecture where apps render into a texture which the compositor can use.

I know, but Windows does not allow anyone to just have that texture, AFAIK.

> All modern operating systems use this same architecture where apps render into a texture which the compositor can use.

...I'm going to have to try that. You can even use your mouse with the HMD? I didn't expect that.

Edit: Okay, I've tried it.

- You can open some small portion of your desktop apps in WMR, but nine times out of ten they are just going to ignore WMR, and open on the actual desktop instead, giving you no feedback whatsoever.

- The apps that you can load often don't work properly, for example the File Explorer is a completely different version that doesn't allow you to actually view decently sized thumbnails of anything, nor open them in any sort of photo viewer.

- Once something is on the desktop, it's impossible to get it into WMR. You can only use it through the desktop view. So, apps that can't open into the WMR environment (i.e. Discord) will be impossible to view or interact with from WMR.

- WMR has this delusion that all windows have to be perfectly vertical, so it's impossible to use the headset while laying down, because a mouse cursor doesn't have enough degrees of freedom to communicate that a window should be tilted. (But even using the controllers has this issue.)

But hey, at least it seems not to have that window capturing problem. If you can bear the fact that nothing actually opens, and nothing that does open even works.

This is a -terrible- solution.

It's a very long story, but yeah, its about how the applications on your desktop can draw content inside their borders, and how those applications interact with things like keyboard/mouse/other applications drawn on the screen. One of the big things is that X11 was written for a time where everything was open with no access control. Any application can view any other application, or capture any keystroke. Wayland introduces a form for permissions control, which has been a huge ordeal to both pave the path for and to design and figure out how on earth that should work. It's great though that you can have some actual control on who can listen to keystrokes and not.