So here’s the thing: X works extremely well for what it is, but what it is is deeply flawed. There’s no shame in that, it’s 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
Man, this person really knows how to make their prose pack a punch.
It’s refreshing almost to the point of inspirational to see someone who’s spent a large chunk of their lives laboring to improve a given code-base make a case for its (XFree86) near total obsolescence with such eloquence and authority.
I’m the Wayland maintainer and I care about BSD. Some other Wayland-related projects (including Sway, wlroots for instance) have FreeBSD continuous integration. Edit: also the Hikari compositor has been designed on BSD. The only reason BSD patches aren’t upstream is that we haven’t figured out a good way to setup BSD CI on gitlab.freedesktop.org.
The issue I’m facing is that gitlab.freedesktop.org uses Linux containers for CI, so we need to spin up a FreeBSD VM in the container to build Wayland and run the unit tests (making sure a commit doesn’t regress FreeBSD support). However official FreeBSD VM images don’t come with SSH enabled by default, and we have no way to edit the image filesystem to do this (UFS being read-only on Linux). Serial console is also disabled by default IIRC (and isn’t great anyways). We’d also prefer not to rely on custom images generated and hosted by an unofficial party (what should we do if it goes offline? what about updates/fixes?).
There has been some WIP work on the FreeBSD infra side which may make SSH enabled by default, but someone still needs to wire it up to the CI image templates used on gitlab.freedesktop.org.
Yeah, I’m aware of sr.ht, in fact I’m an employee :P
The main pain point is that GitLab doesn’t support well integration with third-party Ci services 1. Another concern expressed by some Wayland developers is the dependency on a third-party service.
OpenBSD shouldn’t be too hard to add once FreeBSD is sorted out, I hope.
I don’t think this part of the post should be overlooked as an afterthought to a separate primary point:
So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I’d say yes. But xserver is more than xfree86. Xwayland, Xwin, Xephyr, Xvnc, Xvfb: these are projects with real value that we should not give up. A better way to say it is that we can finally abandon xfree86.
As a happy user of Xenocara on OpenBSD, I personally hope any developer who might be working on - or considering working on - anything that aspires to “a better end-user experience part of a windowing/tiling graphical paradigm” to consider what is still possible to build on top of X without abstracting away multiple layers of the end user’s experience to other sub-systems you add as dependencies (without first considering the implications), and without requiring any new features to “core” parts of the X dependency ecosystem.
I understand the desire for Wayland, but am cautious about the way “GNU is Not Unix” has been so deeply internalized by non-GNU projects. I am personally not ready to throw out the Unix philosophy for desktop paradigms under the assumption “other layers” are already solved problems (i.e. cross compatible GUI application bus IPC and graphical hardware access).
To be fair, I have experimented with writing enough X-based C code to understand anyone who would decide to avoid it. It’s not as terrible as some people would have you believe, but it also doesn’t feel like most of the code you’re writing actually matters to the goal you’re trying to accomplish for an end-user of a graphical interface. There also isn’t any X-based code I’ve come even close to shipping, so who would I be to cast blame?
And call me a curmudgeon or hypocrite, but I’d still rather someone release a native Wayland application I can’t use than a web application I can.
The big gripe I have with Wayland is the fact that while the protocol is nice, it’s too thin and leaves too much to the implementation. I don’t want to depend on some third-party library like wlroots and actually want to see freedesktop.org commit to specifying things instead of just “letting the crowd decide”.
We at suckless really are open to trying new things out. For dwm, we would probably also consider switching away from X if it proves to be more lean, reliable and suckless, but Wayland is deeply flawed and inconsistent. At least with X we can depend on a specification, choose not to implement things, rather than with a dwm as a Wayland-based compositor, where we could receive an arbitrary amount of events that are extensions tailored towards the few centrist “solutions” that are at an arms-race against each other.
Additionally, I think the Wayland spec goes the wrong way and really dropped the ball in regards to federalization/remote-working. Because X is protocol-transparent, you can interact with X-clients over the network via ssh. With Wayland, everything is centered around low latency, which itself is a good thing, but really limits the entire thing a lot.
As others have already mentioned, Wayland-compositors tend to hardfreeze your system on errors. I know that it’s partially the drivers’ fault, but it just is indicative of how low-level Wayland-compositors really are, which is not acceptable in my opinion. X may also be low-level, but it does that for you with its server. So all development efforts have flown and will flow towards solidifying the X server. With Wayland, you may have Weston, but it’s a big mess, and most don’t use it and do their own inconsistent thing.
To put it shortly: The entire Wayland-ecosystem is swamped by freedesktop.org’s fear of specifying things leading to an inconsistent mess. X is not consistent either and has a lot of bolted on things, but at least it has a specification (libraries, server) you can rely on.
I don’t want to depend on some third-party library like wlroots
Why is that?
At least with X we can depend on a specification, choose not to implement things, rather than with a dwm as a Wayland-based compositor, where we could receive an arbitrary amount of events that are extensions tailored towards the few centrist “solutions” that are at an arms-race against each other.
That’s not how Wayland works. A Wayland compositor chooses which interfaces it implements, just like X11 extensions. All existing Wayland extensions aren’t necessary for a Wayland compositor to be able to show a window. Even interfaces part of the core protocol aren’t all mandatory.
Additionally, I think the Wayland spec goes the wrong way and really dropped the ball in regards to federalization/remote-working. Because X is protocol-transparent, you can interact with X-clients over the network via ssh. With Wayland, everything is centered around low latency, which itself is a good thing, but really limits the entire thing a lot.
X may also be low-level, but it does that for you with its server. So all development efforts have flown and will flow towards solidifying the X server.
wlroots partially addresses that
I’d bet the cumulative X.org server + dwm complexity is higher than say wlroots + Sway
Because it’s a private project. When this goes on and we start depending on wlroots more and more, this gives a lot of power to an invidual. I respect Drew DeVault, the developer, a lot, but this path can lead to problems down the road. As I said, if you just throw your hands up and give up on specifying interfaces and delegate it to largely centralized implementations like wlroots, that would better be standardized into higher-level interfaces, something is wrong.
That’s not how Wayland works. A Wayland compositor chooses which interfaces it implements, just like X11 extensions. All existing Wayland extensions aren’t necessary for a Wayland compositor to be able to show a window. Even interfaces part of the core protocol aren’t all mandatory.
There are numerous examples of sway-specific extensions (e.g. for color spaces) that are not specified anywhere. So unless I get out of my way and read all the proprietary extensions of all Wayland-compositor-libraries, I have no way of seeing what’s specified in a single spot (within a freedesktop.org-specification most notably). This is different with X and if it goes on with the oligoculture of Wayland-compositor-library, there’s no way back because applications will start using these interfaces.
This is an interesting project! Thanks for sharing.
wlroots partially addresses that
I’d bet the cumulative X.org server + dwm complexity is higher than say wlroots + Sway
Both valid points if wlroots wasn’t some third-party project that is still rapidly changing and more or less only suitable for sway, because it’s the only project that can keep up with the changes! Do you really seriously consider wlroots in its current form as a sway-backend as a go-to-choice for Wayland-compositors? It’d be a completely different situation if wlroots was developed as a freedesktop-project and actually embraced as a reference. Weston plugins don’t count as compositors for me, before you mention that.
I don’t see how wlroots is different from libwayland in this regard. All open-source projects are “private” projects powered by individuals and/or companies.
But I don’t see how this changes anything. The X.org server has (had) a maintainer, too.
As I said, if you just throw your hands up and give up on specifying interfaces and delegate it to largely centralized implementations like wlroots, that would better be standardized into higher-level interfaces, something is wrong.
Higher-level interfaces which involve IPC and coordinating multiple processes only increase the complexity of the software.
There are numerous examples of sway-specific extensions (e.g. for color spaces) that are not specified anywhere
They are specified. And they aren’t specific to Sway, KDE and Mir implement some of these.
This is different with X and if it goes on with the oligoculture of Wayland-compositor-library, there’s no way back because applications will start using these interfaces.
We try hard to upstream these extensions to wayland-protocols. This is a big task and working on this means we don’t work on something else, so the process is slow.
rapidly changing and more or less only suitable for sway, because it’s the only project that can keep up with the changes!
That’s very far from being true. wlroots is used by many compositors, and even if we “move fast”, each release notes contains an exhaustive list of breaking changes. In practice downstream compositors only need a few changes to support a new wlroots release.
Do you really seriously consider wlroots in its current form as a sway-backend as a go-to-choice for Wayland-compositors?
Sway is in no special position here. The wlroots API has been carefully designed to not be tied to Sway at all (or any compositor for that matter). The fact that many compositors that don’t behave like Sway are backed by wlroots is a proof that it works. A few examples of such compositors: Wayfire, gamescope, wxrc.
Both valid points if wlroots wasn’t some third-party project that is still rapidly changing and more or less only suitable for sway, because it’s the only project that can keep up with the changes! Do you really seriously consider wlroots in its current form as a sway-backend as a go-to-choice for Wayland-compositors? It’d be a completely different situation if wlroots was developed as a freedesktop-project and actually embraced as a reference. Weston plugins don’t count as compositors for me, before you mention that.
As the author of river which also uses wlroots, your statements do not speak to my experience using and contributing to wlroots. I think describing wlroots as a “sway-backend” is blatantly false in particular. wlroots is absolutely the go-to choice for wayland compositors at the moment, nothing else as modular, flexible, and complete has come about yet.
I don’t particularly like Wayland and i don’t plan to switch any of my *nix machines to a Wayland compositor any time soon, but FWIW, what you’re saying matches my experience with wlroots, too. It’s extremely flexible and makes writing a desktop compositor very palatable, even if said compositor isn’t wlroots-like at all. Yes, it’s a moving target, but so is everything in the Wayland space, for better or for worse. And it has a bunch of quirks, some, if not most of them, inherent to Wayland – but it also gives you the tools to work around said quirks. IMHO it’s the best choice if you want to hack on anything desktop-related with Wayland.
Frankly, I think it’s the best route to go by for pretty much any Wayland compositor *shrug*
Excellent post. While it is supposedly a non-dispassionate text, it is in fact much more reasonable than some reactions I have seen on lobsters and elsewhere.
I like a lot of things about wayland, and eventually I plan on switching from i3 to sway. But at the moment there are several types of applications that not only don’t work in wayland, but would be very difficult, or impossible to work natively in all major wayland compositors.
Third party screen shot/capture/share (shutter, OBS, ffmpeg, import, peek, scrot, VNC, etc.)
Color picker (gpick, gcolor3, kcolorchooser)
xdotool
GNOME and KDE have dbus APIs for some (but not all) of these things, and sway has its own IPC, and other compositors probably have similar solutions. However, they all use different mechanisms, which means that if you are writing say, screenshot application you either have to write a different backend for every compositor, or choose just one or two to support.
Something all of these types of applications have in common is they need to be able to inspect and/or modify state from other applications or the compositor itself. Which wayland’s security model normally prevents. I think a major gap in wayland, is having a way for an application to run with escalated permissions so it can have access to other applications. Unfortunately, I don’t have any great ideas on what that would look like.
Until there are standardize protocols for things like screenshots, programatic clipboard access, custom launchers, and output configuration. I’m holding off on moving to wayland.
Many of the reasons are out of date. wf-recorder can be used for screen capture and wl-clipboard is a collection of clipboard utilities, for example. I don’t think that Reddit comment is valid anymore.
I pointed out 2 mistakes/things that are out of date on the list, which implies that the list is no longer valid. In my point of view, it needs to be updated before it can be used for any sort of reason to avoid Wayland.
I also know that it’s wrong that ie. rofi does not work with Wayland, since I use it daily together with Sway.
The onus is on the person making the original claims, not me.
Since open-source has no warranty, we are left in a tough spot of maintaining the old thing or developing the new thing ourselves. I think I have more of a chance developing utilities like the ones listed than xorg.
I use Emacs’s exwm as my window manager because it translates my key bindings from Emacs-style to conventional-style before sending them on to the X clients. Without this it is very difficult for me to use a web browser, since I always end up with twenty-four new windows due to holding down Ctrl-n in order to scroll down, or seventeen print dialogs due to trying to scroll up.
It used to be possible to fix this in the browser with an extension, but a few years ago Firefox copied Chrome’s web extension mechanism, and now it prevents extensions from doing this for “security reasons” making the browser absolutely infuriating to use outside exwm.
Anyway, I’m kind of tired of reading about how awful X is. Sure, it has a lot of shortcomings. Who cares. No amount of streamlined technical improvement is worth putting up with “I have to fight the urge to throw my laptop out the window multiple times per day because of the rage caused by shitty key bindings”. These two types problems are nowhere near the same order of magnitude.
I think XFCE (err wait no, MATE? I think MATE) is going with Mir for some reason. (Which, in case you missed it, is just a Wayland compositor now, they abandoned the custom protocol.) But let me plug Wayfire (which I contribute to reasonably often).
Wayfire is the Compiz of Wayland — a generic compositor to build desktop environments on top of, with a flexible plugin system to add whatever functionality you want, and with a standard collection of plugins that includes many old favorites like wobbly windows and desktop cube :)
dwl is a “dwm for Wayland”; it’s obviously not for everyone, but the code just under 2,000 lines (similar to dwm). I haven’t looked at it in detail, but this seems to indicate that it’s not much harder to write a WM for Wayland than it is for Xorg.
There are probably a few other smaller WMs out there as well.
Yeah, but it’s using wlroots, so it’s not a true “from-scratch” implementation. I know, the X-libraries are also pulled in for dwm and bring complexity, but they are part of the “standard”.
I have the impression that wlroot is more or less the unofficial “standard”.
The end result is a binary that’s actually smaller than dwm on my system (44k vs 49k, stripped), so it doesn’t seem like there’s some needless bloat going on.
What’s the difference between an in-process wlroots library, and an out-of-process X.org server? Doesn’t dwm depend on X.org server just like dwl depends on wlroots?
After seeing the previous post about X, I decided to give wayland another try (my last try was before wlroots creation…).
I wanted to use wio (listed on wlroots page). it’s been 2 days, and I still couldn’t get it started. Whem run from a TTY, it freezes my laptop and I must hard-reboot it.
I looked into other projects from the page, and many compositors are, in fact, abandonware (not a single commit in a year or so). wlroots is a fine project, pushed forward by sway. Other compositors (including those written by Drew Devault himself) are lagging behind.
Thanks to wlroots, wayland is getting closer to full adoption everyday, but it seems to be moving real fast, to the point only sway can really keep up with it.
This is true from the point of view of distros too. I run debian buster, and with standard repositories, there is no way you can even compile wlroots. The meson version required is 0.54 (0.49 in repository), wayland-server must be at 1.18, the very latest version (1.16 in repository). To my little experience, it seems to still be moving too fast to be a drop-in replacement.
I will however try to get it working in the next few days. I am really eager to try a wayland based desktop and make myself a real opinion about it. I really hope KDE, Gnome and sway aren’t the only viable options.
wlroots is intentionally moving fast, depending on the newest dependencies instead of having support code and conditionals for previous versions. If you’re using a distro that doesn’t ship with the newest dependencies, you don’t need to pick the latest version of wlroots, you can compile an older one.
A lot of these smaller compositors aren’t working well, a lot don’t have docs, a lot are a one-man project, a lot are abandoned. I don’t think this is specific to Wayland though.
Of all of these projects, I’d say the more mature ones are Sway, Wayfire, Cage, Hikari, River and Librem5. Waymonad hasn’t seen development in a while but got pretty far. There are maybe others that are usable, apologies if I missed one.
If it wasn’t clear enough: all of these projects need help :P
wlroots is intentionally moving fast, depending on the newest dependencies instead of having support code and conditionals for previous versions.
It is a totally sane approach. It has the drawback of obsoleting all the projects that depend on it after each release. You say that all the wayland projects need help, and I understand it as “wlroots is moving so fast, that a one-man project can’t keep up with it”. My take on it is that wlroots might still not be ready for stable use, and as a result, none of the projects that depend on it can have a stable version.
I wrote my own window manager for X, and it is now stable enough that I almost don’t touch the code anymore. The xcb lib isn’t changing, and hasn’t changed in a long time, so my one-man project is totally up to date with upstream.
If I were to write my own compositor (and I want to!), I would have to constantly update it because wlroots changes so often, just for my project to remain relevant. In this regard, I think it’s more “safe” for me to wait for wlroots to reach a stable state (with a stable API), before starting my project.
I understand it as “wlroots is moving so fast, that a one-man project can’t keep up with it”
No, that’s not what I mean. They don’t need help to update to newer wlroots versions, as the effort to do so isn’t huge at all. I mean they need help to finish their project: fix bugs, add features, etc.
Many of the wlroots-based compositors that are usable as a daily driver today are a one-man project.
But you’re right in saying that if you want to write a compositor and never touch the code again, wlroots isn’t ready yet. wlroots still moves.
EDIT: additionally, breaking the API and requiring up-to-date dependencies are two different things. If wlroots depends on newer libraries, this doesn’t mean it needs to break its API and require downstream changes. But yeah, right now wlroots does both.
There’s nothing particularly compelling in those links.
Some screen sharing and screen recording apps aren’t yet/won’t be ported to Wayland.
This was equally true for other windowing system transitions - some apps weren’t ported from NeWS or SunView either. It doesn’t mean that Wayland is unsuitable for general use.
Wayland breaks global menus in Gnome
This is a GTK issue. GTK4 removed support for a feature that is required by global menus. Wayland isn’t responsible for the development practices of the GNOME project.
Wayland broke global menus with KDE platformplugin.
This issue has been resolved.
Wayland breaks global menus with non-KDE Qt platformplugins.
This may have been fixed in 5.11.
Wayland breaks AppImages that don’t ship a special Wayland Qt plugin
This is another 5.11 issue, it may have been fixed.
I don’t even really care about Wayland vs. X much (the most I’ll say is it feels a little early to push it), but the dumping of gists full of “HAHAH GOT ’EM” link potpourri feels really low quality to me.
Man, this person really knows how to make their prose pack a punch.
It’s refreshing almost to the point of inspirational to see someone who’s spent a large chunk of their lives laboring to improve a given code-base make a case for its (XFree86) near total obsolescence with such eloquence and authority.
That quote is gonna stick in my brain for sure
Considering how Linux-centric Wayland is (the devs seem to not care about anything else), I don’t think we’re about ready to drop Xorg.
I’m the Wayland maintainer and I care about BSD. Some other Wayland-related projects (including Sway, wlroots for instance) have FreeBSD continuous integration. Edit: also the Hikari compositor has been designed on BSD. The only reason BSD patches aren’t upstream is that we haven’t figured out a good way to setup BSD CI on gitlab.freedesktop.org.
Thank you.
I am not a FreeBSD maintainer and I haven’t used FreeBSD since 2012.
I am curious though, what is the problem? Do you need someone to setup the pipeline, money or something else?
The issue I’m facing is that gitlab.freedesktop.org uses Linux containers for CI, so we need to spin up a FreeBSD VM in the container to build Wayland and run the unit tests (making sure a commit doesn’t regress FreeBSD support). However official FreeBSD VM images don’t come with SSH enabled by default, and we have no way to edit the image filesystem to do this (UFS being read-only on Linux). Serial console is also disabled by default IIRC (and isn’t great anyways). We’d also prefer not to rely on custom images generated and hosted by an unofficial party (what should we do if it goes offline? what about updates/fixes?).
There has been some WIP work on the FreeBSD infra side which may make SSH enabled by default, but someone still needs to wire it up to the CI image templates used on gitlab.freedesktop.org.
If someone wants to pick that up and move this forward: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/3#note_563739
I’ll gladly review any patches!
EDIT: just thinking about it now, but the recent work to make FreeBSD buildable from Linux may ease the process.
I think with NetBSD you can do testings http://www.gson.org/netbsd/anita/
Interesting, thanks for the link!
NetBSD lacks funds to do patching them selves still few contributors working on it : https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and
I don’t know if this helps, but sr.ht has CI for the BSDs.
Is OpenBSD on the roadmap?
Yeah, I’m aware of sr.ht, in fact I’m an employee :P
The main pain point is that GitLab doesn’t support well integration with third-party Ci services 1. Another concern expressed by some Wayland developers is the dependency on a third-party service.
OpenBSD shouldn’t be too hard to add once FreeBSD is sorted out, I hope.
I don’t think this part of the post should be overlooked as an afterthought to a separate primary point:
As a happy user of Xenocara on OpenBSD, I personally hope any developer who might be working on - or considering working on - anything that aspires to “a better end-user experience part of a windowing/tiling graphical paradigm” to consider what is still possible to build on top of X without abstracting away multiple layers of the end user’s experience to other sub-systems you add as dependencies (without first considering the implications), and without requiring any new features to “core” parts of the X dependency ecosystem.
I understand the desire for Wayland, but am cautious about the way “GNU is Not Unix” has been so deeply internalized by non-GNU projects. I am personally not ready to throw out the Unix philosophy for desktop paradigms under the assumption “other layers” are already solved problems (i.e. cross compatible GUI application bus IPC and graphical hardware access).
To be fair, I have experimented with writing enough X-based C code to understand anyone who would decide to avoid it. It’s not as terrible as some people would have you believe, but it also doesn’t feel like most of the code you’re writing actually matters to the goal you’re trying to accomplish for an end-user of a graphical interface. There also isn’t any X-based code I’ve come even close to shipping, so who would I be to cast blame?
And call me a curmudgeon or hypocrite, but I’d still rather someone release a native Wayland application I can’t use than a web application I can.
The big gripe I have with Wayland is the fact that while the protocol is nice, it’s too thin and leaves too much to the implementation. I don’t want to depend on some third-party library like wlroots and actually want to see freedesktop.org commit to specifying things instead of just “letting the crowd decide”.
We at suckless really are open to trying new things out. For dwm, we would probably also consider switching away from X if it proves to be more lean, reliable and suckless, but Wayland is deeply flawed and inconsistent. At least with X we can depend on a specification, choose not to implement things, rather than with a dwm as a Wayland-based compositor, where we could receive an arbitrary amount of events that are extensions tailored towards the few centrist “solutions” that are at an arms-race against each other.
Additionally, I think the Wayland spec goes the wrong way and really dropped the ball in regards to federalization/remote-working. Because X is protocol-transparent, you can interact with X-clients over the network via ssh. With Wayland, everything is centered around low latency, which itself is a good thing, but really limits the entire thing a lot.
As others have already mentioned, Wayland-compositors tend to hardfreeze your system on errors. I know that it’s partially the drivers’ fault, but it just is indicative of how low-level Wayland-compositors really are, which is not acceptable in my opinion. X may also be low-level, but it does that for you with its server. So all development efforts have flown and will flow towards solidifying the X server. With Wayland, you may have Weston, but it’s a big mess, and most don’t use it and do their own inconsistent thing.
To put it shortly: The entire Wayland-ecosystem is swamped by freedesktop.org’s fear of specifying things leading to an inconsistent mess. X is not consistent either and has a lot of bolted on things, but at least it has a specification (libraries, server) you can rely on.
Why is that?
That’s not how Wayland works. A Wayland compositor chooses which interfaces it implements, just like X11 extensions. All existing Wayland extensions aren’t necessary for a Wayland compositor to be able to show a window. Even interfaces part of the core protocol aren’t all mandatory.
https://gitlab.freedesktop.org/mstoeckl/waypipe/
Because it’s a private project. When this goes on and we start depending on wlroots more and more, this gives a lot of power to an invidual. I respect Drew DeVault, the developer, a lot, but this path can lead to problems down the road. As I said, if you just throw your hands up and give up on specifying interfaces and delegate it to largely centralized implementations like wlroots, that would better be standardized into higher-level interfaces, something is wrong.
There are numerous examples of sway-specific extensions (e.g. for color spaces) that are not specified anywhere. So unless I get out of my way and read all the proprietary extensions of all Wayland-compositor-libraries, I have no way of seeing what’s specified in a single spot (within a freedesktop.org-specification most notably). This is different with X and if it goes on with the oligoculture of Wayland-compositor-library, there’s no way back because applications will start using these interfaces.
This is an interesting project! Thanks for sharing.
Both valid points if wlroots wasn’t some third-party project that is still rapidly changing and more or less only suitable for sway, because it’s the only project that can keep up with the changes! Do you really seriously consider wlroots in its current form as a sway-backend as a go-to-choice for Wayland-compositors? It’d be a completely different situation if wlroots was developed as a freedesktop-project and actually embraced as a reference. Weston plugins don’t count as compositors for me, before you mention that.
I don’t see how wlroots is different from libwayland in this regard. All open-source projects are “private” projects powered by individuals and/or companies.
Just as a head’s up: https://drewdevault.com/2020/10/23/Im-handing-wlroots-and-sway-to-Simon.html
But I don’t see how this changes anything. The X.org server has (had) a maintainer, too.
Higher-level interfaces which involve IPC and coordinating multiple processes only increase the complexity of the software.
They are specified. And they aren’t specific to Sway, KDE and Mir implement some of these.
We try hard to upstream these extensions to wayland-protocols. This is a big task and working on this means we don’t work on something else, so the process is slow.
That’s very far from being true. wlroots is used by many compositors, and even if we “move fast”, each release notes contains an exhaustive list of breaking changes. In practice downstream compositors only need a few changes to support a new wlroots release.
Sway is in no special position here. The wlroots API has been carefully designed to not be tied to Sway at all (or any compositor for that matter). The fact that many compositors that don’t behave like Sway are backed by wlroots is a proof that it works. A few examples of such compositors: Wayfire, gamescope, wxrc.
As the author of river which also uses wlroots, your statements do not speak to my experience using and contributing to wlroots. I think describing wlroots as a “sway-backend” is blatantly false in particular. wlroots is absolutely the go-to choice for wayland compositors at the moment, nothing else as modular, flexible, and complete has come about yet.
I don’t particularly like Wayland and i don’t plan to switch any of my *nix machines to a Wayland compositor any time soon, but FWIW, what you’re saying matches my experience with wlroots, too. It’s extremely flexible and makes writing a desktop compositor very palatable, even if said compositor isn’t wlroots-like at all. Yes, it’s a moving target, but so is everything in the Wayland space, for better or for worse. And it has a bunch of quirks, some, if not most of them, inherent to Wayland – but it also gives you the tools to work around said quirks. IMHO it’s the best choice if you want to hack on anything desktop-related with Wayland.
Frankly, I think it’s the best route to go by for pretty much any Wayland compositor *shrug*
Excellent post. While it is supposedly a non-dispassionate text, it is in fact much more reasonable than some reactions I have seen on lobsters and elsewhere.
Below quoted comment (not mine) is probably the best reason why X11 is still a lot better then Wayland.
Source:
https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/
Many of the reasons are out of date.
wf-recordercan be used for screen capture andwl-clipboardis a collection of clipboard utilities, for example. I don’t think that Reddit comment is valid anymore.4/7.
wofiandbemenuaren’t necessarily exactly what you want, but they do exist.You nailed two. That means 2/7 of listed issues has been finally addressed on the Wayland side.
That means 5/7 is still on X11 side.
Still no go.
I pointed out 2 mistakes/things that are out of date on the list, which implies that the list is no longer valid. In my point of view, it needs to be updated before it can be used for any sort of reason to avoid Wayland.
I also know that it’s wrong that ie. rofi does not work with Wayland, since I use it daily together with Sway.
The onus is on the person making the original claims, not me.
hell, make it 3/7 now:
Nice.
I think that I can accept X11 as abandonware when Wayland will be default in OpenBSD :)
I think I can accept OpenBSD as relevant for desktop use, once Wayland is supported.
Just as a side note, this is imported from the top comment on the Orange site: https://news.ycombinator.com/item?id=24920327
(Sorry, won’t reply to all of that, I’ve already had enough with the discussion there.)
If you will read whole of that comment on the ‘Orange’ site you will note that it links to the same Reddit comment I posted :)
Since open-source has no warranty, we are left in a tough spot of maintaining the old thing or developing the new thing ourselves. I think I have more of a chance developing utilities like the ones listed than xorg.
The problem with Wayland is that there are basically 3 “options”:
What is the Wayland solution for those of us on XFCE, IceWM, FVWM, or WindowMaker?
I use Emacs’s exwm as my window manager because it translates my key bindings from Emacs-style to conventional-style before sending them on to the X clients. Without this it is very difficult for me to use a web browser, since I always end up with twenty-four new windows due to holding down Ctrl-n in order to scroll down, or seventeen print dialogs due to trying to scroll up.
It used to be possible to fix this in the browser with an extension, but a few years ago Firefox copied Chrome’s web extension mechanism, and now it prevents extensions from doing this for “security reasons” making the browser absolutely infuriating to use outside exwm.
Anyway, I’m kind of tired of reading about how awful X is. Sure, it has a lot of shortcomings. Who cares. No amount of streamlined technical improvement is worth putting up with “I have to fight the urge to throw my laptop out the window multiple times per day because of the rage caused by shitty key bindings”. These two types problems are nowhere near the same order of magnitude.
I think XFCE (err wait no, MATE? I think MATE) is going with Mir for some reason. (Which, in case you missed it, is just a Wayland compositor now, they abandoned the custom protocol.) But let me plug Wayfire (which I contribute to reasonably often).
Wayfire is the Compiz of Wayland — a generic compositor to build desktop environments on top of, with a flexible plugin system to add whatever functionality you want, and with a standard collection of plugins that includes many old favorites like wobbly windows and desktop cube :)
[Comment removed by author]
wlroots isn’t a compositor, it’s a medium-level-ish library for writing compositors.
dwl is a “dwm for Wayland”; it’s obviously not for everyone, but the code just under 2,000 lines (similar to dwm). I haven’t looked at it in detail, but this seems to indicate that it’s not much harder to write a WM for Wayland than it is for Xorg.
There are probably a few other smaller WMs out there as well.
Yeah, but it’s using wlroots, so it’s not a true “from-scratch” implementation. I know, the X-libraries are also pulled in for dwm and bring complexity, but they are part of the “standard”.
I have the impression that wlroot is more or less the unofficial “standard”.
The end result is a binary that’s actually smaller than dwm on my system (44k vs 49k, stripped), so it doesn’t seem like there’s some needless bloat going on.
What’s the difference between an in-process wlroots library, and an out-of-process X.org server? Doesn’t dwm depend on X.org server just like dwl depends on wlroots?
See my other comment, which hopefully clears that up.
The wlroots wiki has a pretty big list of compositors. Many of them are smaller compositors.
Are they working though ?
After seeing the previous post about X, I decided to give wayland another try (my last try was before wlroots creation…).
I wanted to use wio (listed on wlroots page). it’s been 2 days, and I still couldn’t get it started. Whem run from a TTY, it freezes my laptop and I must hard-reboot it.
I looked into other projects from the page, and many compositors are, in fact, abandonware (not a single commit in a year or so). wlroots is a fine project, pushed forward by sway. Other compositors (including those written by Drew Devault himself) are lagging behind.
Thanks to wlroots, wayland is getting closer to full adoption everyday, but it seems to be moving real fast, to the point only sway can really keep up with it. This is true from the point of view of distros too. I run debian buster, and with standard repositories, there is no way you can even compile wlroots. The
mesonversion required is 0.54 (0.49 in repository),wayland-servermust be at 1.18, the very latest version (1.16 in repository). To my little experience, it seems to still be moving too fast to be a drop-in replacement.I will however try to get it working in the next few days. I am really eager to try a wayland based desktop and make myself a real opinion about it. I really hope KDE, Gnome and sway aren’t the only viable options.
wlroots is intentionally moving fast, depending on the newest dependencies instead of having support code and conditionals for previous versions. If you’re using a distro that doesn’t ship with the newest dependencies, you don’t need to pick the latest version of wlroots, you can compile an older one.
A lot of these smaller compositors aren’t working well, a lot don’t have docs, a lot are a one-man project, a lot are abandoned. I don’t think this is specific to Wayland though.
Of all of these projects, I’d say the more mature ones are Sway, Wayfire, Cage, Hikari, River and Librem5. Waymonad hasn’t seen development in a while but got pretty far. There are maybe others that are usable, apologies if I missed one.
If it wasn’t clear enough: all of these projects need help :P
It is a totally sane approach. It has the drawback of obsoleting all the projects that depend on it after each release. You say that all the wayland projects need help, and I understand it as “wlroots is moving so fast, that a one-man project can’t keep up with it”. My take on it is that wlroots might still not be ready for stable use, and as a result, none of the projects that depend on it can have a stable version.
I wrote my own window manager for X, and it is now stable enough that I almost don’t touch the code anymore. The xcb lib isn’t changing, and hasn’t changed in a long time, so my one-man project is totally up to date with upstream. If I were to write my own compositor (and I want to!), I would have to constantly update it because wlroots changes so often, just for my project to remain relevant. In this regard, I think it’s more “safe” for me to wait for wlroots to reach a stable state (with a stable API), before starting my project.
No, that’s not what I mean. They don’t need help to update to newer wlroots versions, as the effort to do so isn’t huge at all. I mean they need help to finish their project: fix bugs, add features, etc.
Many of the wlroots-based compositors that are usable as a daily driver today are a one-man project.
But you’re right in saying that if you want to write a compositor and never touch the code again, wlroots isn’t ready yet. wlroots still moves.
EDIT: additionally, breaking the API and requiring up-to-date dependencies are two different things. If wlroots depends on newer libraries, this doesn’t mean it needs to break its API and require downstream changes. But yeah, right now wlroots does both.
Just found this :)
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
TL,DR - some of the links are inaccurate.
There’s nothing particularly compelling in those links.
This was equally true for other windowing system transitions - some apps weren’t ported from NeWS or SunView either. It doesn’t mean that Wayland is unsuitable for general use.
This is a GTK issue. GTK4 removed support for a feature that is required by global menus. Wayland isn’t responsible for the development practices of the GNOME project.
This issue has been resolved.
This may have been fixed in 5.11.
This is another 5.11 issue, it may have been fixed.
Very positive and productive. Thanks for sharing material that drives everybody forward.
I don’t even really care about Wayland vs. X much (the most I’ll say is it feels a little early to push it), but the dumping of gists full of “HAHAH GOT ’EM” link potpourri feels really low quality to me.