Write a Wayland Compositor [video]
streaming.media.ccc.de
streaming.media.ccc.de
Although I do understand the value of the current approach in the industry (i.e. MVP), I think it does come with a cost - you get a large corpus of low density code that gives a lot of surprises in many different corners. Redhat-funded projects are really leading this trend (I'm looking at you systemd, the project). If you read their code, you'll instantly notice that they are becoming more and more labor-intensive, and less and less hacker-friendly. We are losing smartness for the sake of grunting.
Some might think Wayland is a smart approach, but it's actually not. It's mostly just pure grunting - a showcase of large engineering horsepower. It's a large-scale refactoring & optimization of the modern day X11 desktop ecosystem. Everything works in the exact same way, but things happen in slightly different places, and some features are banned by policy (arbitrarily outlined by wayland devs). These missing special features now need to be implemented explicitly as "protocols".
Now, I really want to ask - where are we heading here? Are we really stepping forward? I don't think so. We're just going side ways.
But I plan to write my own wayland compositor, probably based on linux dma-buf, like the one running on the steam deck (basically an improved fork of valve one).
And in assembly, x86_64 at first, but I am lurking on risc-v.
Current Nvidia drivers support GBM, and thus should work with wlroots. Their status of unsupported mean that the wlroots maintainers cannot help if it does not work as they cannot debug a closed source driver, making it impossible to see what might be wrong.
General improvements that help nvidia compatibility are accepted though if other's identify an issue.
Because nvidia drivers traditionally didn't provide APIs that sway and other wayland compositors expected (drm, dmabuf, atomic) and tried to do it's own things (EGLStreams). For compositors it meant to have to code paths, one nvidia-specific and another one generic. Some compositors implemented both, others implemented generic only.
For comparison, it would be like complaining that Windows/DirectX games do not run with a GPU that doesn't come with DirectX driver. Well, duh.
However, Nvidia signaled a u-turn, that they are going to be more cooperative. How and when, well, it remains to be seen.
It is still unsupported though as wlroots only actively support open source video drivers.
(Improvements to Nvidia support is accepted, if it is a general improvement and not just a hack around a driver bug.)
And that's why linux on nvidia is doomed.
Maybe it will be better one day: They are (also slowly) moving in the right direction though, and nouveau might be revived by taking some bits from their new (barebone) kernel driver. But until then, swear your allegiance to the GPU vendors that play nice.
Next I'll just install xserver. A menu is clutter.
All the block diagrams prominently putting systemd-logind between X11/Wayland-compositor are very misleading, and seems likely to create more misinformed ire for systemd.
systemd-logind is basically just an arbiter of the seats for reasons like you can only have one drm-master on a given drm device at a time. It's not involved in all X11/Wayland-compositor<->kernel interactions. Once the seat has been acquired it gets out of the way. That should not be some huge box right in the middle of the two.
You can trivially confirm this by stracing systemd-logind on your system while interacting with your desktop. It's just sitting idle in epoll_wait().
Imagine multiple kiosks in a train station/airport running off a single box in a corner. Or a library with a dozen monitors+keyboards hanging off a single box. Consumer PCs are so powerful these days it's quite practical to do such things, at least in terms of the hardware.
*NIX has historically cared about such multi-user use cases, and Linux/Libre software specifically has proudly facilitated making more use of our hardware vs. being wasteful by forcing purchase of more machines through superficial software limitations. The entire era of shared web hosting that arguably made Linux a commercial success throughout the 90s and early 2000s was a product of hosting more customers per less expensive commodity PC.
* I've yet to see any actual, honest to god benefits for the end user. Literally everything I've seen is the fact that it makes development easier for the wayland devs and harder for literally everyone else.
* Trying to use a wayland window manager outside of gnome or kde leaves you reliant on a bunch of hackish utilities (redshift, taskbar, screen recording / sharing, etc) which are available on AUR and basically no where else
* Scaling and perf for xwayland apps (i.e. most apps) is pretty bad.
Is wayland the future? Maybe, but I'll happily use xorg for the next decade if needed until the user experience is rock solid over on wayland.
You can see some small benefits in GNOME like movies still playing while window switching, nice shadows, no more tearing, etc. but honestly who cares but aesthetes. None of this was in popular demand. The security is nice but when was that ever exploited in the wild? Mostly I see downsides, like now there's multiple ways (or no way in some compositors) to dim screens...
I'm sure eventually we'll get all our features back but for now it's mostly a bunch of small irritations that add up.
Someone building the next Apple might care.
If Wayland improves movie playing under GNOME, then it solves a GNOME bug, not an X11 bug.
I think that it counts as a mainstream WM.
X11 is very far from an ideal graphics system and I would like to see it replaced by a better system, which would still have to also implement the X protocol for the legacy applications.
Nevertheless, I have not seen any argument yet that would indicate that Wayland is the appropriate replacement for X11. On the contrary, some of the ideas on which Wayland was originally based were definitely wrong and they have shown that the Wayland developers lacked experience about how many computers are used.
Even if a part of the initial mistakes have been patched meanwhile, that lack of vision at the Wayland origin makes me skeptical even about the quality level of the Wayland parts about which I do not know anything.
Are you using fractional scaling (or different scaling values per monitor)? Does vsync work? How about the scrolling stutter at high refresh rates? And if you want to use variable refresh, you have to disable/unplug all the other monitors and reboot.
Vsync works, but I must choose with which of the monitors.
For about a decade, I have used only 4k monitors, even starting with the early models that were seen by the computer as multiple monitors, because HDMI and DisplayLink could not carry 4k @ 60 Hz on a single link at that time.
Nevertheless, I still cannot understand why would anyone want to use any kind of "scaling" in relationship with a monitor.
Any kind of "scaling" is guaranteed to generate sub-optimal images.
The correct way to deal with monitor resolutions is to set for each monitor the appropriate dots-per-inch value, depending on the monitor size and resolution.
With the right DPI value, all typefaces and vector drawings will be rendered beautifully. Scaling is never needed per monitor, but only per window, either for the windows containing bitmap images, i.e. pictures or movies, or for the windows that contain GUIs implemented by incompetent programmers in Java with typefaces sized in pixels, instead of using scalable typefaces sized in points, like any decent (non-Java) GUI.
I did not need to set different DPI values for each monitor belonging to a multi-monitor layout, so I do not know if that is possible in X11.
As for why use scaling, I can't read anything at 4k native and the UI elements don't scale correctly with the font dpi. Windows has fully functional 150% and 175% options (one of the few things Windows does well now) and in MacOS has really nice global super-sampling options between 1080p-1440p hidpi.
With the default font size set at 12 points, everything is very easy to read. Even 10-point or 9-point fonts are still comfortable, despite the fact that otherwise I need glasses for reading small printed books.
Under XFCE, almost everything is scaled fine on 4k and 192 dpi. The only exception is that some of the scrollbars remain rather narrow, but they are still usable.
Like what?
X11 is such a central part of the software required to use a computer that it is not acceptable for a substitute to implement only a subset of its functions.
For any X11 replacement, its architecture should have been conceived since the beginning to enable the implementation of all X11 functions, even if for some of them a lower performance caused by interposed compatibility layers is acceptable, if it is hoped that they will be deprecated eventually.
It should have been obvious for the Wayland developers that some of the X11 features will never be deprecated, e.g. screen snapshots, screen sharing or remote desktop access.
Instead of trying to remove such features, they should have tried since the beginning to find better solutions for them then in X11.
While a network protocol should be implemented by a program distinct from the graphics system, when designing any modern graphics API one should ensure that it has good compatibility with something like the Remote Desktop Protocol.
In general the Wayland designers have attempted to minimize the work they had to do by claiming that various functions belong into other programs, but their arguments are not convincing.
Most, if not all, functions of a window manager should be implemented in the same process as the graphics system, even if the window manager should be some kind of replaceable plugin. That includes the window decorations. A GUI application must be concerned only with the client area of a window.
Moreover, it is inexcusable that Wayland has not been designed with an up-to-date color management since the beginning.
Who uses just one computer anymore? We shouldn’t make architectural choices that assume one GPU local to an app server, because in real life GPUs are found attached to each user’s display.
Most significantly, the "only the focused app should be able to read input" is wildly, fantastically wrong, mind-bendingly deviated from the norm on literally every other graphical user interface in the history of humanity, and utterly incomprehensible to anyone who is not an outright "cybersecurity" fetishist. Imagine a windowing system where you are playing a video game with a USB controller, you mouse over to a window to send a text message and your video game loses the ability to process the controller input. This is clearly surprising behavior, if not outright user-hostile, and only Wayland gets this wrong. Rather than fixing it, Wayland devs gaslight users and developers into believing anyone who opposes this bad behavior is anti-security and therefore pro-badguy, or something. So, each separate desktop environment tribe is now having to produce their own bespoke utilities to mux input clientside to enable normal use of computers, because the Wayland protocols are empowered by divine right instead of technical merit.
I want to add that despite the above litany I do regard Wayland as a marked improvement over X11 and I have no interest in going back to the bad old days. None of the problems with Wayland are unfixable in a 2.0 or so bad that it's worth going back to X11. The actual big problem with Wayland is the unwillingless of the core developers to take advice, but that was a problem back when they were the X11 core developers, and I don't see it changing. For those of us who don't have to interact with them, it's a non-issue.
Is there a solution to this? Any alternative at all? Like, I agree with this problem and it makes me almost irrationally angry that fundamental software on what should be a flexible and open platform are built by people who are so hostile to basic settings or extensible functionality that they are even more egotistical than Apple engineers :/.
I mean, I can run X11 as long as possible, but sooner or later, I'm probably going to have to deal with Wayland. Especially since I'm also not willing to consider Mac because I've suffered enough, and Windows 11 looks like it might piss me off enough to go back to an opensource desktop.
Alternatives probably look like borrowing from other projects that have managed to wrangle things. Android doesn't use X or Wayland, afaik, but I don't know that it makes a good base for a desktop. I believe ChromeOS uses X11 (EDIT: I'm probably wrong, looks like they use Wayland) and their own window management etc, that doesn't help if you don't like X11/Wayland.
Otherwise, maybe it's possible to build on top of Windows apis. There's NDISWrapper, maybe someome crazy could build something to use GPU drivers for Windows, and run wine or something. If you look around, you'll see articles about how the portable executable file format for Linux GUIs is windows PE, and it sort of makes sense, a little. That'd be a big transition in expectations though.
Because redshift is designed for X11. If you want redshift for Wayland then you use gammastep. Taskbar options if you don't want to use whatever is part of a common window manager would be Waybar, swaybar, and i3statusrs. Screen recording works well with OBS. All this works without relying on the AUR BTW.
Nope, wrong, this doesn't work for KDE or GNOME or most of the big compositors for that matter. There really is no standard way as I mentioned in another comment. Anyway, from the gammastep README:
> Why doesn't this work with Wayland compositors like Mutter, KWin, Mir, and Enlightenment?
> This program supports the wlroots protocol for gamma adjustments, but several Wayland compositors do not support this protocol. GNOME and KDE have their own built-in mechanisms for adjusting color temperature on Wayland.
For GNOME, I might as well say here for reference, using gsettings to adjust the keys in org.gnome.desktop.a11y.magnifier seems to work for now, but I'm sure they'll find a reason to remove that soon enough.
but even if you use gnome or kde you can still use redshift in X11 because these things are independent. e.g. maybe you have a redshift config file associated with a screen / location, it shouldn't matter which DE you are using for it.
These exist, but while they are first class citizens on AUR (which is really just building from source), they are mostly absent from the ubuntu repos. You wind up chasing down and compiling nine different dependencies for a fecking backlighting program before realizing you just don't care anymore and you happily switch back to i3wm on xorg and move on with your life.
Libinput and Pipewire in particular solve a huge selection of issues I would routinely run into on linux machines in the 2010's.
Not limited to wayland, but definitely pushed by wayland and developed in tandom with a similar set of goals (renovate mostly legacy spaces that are critical in the end-user space).
I have also - not ever - had to touch a terminal/file editor to make an external display work with wayland. Which... is just hands down pleasant. And frankly an experience that does not exist with X. For the most part - I just plug it an and things work as expected. Including much better scaling/hidpi support.
Honestly - not having to mess with conf files for basic input/output has been a hallmark of my experience with Wayland.
I enjoy quite a bit more deep diving in linux than most any typical user (I run arch as a daily driver and host about 15 apps in a k8s cluster in my basement - I'm not afraid of some configuration), but I'm tired of wasting time making devices work like they should. Personally - I don't find that experience enjoyable or satisfying. I'd like my mouse/touchpad/monitor/headset to just work when I connect them, and wayland based compositors seem to get those mostly right.
I switched 5 years ago - back when screen sharing was still... rough, and a lot of the benefits weren't present because major applications (namely - browsers) were still running in Xwayland. The experience today is just downright pleasant. I enjoy my wayland boxes far more than my work macbook, and the last hold-out has been a Windows 10 box for games, which thanks to valve and wine will not be getting upgraded to windows 11.
1. I was told to ~piss off~ because i use Nvidia for Blender and don't want to switch to AMD. The hostility was very discouraging.
2. I adjusted my workstation accordingly to not deal with the screen issue long ago. Yea, it would be nice to use differing monitors, but before Wayland was really viable i had to solve the problem properly to keep working. The net result is this killer feature had to be solved by me with hardware before Wayland could even have a chance to solve it with software.
I can understand that. This doesn't excuse the hostility, but also understand that, to the developers, it's been a huge slap in the face that nvidia didn't feel like adopting the standard that the rest of the Linux graphics community had adopted. Having to support another rendering backend, just because nvidia chooses to -- yet again -- abuse the Linux community, is hard to feel good about.
Now, it's inexcusable to pass that hostility on to regular users, assuming they are asking politely, and aren't acting entitled to a solution. But I understand where the hostility comes from.
(It's also telling that nvidia has, more recently, decided to stop doing their own thing, and adopt the established standard. Even they realized -- though it took them way more time than it should have -- that what they were asking was too much.)
LOL as a long time "just a WM" user, I don't find any of these to be that hackish.
But yeah I use KDE so probably for other DE is not worth it?
It's become pretty clear that their abstractions aren't correct. If I have to link against a gigantic C library just to get window decorations, we have a deeper problem.
(see: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i... for how big it is)
> Currently there is 11 THOUSAND lines of Rust in wlroots-rs. All of this code is just wrapper code, it doesn’t do anything but memory management. This isn’t just repeated code either, I defined a very complicated and ugly macro to try to make it easier.
> This wrapper code doesn’t cover even half of the API surface of wlroots. It’s exhausting writing wlroots-rs code, memory management is constantly on my mind because that’s the whole purpose of the library. It’s a very boring problem and it’s always at odds with usability - see the motivation for the escape from callback hell described above.
Disclaimer: I don't know Rust beyond println!("Hello World"); C is my preferred language for decades now.
The example Rust code in that linked post is just an absolute unreadable horror show. If that's representative of what it's really like to interop C with Rust or just write real Rust code in general, I'm strongly discouraged from bothering to put more effort into the language.
Can anyone skilled and experienced enough with Rust to judge what's going on there comment? Is the author just a noob making a mess of things as anyone can do in any language, or is this limited to C interop? Or is Rust normally such an inscrutably verbose disaster?
On the other hand, I can't think of a way to do it better either. wlroots might just be uniquely horrible here.
However, I tried quite a few ways to make this safe and ergonomic. Perhaps some better way exists that I missed, but even if a solution exists the work needed to implement it is very, very boring.
wlroots is very much a C API, but I admit I was expecting it to be easier to use from Rust and is my current biggest criticism with the language.
Normal Rust is normally not this inscrutable - however it does have a lot of features that could make it as hard to read. It requires a certain amount of discipline that you don't see in simpler languages like Go. I for one never write macros if I can help it anymore.
Is there a write-up of the critique of this issue?
I read the Waycooler blog posts but they didn't go into details.
In the last 15 years, that assumption has broken. People want to write applications specifically avoiding C/C++ and even Gnome/KDE.
Wayland has not adjusted to this new reality. It is not clear that it may even be able to.
The problem is that this kind of graphics system programming is a gigantic pile of work while being very fiddly with non-obvious details that you have to get correct. Very little of it is "fun" and the people qualified to be doing it are capable of earning a lot more money doing basically anything else. The fact that almost exactly the same people doing Wayland were the ones doing X11 previously shows that nobody is jumping up and down for the chance to attack this.
Love Sway.
I'd kind of say it the other way around. I don't notice any real downside over X, configuration is much nicer, and apparently it's more secure or something? Why not.
I'm learning a lot about the politics of the situation in here! For me, Wayland worked.
Most Wayland compositors outside of GNOME, KDE and Weston are wlroots-based. Whether the packages have been added to Arch repos is kind of neither here nor there, a lot of them are reasonably mature and will do what they say. Wlrobs for example will work just fine if you want high performance screen capture inside of wlroots without relying on desktop portals.
XWayland apps scale fine, they just don't render at high DPI. I agree this is bad if it's most apps. That said, you may not have realized but a lot of apps that start in XWayland today work fine with Wayland/XDG Shell with a command line flag or environment variable. Chromium and Electron apps will switch soon when the ozone platform hint flag is changed to default to "auto". That means that Firefox, Chrome, Electron, SDL, GLFW, Qt 5, Qt 6, GTK 3 and GTK 4 apps can all start in native Wayland assuming the apps themselves don't depend on X11, including many tricky ones like OBS. Even Wine might soon have a native Wayland driver[1], further knocking down the number of apps that hard-depend on X. (For me, the main ones I can think of are Krita and dolphin-emu.)
I think the vast majority of Wayland issues today just stem from the NVIDIA experience. And to be fair, that is a completely valid reason to not use Wayland. It's a shame though, because the developers behind Xorg have no interest in maintaining parts of X outside of XWayland. It's tough to break many of these chicken-and-egg problems with 80% of the Linux user base being shafted. Of course, it's not just about Wayland, it's about the whole stack. NVIDIA users had to wait longer to get many basic creature comforts, like KMS support. It's very telling that only one major GPU vendor has issues like this with open source OSes, it's just unfortunate that it has to be the biggest one on desktop.
Of course, everything is always just around the bend. But with improving NVIDIA drivers and concrete timelines for apps defaulting to Wayland when possible, 2023 seems like it might just be the turning point. I'm patiently awaiting new NVIDIA driver releases... (But for now, you will have a way, way better time on Intel and AMD. It's leagues ahead.)
When Wayland was proposed, it’s biggest benefit was for direct rendering. At the time AIGLX was still the main hack to getting decent compositing/GL performance and had some major drawbacks. Wayland was designed in a manner more similar to the DRs in other desktop OSes (Windows and OS X, primarily). But, in its long development and adoption period, X’s DRI/DRM infrastructure has had plenty of time to mature and many of those arguments have been made moot. In fact, it still generally outperforms Wayland in many cases:
https://www.phoronix.com/review/nvidia-510-wayland/2
Theoretically Wayland is still conceptually superior in that regard; but you’re right, it hasn’t shown the drastic improvement originally promised.
So using the data from that article to conclude that "[Xorg] still generally outperforms Wayland" seems wrong. A comparison between native Wayland apps vs Xorg apps would have been a lot more relevant though.
[1] - https://www.phoronix.com/review/nvidia-510-wayland [2] - https://github.com/libsdl-org/SDL/pull/6362
X11 reduces my laptop battery life to about 33%. Possibly because the refresh rate is 144Hz, I don't know. Battery life is a substantial use-case.
The perceived latency is also way lower, resulting in a more pleasurable experience (and that matters).
> Trying to use a wayland window manager outside of gnome or kde leaves you reliant on a bunch of hackish utilities
That's due to the philosophy of those compositors (compose something bigger with simple tools, i.e. the unix philosophy). Nothing in Wayland is preventing the implementation of a full shell (as Mutter and KWin prove).
> Scaling and perf for xwayland apps (i.e. most apps) is pretty bad.
The fractional scaling extension is pretty new, but was designed to rectify this.
My big peeve with Wayland is Gnome and their f$&#(_ing refusal to implement decorations. And screen sharing is mostly broken on Ubuntu 22.4 (but that's probably because Ubuntu is utter shite, screensharing has been rock-solid on my distro-hopping personal PC).
Which is not really something that can be said about the big toolkits which tend to dictate how execution happen.
But that attitude certainly seems common among the people that build compositors. Having more alternative implementations would be very healthy for the environment.
It makes sense because Wayland was invented for the purpose of forcing hobbyists and power users into ecosystems that are 100% corporate controlled.
I agree that the isolated failure mechanism in this case is a strength of X11, but it's too far to extrapolate that to the designs as a whole.
I've switched to Wayland. On GNOME I haven't noticed any benefits, nor any costs. It has been a no-op.
However, applications that just grabbed X11 framebuffer won't work. They have to use respective APIs with user control ("portals") for that. Some do (Chrome, Firefox), some don't (MS Teams).
So does RDP and VNC, if you're interested... Across most every variant (wlroots based - ex: sway, gnome - mutter, kde - plasma wayland)
Since each company sort of sticks with 1 tool for every employee, could be kind of a deal breaker if they pick a tool that can't screen share on Wayland.