I always ran wayland (since I got "Ubuntu on Wayland" at the login available), but now my son wants to play minecraft with me so I have to use X. It's just this 1 thing that keeps me off it now. I imaging what the "Why Wayland? Will at some point flip to "Why not Wayland?" When really (almost) everything works.
I'd assume minecraft would work in xwayland right? I've been playing a bunch of AAA games (Deus ex games, dying light ect) all on wayland, with sway aswell.
I will run Wayland when it is built into Linux Mint. When they have fixed screenshots and color pickers and network transparency and any other hidden things I don't know about.
X's network transparency is not feasible when using any modern window manager, since you'll still be slinging pixel buffers over the network, and compositing them together on the client. It's just easier to render on the host and just send a single pixel buffer instead of a bunch of them as this is faster and simpler.
Sure, but the main thing is that if you do ssh -X it does kind of work. I can have one individual window integrated with my normal desktop, from a remote machine. It sucks but it's enough to get a few basic things done.
Wayland should surely be able to at least match that!
Individual pixel buffers should still be faster if only some of them change regularly, right?
This is hard to believe to me, I've used `ssh -X` countless times over the last twenty years on Ubuntu, Debian, Gentoo, Mandrake, Suse, Nixos and whatever else. I cannot remember this did ever fail. It might have been slow. I might have fixed xauth issues at the beginning. But it worked. So I am wondering what you did to have such bad experience.
Gnome, probably. But also, all the things I'd want to run like this probably wouldn't work - games, video players, browsers and IDE's. Everything else I run from the terminal be it locally or remotely.
I'll never understand why everyone went this way instead of extending the X11 draw pimitives to something that can actually be used by modern UI toolkit, like svg. People always claim that pixel buffers are more efficient, even bandwidth-wise, but I've yet to see a proof that "here's a bunch of pixels" is more efficient that "draw a gray rectangle (x0,y0,x1,y1)".
In a way they did. HTML/HTTP is exactly what you get if you extend it to cover all the modern stuff, and it's great.
I think the real question is why can't the display manager just be a browser, plus some backwards compatibility for "here's a bunch of pixels"..
All the RAM use issues of Electron go away if the whole desktop is a single shared browser, plus you can do client side JS work and not need to send any data at all for a lot of things, AND you can cache things, plus you can decompress video client side, play sound on the client...
Just do HTTP over UNIX domain sockets with some signalling to tell the server to open a window.
The X11 drawing primitives have already been extended with the Xrender extension. It allows to draw textured, anti aliased trapezoids, color gradients and many composition/transparency/mask modes. If GLAMOR is enabled it is even hardware accelerated. It is of course much more efficient over the wire than periodically dumping a bunch of bitmaps. The Cairo X11 backend uses Xrender by default. Also many GTK 2.x rendering backends used Xrender. All of this functionality was dropped with GTK 3+.
Screenshots don’t work? They work in vanilla Gnome on Fedora. So do color pickers, from what I’ve seen. Though, maybe I’m only using those with my browser. Not sure what you mean by network transparency, though.
Pseudostandards are one of my least favorite patterns ever.
You take a protocol that works, then you make a new "Modern flexible unopinionated" protocol and invite people to make their own versions with lots of incompatibilities.
Wayland still doesn't handle fractional scaling as well as x11 (at least for my laptop) and the text blurriness with fractional scaling is really a show stopper. X11 just works though. Hopefully they will iron out the last of the bugs and this 10 year project will finally achieve its potential.
Funny, fractional scaling is precisely what convinced me about wayland. Especially with mixed ratios, like you easily get when plugging a laptop to an external screen. My work laptop has a 1080p 14" screen at 1.00 and it's connected to the office's 4K 32" screens with a 1.35 factor, it just works. Good luck getting it to work that well on X11.
Same here. I simply cold not get fractional scaling working comfortably on X11 and that's why I've been on Wayland for years now.
The cases where fractional scaling doesn't work on Wayland are when you're running an app through XWayland. In those cases, I'd just find an alternative that works with Wayland. That's also what lead me to switch to Firefox full-time - Chromium's Wayland support lagged behind quite a bit.
Ubuntu's version of GNOME X11 handles it pretty well. You can workaround it similarly in other DEs/WMs by mucking around with xrandr (I forget exactly). I have an Nvidia card and last time I tried Wayland was just not usable. I also hate how at this point we have 3 choices for Wayland WMs compared to what is probably hundreds for X11. I did get frustrated with mixed DPI on Linux and just ended up replacing my 4K monitor with a 1440p one.
What's also kinda sad and funny is that X11 has had from day 1 support for different DPIs on different displays. But most programs just ignore X11s DPI setting and assume it's 96ppi. It also conflicts with modern multi-monitor on Linux which essentially fakes one giant display so you can drag windows across. There is some drawbacks but if you config each monitor to be a separate X11 display with the proper DPI and use compatible programs like Alacritty it kinda just sorta works.
Theoretically, Wayland has proper support for fractional scaling, and this just works. In practice however, this only works for wayland-native applications and all applications running through XWayland will be rendered small and scaled up, which ends up looking terrible. I guess this is implementation dependent, but this is consistent across Wayland on GNOME, Sway and KDE Plasma.
This is unfortunate, since many applications can scale just fine, but only through older hacks. Chrome and Electron applications will scale just fine by providing a proper DPI. Same for very old apps. GTK and QT applications will not, but they scale just fine by setting appropriate environment variables.
In practice, this leads to the experience often being better on X11. I've found KDE X11 to handle this the best, with the limitation being a single global scale, only certain fractions allowed and needing to restart KDE after changing it.
GNOME with Ubuntu patches and Xfce will scale everything x2 and use RandR to provide a higher virtual resolution. This has performance costs and messes with cursor speed (measured in pixels) but otherwise also produces good results.
Why is it surprising (or even Wayland’s fault) that X apps don’t have proper fractional scaling under Wayland (or anywhere)? Like it is quite clearly the fault of X, isn’t it?
Some frameworks don't have support for Wayland. So it might be not up to the program authors. World is not limited to GTK and Qt. One such example is Java.
The thing is that many X apps DO have fractional scaling under X, but not under Wayland. This implies that it could be made to work but for some reason isn't.
I've had a few issues (NixOS, sway). Mainly screen capture. XWayland apps can record windows, but not my whole screen. Wayland apps can record my whole screen but not individual windows. I also don't know how to get XWayland to match my sway display resolution as it is only half the resolution.
Also libinput via sway doesn't have a way to disable the touchscreen if I'm using a stylus as far as I'm aware.
I'm sure there are solutions to some of these, but given I already spend a significant amount of time fiddling with my NixOS configuration I'm already quite an outlier with regards to the amount of effort I am willing to spend and even I'm exhausted.
I need to know more about touchscreens and disabling touch but not stylus operations. Where can I find out more about this? What does it mean, physically? Where is the distinction handled?
The stylus I'm using operates independently from the capacitive touchscreen and is presented as a separate input device by libinput. The stylus needs external power and the input reports not just xy, but z coordinates. Physically I am not sure whats going on, and struggled to find anything authoritative on the subject.
The article is bad too. I can't decipher this sentence.
> X11 is showing to be in use above 90% over the span of this multi-month data and on average seems to be about 93% currently to Wayland at roughly 7%.
If the chart was really supplied by the Mozilla Telemetry team then it's quite an embarrassment. When analytics is your profession you should know better than to do things like use red and blue alongside each other. Even if you're not colorblind, #afa7f4 (desaturated blue) and #98b4fe (desaturated purple) are hard to distinguish because Chrome says the contrast ratio is 1.06. See https://personal.sron.nl/~pault/ to learn more.
I really hope wayland doesn't become to x11 what IPV6 is to ipv4.
Because after so many years, a lot of the ecosystem hasn't moved, or is even not compatible with it. Good multi display support is missing, and some games don't render well.
I want it to succeed, and the project has been progressing non-stop, but it does show how much time and energy such an endeavor takes. I was expecting to be able to use it for years and years.
btrfs is a drop-in replacement. Nothing changes for the user when they switch to it. With Wayland many basic features are missing even today. (Yes I know someone will explain here that everything works. Don't make me laugh)
> Nothing changes for the user when they switch to it.
You must perform regular maintenance on btrfs or it will quite simply break. This is a huge departure from for example ext4, which is (to the end user at least) hassle free.
I'm not sure about the "maintenance" part, however, my experience was:
- a few years ago, one system would suddently not boot (due to btrfs); this happened twice
- nowadays, on one system, background scrub doesn't start
This is anecdata of course, but I've never had a good impression overall. I don't see any reason to use btrfs rather than ZFS, considering that Ubuntu and derivatives are starting to add builtin support.
BTRFS is a great solution to the problem of having data be accessible reliably.
I've had issues with Wayland, and I've also had issues with X, but I've been using Gnome's Wayland session for 4 years now. More so than actual window manager issues, I've been experiencing issues with my GPU drivers. FOSS software has never been without it's operational issues. I don't understand what's up with this prejudice towards Wayland. You do understand, that it's the X developers themselves that advocated for Wayland (besides designing and developing it), don't you? X originates in the 80s and it's not a design that stands the test of time. Since the late 00s, all of the window managers had already started doing compositing themselves, circumventing all of the nice layers of the X protocol and just copying pixel buffers around, the interface with X itself is blocking, vertical sync is impossible, security is a joke, the code was untenable. I understand that in as heterogenous software ecosystem as desktop Linux, any large fundamental change will be ugly because there is no shared release cycle and there is no platform, so one can't just change everything overnight, but as far as I can tell, Wayland has been usable for quite a while now. Literal years. Unless you're using hardware vendors that are hostile to FOSS.
> X originates in the 80s and it's not a design that stands the test of time.
Actually the fact that X11 can be used today despite the fact that we went through several cycles of vastly changing GPU hardware shows that it absolutely has stood the test of time.
Ncurses apps can also display GUIs for a long time now, but it doesn’t mean that they are actually good solutions.
The X server became a pretty useless middle man between clients and the compositor. And the vastly changed GPU hardware is the reason we should prefer a superior solution - we no longer draw as we did 3 decades ago, so we should cut out the middle man.
Terminal applications stood the test of time as well. For everything that is not graphical in nature they are indeed good solutions.
> The X server became a pretty useless middle man between clients and the compositor.
X is a middle man but far from useless. Just as Wayland is a middle man as well. And looking at the protocol actual access to GPU memory is more opaque on Wayland than on X11 and as such to me Wayland is a more intrusive middleman.
If you want to "cut out the middle man" you have to use DRM directly.
Wayland is not a middle man as it is the compositor itself as well - it does the minimal amount of work necessary to compose the desktop. X on the other hand just transfers messages between clients and the compositor without doing any actual work (x render functions are almost never used by modern applications)
Many of the points of this talks are invalidated with the introduction of DRI3 others are still valid but Wayland is not a solution. The X server indeed "just transfers messages between clients" but so does a Wayland compositor. How else would a screen capture functionality even work. Also, the fact that GTK/QT applications don't use Xrender (GTK used to but dropped it) can not be blamed on X.
Using xrender would pretty much result in terrible performance, not allowing the extreme parallelism of GPUs. This is the fundamental problem with X, it originates from a time when GPUs were not even a thing. It had a great run, but let it sleep now.
Also, DRI3 doesn’t solve the fundamental security flaw of X - which can only be solved by nesting multiple X servers into each other. At that point we would have a much uglier architecture than we have with wayland.
I am a bit confused. I do not think that hardware accelerated UI was a thing until quite recently and people did not really have issues with its performance. If anything it feels like that accelerated UI drawing is slower on older machines compared to software-rendered UI.
Well, try using any graphical application from inside a vm (those are often software accelerated only).
But the problem is basically: you can either have 1-2-4-8 cores at most writing pixels into a buffer one after another (but due to the complexity of interactive GUIs it will most often be single threaded), so a circle will be displayed as going over an area and coloring each pixel.
Versus specifying some condition and having the GPU run it on every pixel in large batches, almost doing it in one go. Of course for 3 lines, what previous GUI iterations were, you don’t need gpu, but for gradients, media!, and basically a bunch of other things you simply need the GPU’s orders of magnitude more parallelism. Add to the picture that we are using much bigger screen resolutions (full hd has 6x number of pixels compared to 480p, and then we are not even talking about 4k. And 120, 240fps monitors are a thing now) and you can quickly see that 1) drawing is a greatly parallelizable task 2) having it done serialized simply doesn’t scale to today screens.
The drawing lib used by chrome is ridiculously performant - the problem is not at lower layers in case of modern UIs. Specific hardware will also be much more efficient than general purpose one, so no, gpus are not the culprit behind any of those.
While you may not like gradients, animations (which absolutely mandate GPUs) for example do give context on what happens because humans are used to physical objects that don’t teleport from one place to another. I wouldn’t consider these needless features either.
Who uses XRender? If nobody is using XRender, is it because everyone is wrong or is it because XRender is not the best solution to the problem it's trying to solve today? And sure, X just transfers messages between clients, and the window manager is just a client, but it feels like X is redundant here - why not have a unified protocol so that the clients can talk to the window manager directly? That way, the window manager can actually delegate different functionality using some kind of an authentication mechanism. X was developed when the principle of least privilege wasn't as prevalent and it shows. I don't want all of my applications to be able to capture all of my screens at all times. Yet with X, there's no way to prevent this.
And, may I ask,why are you so quick to dismiss the core developers of X?
> Literal years. Unless you're using hardware vendors that are hostile to FOSS.
Except new GPU hardware at reasonable prices has been unobtainable for 2 years now, and AMD's new Linux friendly stance was only a couple of years before that. So there's like a 2-3 year window where you could have said "Well, you should have known to buy the FOSS friendly hardware". (Which came with other tradeoffs, AMD had uncompetitive hardware and poor GPGPU support in that time period)
It really doesn't. I tried it again just yesterday and they don't support having multiple screens on Wayland, somehow. I want to switch to Wayland, but no, NVIDIA still doesn't work yet
> but it does show how much time and energy such an endeavor takes.
The reason it takes so much time is not that is requires a lot of "energy" or that the problem in general is particular hard to solve. Wayland is fundamentally flawed at the concept level and the only way for it to get to a usable state is to turn it essentially into another X. Combine this with general stubbornness of all involved parties and the extreme hesitancy to standardize essential things you get a recipe for disaster.
This is what I don't get. Wayland seems not to have started with solving some of the X11 problems first but on a strong framework, it seems to just be reinventing the wheel and hoping to catch up and fix the problems somewhere along the way. So users just wait for that moment and X11 works 'fine' for the majority in the meantime.
What credentials do I need to state and opinion on how it seems to have evolved? I'm not stating a scientific truth.
And yes, it is the fallacy of credentialism to attempt to use that as a measure of authority to make a statement. I could be a kernel developer of 20 years experience and have been terrible for all of them.
That's right - you're not stating a scientific truth, you're just stating falsehoods. It's pretty much enough to look at how any non-trivial X11 client looks like these days to understand the reason for Wayland's existence. Wayland, while not perfect, offers an incredibly clean and extendable design when compared to X11.
Whether the whole ecosystem is already in place to move regular users over is another matter (I'm developing a Wayland compositor at work and even I am still using X11 on my workstation), although with this kind of project I guess you just need to face the chicken-and-egg problem at some point to actually move things forward.
You just explained exactly what I assumed is going on. Great, Wayland has a bright extensible future, but right now it doesn't solve anything so special that common users (or distro owners) desire moving over, hence the low usage of Wayland.
Not a problem with Wayland, it's just as you say, not there yet.
The difficulty arise from the complexity of the problems to solve.
In a x11 world, the assumption is that everything that a user runs is fully trusted, any software has access all the inputs, all the audio, everything that is displayed without any restriction. This wasn't a problem 30 years ago, but is quite a blocker for modern approach to security with granular permissions.
The architecture of x11 itself does not fit a modern graphical stack, some problem cannot be solved properly like monitors with different framerates, fractional scaling etc...
Wayland is just one part of the big efforts that are ongoing to address those issues. This impact the whole desktop ecosystem, it's a massive effort.
Wayland will replace X though indeed (coupled with other things) that's the intent.
> The difficulty arise from the complexity of the problems to solve.
What problems are those exactly? It's my impression that Wayland (the protocol) just creates problems without solving any.
> Wayland is just one part of the big efforts that are ongoing
Yes. The anti-user anti-general-purpose-computing anti-freedom efforts. Trying to create a world where device owners may use their devices only for a set of approved actions such as browsing Instagram and Tiktok. When someone speaks against it, they are attacked with FUD, and "security" is called upon. Does that remind you of anything?
None of those comments have an actual example.
I still have no idea what you complain about, there's really not much difference between using gnome on wayland and gnome on X11
or Sway and I3. In the wayland counterparts though some of the security problems at the core of x11 have been addressed, and input and display just works better.
There's no-one forcing you to do anything or forbiding you to do anything.
> there's really not much difference between using gnome on wayland and gnome on X11
Yes, looking just at big DEs there's not much difference. Consider, however, the problems Wayland causes for the ecosystem. Take screen grabbing programs or input event interceptors like xdotool. There's simply no way to implement one of those strictly on Wayland. Each Wayland compositor must be targeted separately instead.
This is discussed in some of the threads I linked to, BTW.
Fragmentation galore, pretty sure you're actually reinforcing my point with these examples. Can one rely upon any of these hacks, extensions and third-party APIs working for all systems with a Wayland compositor? Some of these are compositor specific, and some are implemented independently of Wayland, but then of course depend on other stuff that's not universal.
The current ydotool goes in another direction, it tries to be independent of Wayland, but this also means it doesn't know your keyboard layout, making it less useful. It also requires a privileged daemon running on my system, something I wouldn't give to such an obscure project.
These problems don't even exist for X11 users because implementing such functionality is easy because it's supported by X.
> a form of argument and an informal fallacy of having the impression of refuting an argument, whereas the real subject of the argument was not addressed or refuted, but instead replaced with a false one
Xdotool is just one of many tools for automation on x11, it's not part of xorg.
There's also Xautomation, AutoKey and others.
What's the difference? There is absolutly none. Where is there more fragmentation?
I'm not refuting anything you still haven't brought any argument at all :D
I’ve seen it so many times.. what is flawed with Wayland? Do you even have sufficient knowledge on the topic to have a fact-based opinion on it? Because 1) wayland is made by the very people who maintained X for decades, 2) it is a deliberately small-core protocol which is extensible - which allows future growth. That small core is quite easy and elegant, it can hardly be flawed, unless you have something concrete to say about that. It is pretty much “display this buffer of type X” and that’s it.
The protocol doesn't support most essential features, leaving them up to "compositors" to implement mutually incompatibly. Screenshots, accessibility, etc.
Thus Wayland promotes fragmentation and death of the Linux desktop.
On top of not actually solving problems, the protocol manages to be too opinionated, forcing compositing on the user.
You're joking about 'forcing' right? There are so many decisions in modern operating systems that are not easy to change. Are you mad at Linux for 'forcing' you into 'rwx' filesystem security? Or 'forcing' you to use iptables for configuring your firewall?
Other desktop environments shifted to compositing 15 years or longer ago since it performs better on modern GPU's than the old 'damage check and repaint' algorithms. I don't think it's impossible to do that with Wayland, but since nobody tried to build that I think interest is very low.
> Thus Wayland promotes fragmentation and death of the Linux desktop.
First of all, what is dead may never die. Second of all, no, it is false. The core protocol is indeed small (unix philosophy ain’t a good thing now for some reason I guess?), but the extensions are easily queriable and they undergo standardization if they are deemed useful. Would you prefer a single entity giving directions on what has to be included? That would seem pretty antithetical to the whole bazaar style of development.
I don’t think Wayland will fail. I’ve been running it for about a year now (since Fedora 34). It’s been mostly smooth sailing, and a big quality of life improvement, with only a few drawbacks. (Screensharing does not work for all windows, such as my terminal.)
- Games are much better behaved. I can reliably window, maximize and full-screen them. They also never mess with the display resolution.
- Seems to have less windows (especially hover tool tips) just hanging around. I guess the compositor can close these at the right time under Wayland.
- Proper secure screen locking. (I think GNOME + GDM can do something safe on X but most display managers + lock screens can't cooperate well enough to manage this.)
Honestly it is nothing major (except the mixed dpi stuff) but a nice step up. And if the X devs say that X is unmaintainable and this is going to lead to many improvements and be able to be maintained for the next age of displays on Linux I'm happy to make the switch now that it is the default and I am not aware of any problems for my workflow.
Thanks, I get all the arguments from the developers and that it should be better in principle in the long run. But I need screen sharing, screen shots, and of course xsnow ;-)
Screen sharing and screenshots have been working perfectly for me (in fact screenshots are actually better with multi-monitors than X because they don't mess up the off-screen space). No comment about xsnow ;)
I think screenshots work out-of the box for most compositors and screenshot tools but depending on your distro you may need to configure xdg-desktop-portal for screen recording. On my distro (NixOS) this seems to work on GNOME with no additional config.
For NixOS configuring GNOME which uses Wayland by default (if your GPU supports it) is just:
Mostly what the other commenter said. Smooth scrolling / no tearing, no weird visual glitches (like the big black rings around all windows when changing resolution or logging out), etc.
Yeah, I've been on Wayland and Sway for almost two years now. Screen sharing with Zoom was hit or miss for a while but is now relatively reliable (at least as much as Zoom is reliable). I can't really quantify anything, but it definitely feels like better performance and reliability than I used to get with Xorg (on a dual 4K monitor setup).
I'm using Gnome 40/Fedora 34 with laptop and attached 4K display. Gnome apps works absolutely fine. Some non-gnome apps do not re-scale when moved between displays and that's the only issue that I've found.
Also I run Factorio absolutely fine. No idea about other games, though.
BTRFS has stabilized outside of niche configurations like RAID5/6. With Wayland common hard- and software combos are still cause for lockups and the like. I can't get it to not crash an various bog standard all-Intel hardware, for no apparent reason. The internet is full of such (recent) reports.
Worth pointing out that for the longest time, Firefox on Wayland was borking the clipboards regularly, forcing a restart of the whole stack (at least on Gnome).
That pushed a lot of people to use the X versin of firefox, even if on Wayland.
It seems to be fixed for me now but eh... who knows
Which way around is that? Firefox would be unable to use it's Clipboard and require restarting, or Wayland would require restarting.
If it's the later, would it not imply a shaky foundation if an app is able to brick the systems compositor with something as simple as clipboard access?
At least for me it would hang the app trying to retrieve the clipboard value that was set by Firefox. It would continue to hang until I either a) copied data from another app, or b) reloaded sway.
In Wayland the data of the clipboard stays in the app where it was "added" to the clipboard and only transit between the application where it was copied to the app where it is pasted when pasted.
I think the issue was at this transit stage on Firefox side.
It didn't have any impact on the compositor, it would behave differently in the receiving app. Some would crash, some would freeze for a bit, some would be totally fine but would just fail to get the data to paste.
> In Wayland the data of the clipboard stays in the app where it was "added" to the clipboard and only transit between the application where it was copied to the app where it is pasted when pasted.
Back to the future...
This was how the Amiga clipboard functionality worked (at that point it was because it saved memory), though you could push the data into separate clipboard storage if necessary (e.g. if an application was about to close while a clip was active, or because an application requested a paste).
This was such a frustrating issue and was glad when it was finally fixed. My next bug bear is screen sharing on Wayland. I use a massive monitor and wlroots/sway (I have no idea where the functionality should lie) doesn’t really offer a nice way to share either a specific window or screen range.
Chrome has a nice feature where you can share Chrome itself or a specific tab which somewhat mitigates this problem for me so it would be great if Firefox had the same ability. Ultimately it would be great if I could just share anything but the progress on https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issue... is not quite there yet. I just wish I knew how the stack worked so I could potentially judge what the effort would be but I feel like it would he a massive rabbit hole which I just can’t afford.
This actually works somewhat today, but it's all a little hit and miss.
For Wayland I believe the currently accepted way if doing screen sharing is through xdg-desktop-portal which has a backend for wlroots and a bunch of other common compositors. I have gotten this to work fairly decently with Firefox at least, but some things are a bit hacky.
Thanks, I use this for sharing the screen but it only allows me to share a specific screen. It does not offer the ability to share a region [1] or specific window [2] on that screen. Supposedly this is due to API limitations in wlroots or some lower component.
Thanks, I can share the entire screen, I just want some way to share either a region of the screen or specific window. I have a hack that sets up a stream through the webcam but this is clunky and annoying to set up. Plus it means that the screen is shared as a webcam on messaging apps which doesn't always work too well (different people are highlighted as they talk). Sharing my entire screen isn't really that great as the resolution is 5120x1440 and it doesn't really display well for others.
Exactly. Wayland is unusable for me on current Debian family distros because tools like Slack and Teams can't share screens properly and IME just about everyone now uses some tool like that for remote working. None of the other advantages matters much if I can't send essential communications without logging out and then starting a new X session first.
Does Firefox default to Wayland these days on wayland-default distros? I seem to recall, using a Linux laptop for work just a year or so ago, that I had to set a couple of config variables manually that were really really easy to screw up. Ended up using the X version of FF for a while on Wayland until I figured out what was causing issues in my environment.
My FF-related reason for using X11 that drag&drop from FF to Nemo doesn't work under sway but does work under i3. Trying several combinations of environment variables to switch between native and xwayland mode didn't make a difference.
The second reason, not related to FF, is that wine-wayland is still experimental.
Wayland is the new option, that surprisingly (since X is quite ugly) manages to have a much worse design than X.
Wayland (as a consequence of its design) isn't really a single option, rather each DE and WM does it's own implementation of lots of stuff, with different interfaces. So please don't use it as you would be supporting fragmentation and death of the Linux desktop.
> Wayland is the new option, that surprisingly (since X is quite ugly) manages to have a much worse design than X.
Citation needed.
And no, it doesn’t support fragmentation - it is a protocol with multiple implementations - which is a good thing! It means that noone will code against the implementation, but the protocol. (And in practice, there are very few non-standard extensions that supposed to be cross-platform. Those are mostly for DE-specific functions)
TBH I remember your other comments about Wayland across many threads, and most of them have a quality of being confused in such a manner as to provoke long answers and derail the discussion.
> a protocol with multiple implementations - which is a good thing
The protocol is severely lacking in features. This means the "compositors" end up doing most stuff independently of Wayland, in mutually incompatible way of course. Thus the fragmentation of the Linux desktop: Gnome vs KDE vs wlroots, etc.
Am I more of a troll than the other low-effort comments claiming false things like “wayland manages to have worse design than X (without any concrete example)”, or that it causes fragmentation in desktop when fragmentation has always been a thing? Good luck using anything dbus-related thing under a minimal wm like dwm.
Sorry for calling you a troll. That wasn't fair to you, and also isn't good for the discussion.
> fragmentation
No, Wayland introduces new sources of fragmentation that did not exist before. Imagine trying to write a screenshotting program, or an xdotool replacement.
> Good luck using anything dbus-related thing under a minimal wm like dwm.
X11’s desktop tooling heavily relies on dbus for many features. Eg. accessibility is implemented with dbus, which may not be supported by niche window managers. With wayland, now we have a good way to extend the protocol (while it was basically impossible with X due to its age). Of course the dbus-related fragmentation is still here, because not every feature maps cleanly to “it is a display-related feature” that should go into wayland, or “it requires general IPC” and should go into dbus.
But unfortunately due to the bazaar style of development, fragmentation will always be a central part of linux, which is both good and bad.
X11 is an ancient protocol originally developed for network use (with many graphical terminals connected to one server), it's mature in terms of features but has some inherent security issues. Apps can easily monitor your entire and there's no easy way to block that. It's also more prone to tearing. It was never intended to be frame-perfect in terms of timing. It supports network transparency which is great because you can start remote GUI programs over an SSH session.
Wayland addresses some performance and security issues of X11 but still lacks some features. Apps need to be developed specifically for it (though dual stack is possible) which hinders adoption also. For example screen recording is often an issue. This is partly due to security but also because of it not being recognised as a major usecase from the start. Also, drivers are more of an issue with Wayland. Wayland doesn't have network transparency which I miss a lot.
The benefits of Wayland are:
- Much better graphical stack (no more tearing, weird graphical glitches, fractional scaling support without blurring for Wayland native apps)
- Much improved security (on x11, any app has access to all your input, your clipboard and everything that is displayed, all the time), on Wayland an app only know about it's own buffer, its own clipboard and has input access when focused).
Not a plus or downside but interesting thing is that the ecosystem growing around Wayland is harmonizing the desktop environments (finally!)like pipewire now replacing pulse-audio, jack and alsa together or xdg-desktop portal allowing to use the file picker of your environment rather than the one from the library an app is built with (for example, kwrite on gnome would use the gnome file picker).
The downsides of Wayland are:
- A few apps are not playing nicely, like Zoom
- Nvidia support is finally getting better, but from what I can read it's not totally smooth yet.
- KDE is more stable on X11 than Wayland from what I read. but they are focusing on Wayland this year.
- It changed a LOT recently, more conservative distro based on LTS or releases that are a few major version behind like Debian will carry issues that have been fixed since.
- Some tools relying on x11 specific functionalities might not work, it can be necessary to spend a bit of time to find some alternatives.
The way I see it, if your distribution default to x11, stick with it. If it isn't, it's worth a try
X11 is just a protocol too. There's no shared codebase used by all implementations of X11 either.
But the reason for that misconception is presumably that what most users would customise with X was replacing the WM - there was little demand for lots of different X servers other than for very specific needs or different platforms.
Meanwhile with Wayland, we need a compositor to replace every X wm people still care about.
For me, that's the big blocker - as long as there's no drop-in replacement for bspwm, it's a hassle for me to move over and none of the "benefits" of Wayland matter to me.
(EDIT: In fact, because of how Wayland shifts responsibilities, Wayland has led to more code being shared between compositors via projects like wlroots because the burden to implement a Wayland compositor is far higher than to implement a window manager for X, and more people care about window management functionality than the low level server functionality; eventually I believe and hope we'll end up with a couple of dominant compositors with a common set of extensions supported for all the "missing" X functionality, including a wm extension, and we'll be back at pretty much parity with X)
The missing compositor issue will change a lot I believe very soon. Wlroots[1] just recently landed their scene graph api which enables building wayland compositors with full damage tracking support without needing to touch some of the low level stuff like rendering and buffer management. For example I am currently working on my own wayland compositor and it is super easy to use. Really excited for the future!
[1]: https://gitlab.freedesktop.org/wlroots/wlroots
I think my issue is that there shouldn't be a need for this proliferation of compositors. Wlroots is making that slightly less ridiculous, but wlroots itself is mostly necessary because nobody has bothered creating a WM extension for the Wayland protocol.
I'm not excited. There's no reason we should need dozens of compositors that are mostly identical apart from code that could easily live in a separate process.
That wlroots is getting better at making it easier to build a compositor is a poor bandaid from just removing the need to build a compositor at all.
It's one of many examples of Wayland throwing the baby out with the bath water.
I’m not sure I follow. Is your issue with Wayland that it’s not like x11 with a separate server and window manager? Someone can come along and write that in the future if that’s your preference.
As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit. Right now wlroots makes it easiest but if in a few years another implementation proves to be better, all those client programs aren’t going to stop working. For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.
Yes. My point above is that one of the barriers to replacing X is that the barrier to writing a compositor for Wayland is far higher than the barrier to writing a window manager for X. And while wlroots is slowly addressing that you're still stuck with the issue that wlroots requires far larger bindings to other languages for example, than what is required to write a WM for X, and is becoming a larger and larger dependency, even as most wm's only want to customise a tiny portion of the functionality of other compositors.
Until there is a compositor offering the same ease, either a bunch of WM's people use and care about won't get an equivalent for Wayland, or it will take a lot more time and effort.
As it is, for example, I'm not moving to Wayland before there's a drop-in replacement for bspwm. River seems to be close-ish to being able to offer something like that, but the benefits of Wayland do not really matter to me and so I have no interest in investing time in replacing bspwm for minimal gain.
> As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit.
This is true for X11 as well. X11 is just a protocol. But in practice we ended up with a small set of implementations exactly because the pain of implementation was too high, and even most separate servers (e.g. Xephyr for example, or, in fact Xwayland) were often based on Xorg the way many Wayland compositors are based on wlroots.
But that is with the APIs allowing out of process WMs. For Wayland the lack of a WM protocol means you can't avoid a higher proliferation of compositors until someone adds such an API, and it'll hold back development by making a lot of people spend time duplicating compositor code for no good reason.
> For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.
It's great that it's getting easier, but the point is this is the "wrong order" - if you have even a fairly basic WM API very few WMs will care about the scene graph at all. It's like people are intent on ignoring the lessons of what actually worked well with X.
It's really not my problem - I'll stay on Xorg until Wayland is more suitable, however many years that might take. But anyone who cares about Wayland ought to take seriously that the proliferation of compositors will become a nightmare, whether or not more and more of them depend on wlroots, as it means more and more packages to rebuild, test and distribute whenever there are wlroot fixes, for example, for very little gain vs. simply moving the bits that will differ between wm's out of process.
Be aware that some other unixes are often corned as Linux.
I use Firefox on FreeBSD and most third party websites identify me as Linux (except Firefox itself). I can't run Wayland because KDE on Wayland is currently broken on FreeBSD :)
147 comments
[ 2.8 ms ] story [ 239 ms ] threadI do have an AMD gpu though.
I could have sworn that I tried it in the past and it didn't work... Ok, so that was my last reason to use X...
Wayland should surely be able to at least match that!
Individual pixel buffers should still be faster if only some of them change regularly, right?
I think the real question is why can't the display manager just be a browser, plus some backwards compatibility for "here's a bunch of pixels"..
All the RAM use issues of Electron go away if the whole desktop is a single shared browser, plus you can do client side JS work and not need to send any data at all for a lot of things, AND you can cache things, plus you can decompress video client side, play sound on the client...
Just do HTTP over UNIX domain sockets with some signalling to tell the server to open a window.
You take a protocol that works, then you make a new "Modern flexible unopinionated" protocol and invite people to make their own versions with lots of incompatibilities.
The cases where fractional scaling doesn't work on Wayland are when you're running an app through XWayland. In those cases, I'd just find an alternative that works with Wayland. That's also what lead me to switch to Firefox full-time - Chromium's Wayland support lagged behind quite a bit.
What's also kinda sad and funny is that X11 has had from day 1 support for different DPIs on different displays. But most programs just ignore X11s DPI setting and assume it's 96ppi. It also conflicts with modern multi-monitor on Linux which essentially fakes one giant display so you can drag windows across. There is some drawbacks but if you config each monitor to be a separate X11 display with the proper DPI and use compatible programs like Alacritty it kinda just sorta works.
This is unfortunate, since many applications can scale just fine, but only through older hacks. Chrome and Electron applications will scale just fine by providing a proper DPI. Same for very old apps. GTK and QT applications will not, but they scale just fine by setting appropriate environment variables.
In practice, this leads to the experience often being better on X11. I've found KDE X11 to handle this the best, with the limitation being a single global scale, only certain fractions allowed and needing to restart KDE after changing it.
GNOME with Ubuntu patches and Xfce will scale everything x2 and use RandR to provide a higher virtual resolution. This has performance costs and messes with cursor speed (measured in pixels) but otherwise also produces good results.
Also, there is some ongoing work on Wayland in Java - https://www.phoronix.com/scan.php?page=news_item&px=Wakefiel...
[1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Also libinput via sway doesn't have a way to disable the touchscreen if I'm using a stylus as far as I'm aware.
I'm sure there are solutions to some of these, but given I already spend a significant amount of time fiddling with my NixOS configuration I'm already quite an outlier with regards to the amount of effort I am willing to spend and even I'm exhausted.
Have I forgotten how to read graphs?
Edit: Graph starts at 90%, oh how I hate when they do that.
> X11 is showing to be in use above 90% over the span of this multi-month data and on average seems to be about 93% currently to Wayland at roughly 7%.
If the chart was really supplied by the Mozilla Telemetry team then it's quite an embarrassment. When analytics is your profession you should know better than to do things like use red and blue alongside each other. Even if you're not colorblind, #afa7f4 (desaturated blue) and #98b4fe (desaturated purple) are hard to distinguish because Chrome says the contrast ratio is 1.06. See https://personal.sron.nl/~pault/ to learn more.
Because after so many years, a lot of the ecosystem hasn't moved, or is even not compatible with it. Good multi display support is missing, and some games don't render well.
I want it to succeed, and the project has been progressing non-stop, but it does show how much time and energy such an endeavor takes. I was expecting to be able to use it for years and years.
See also: BTRFS
You must perform regular maintenance on btrfs or it will quite simply break. This is a huge departure from for example ext4, which is (to the end user at least) hassle free.
- a few years ago, one system would suddently not boot (due to btrfs); this happened twice
- nowadays, on one system, background scrub doesn't start
This is anecdata of course, but I've never had a good impression overall. I don't see any reason to use btrfs rather than ZFS, considering that Ubuntu and derivatives are starting to add builtin support.
Scripts for actually doing so can be found f.e. here: https://github.com/kdave/btrfsmaintenance
Actually the fact that X11 can be used today despite the fact that we went through several cycles of vastly changing GPU hardware shows that it absolutely has stood the test of time.
The X server became a pretty useless middle man between clients and the compositor. And the vastly changed GPU hardware is the reason we should prefer a superior solution - we no longer draw as we did 3 decades ago, so we should cut out the middle man.
Terminal applications stood the test of time as well. For everything that is not graphical in nature they are indeed good solutions.
> The X server became a pretty useless middle man between clients and the compositor.
X is a middle man but far from useless. Just as Wayland is a middle man as well. And looking at the protocol actual access to GPU memory is more opaque on Wayland than on X11 and as such to me Wayland is a more intrusive middleman.
If you want to "cut out the middle man" you have to use DRM directly.
Wayland is not a middle man as it is the compositor itself as well - it does the minimal amount of work necessary to compose the desktop. X on the other hand just transfers messages between clients and the compositor without doing any actual work (x render functions are almost never used by modern applications)
Also, DRI3 doesn’t solve the fundamental security flaw of X - which can only be solved by nesting multiple X servers into each other. At that point we would have a much uglier architecture than we have with wayland.
But the problem is basically: you can either have 1-2-4-8 cores at most writing pixels into a buffer one after another (but due to the complexity of interactive GUIs it will most often be single threaded), so a circle will be displayed as going over an area and coloring each pixel.
Versus specifying some condition and having the GPU run it on every pixel in large batches, almost doing it in one go. Of course for 3 lines, what previous GUI iterations were, you don’t need gpu, but for gradients, media!, and basically a bunch of other things you simply need the GPU’s orders of magnitude more parallelism. Add to the picture that we are using much bigger screen resolutions (full hd has 6x number of pixels compared to 480p, and then we are not even talking about 4k. And 120, 240fps monitors are a thing now) and you can quickly see that 1) drawing is a greatly parallelizable task 2) having it done serialized simply doesn’t scale to today screens.
This is because said graphical applications are designed to be used with a modern GPU and they use stuff like OpenGL to render their components.
"but for gradients"
Maybe we can go without them. Modern UIs are too heavy, latency-inducing, battery consuming, and can turn your device into a heater easily.
"And 120, 240fps monitors are a thing now"
Re-drawing the window in every frame is a wasteful action that tends not to happen with applications designed for software rendering.
While you may not like gradients, animations (which absolutely mandate GPUs) for example do give context on what happens because humans are used to physical objects that don’t teleport from one place to another. I wouldn’t consider these needless features either.
And, may I ask,why are you so quick to dismiss the core developers of X?
Except new GPU hardware at reasonable prices has been unobtainable for 2 years now, and AMD's new Linux friendly stance was only a couple of years before that. So there's like a 2-3 year window where you could have said "Well, you should have known to buy the FOSS friendly hardware". (Which came with other tradeoffs, AMD had uncompetitive hardware and poor GPGPU support in that time period)
I have seen various comments claiming that the code was very clean.
"Since the late 00s, all of the window managers had already started doing compositing themselves"
Most window managers don't do compositing.
Also, XCB is async.
The reason it takes so much time is not that is requires a lot of "energy" or that the problem in general is particular hard to solve. Wayland is fundamentally flawed at the concept level and the only way for it to get to a usable state is to turn it essentially into another X. Combine this with general stubbornness of all involved parties and the extreme hesitancy to standardize essential things you get a recipe for disaster.
This is a fallacy.
If I start making wild claims about cardiology, you'd be correct to ask me for some credentials.
And yes, it is the fallacy of credentialism to attempt to use that as a measure of authority to make a statement. I could be a kernel developer of 20 years experience and have been terrible for all of them.
Whether the whole ecosystem is already in place to move regular users over is another matter (I'm developing a Wayland compositor at work and even I am still using X11 on my workstation), although with this kind of project I guess you just need to face the chicken-and-egg problem at some point to actually move things forward.
Not a problem with Wayland, it's just as you say, not there yet.
The difficulty arise from the complexity of the problems to solve.
In a x11 world, the assumption is that everything that a user runs is fully trusted, any software has access all the inputs, all the audio, everything that is displayed without any restriction. This wasn't a problem 30 years ago, but is quite a blocker for modern approach to security with granular permissions.
The architecture of x11 itself does not fit a modern graphical stack, some problem cannot be solved properly like monitors with different framerates, fractional scaling etc...
Wayland is just one part of the big efforts that are ongoing to address those issues. This impact the whole desktop ecosystem, it's a massive effort.
Wayland will replace X though indeed (coupled with other things) that's the intent.
What problems are those exactly? It's my impression that Wayland (the protocol) just creates problems without solving any.
> Wayland is just one part of the big efforts that are ongoing
Yes. The anti-user anti-general-purpose-computing anti-freedom efforts. Trying to create a world where device owners may use their devices only for a set of approved actions such as browsing Instagram and Tiktok. When someone speaks against it, they are attacked with FUD, and "security" is called upon. Does that remind you of anything?
Some relevant past comments:
https://news.ycombinator.com/item?id=26753902
https://news.ycombinator.com/item?id=26758783
https://news.ycombinator.com/item?id=24886074
https://news.ycombinator.com/item?id=26758945
Yes, looking just at big DEs there's not much difference. Consider, however, the problems Wayland causes for the ecosystem. Take screen grabbing programs or input event interceptors like xdotool. There's simply no way to implement one of those strictly on Wayland. Each Wayland compositor must be targeted separately instead.
This is discussed in some of the threads I linked to, BTW.
The portal for xdg-desktop takes care of the implementation and is the responsibility of the compositor.
It's already used by Flameshot for example.
There is several xdottool equivalent as well: https://github.com/atx/wtype https://github.com/ReimuNotMoe/ydotool
This one is specific to wlroot based compositor: https://git.sr.ht/~brocellous/wlrctl
The current ydotool goes in another direction, it tries to be independent of Wayland, but this also means it doesn't know your keyboard layout, making it less useful. It also requires a privileged daemon running on my system, something I wouldn't give to such an obscure project.
These problems don't even exist for X11 users because implementing such functionality is easy because it's supported by X.
2. You respond by giving a bunch of examples that align with my statement, but you don't seem to realize this.
3. I clarify.
4. Suddenly I don't operate in good faith?!
What's worse, your replies attack straw versions of my comments: https://en.wikipedia.org/wiki/Straw_man
> a form of argument and an informal fallacy of having the impression of refuting an argument, whereas the real subject of the argument was not addressed or refuted, but instead replaced with a false one
I'm not refuting anything you still haven't brought any argument at all :D
The protocol doesn't support most essential features, leaving them up to "compositors" to implement mutually incompatibly. Screenshots, accessibility, etc.
Thus Wayland promotes fragmentation and death of the Linux desktop.
On top of not actually solving problems, the protocol manages to be too opinionated, forcing compositing on the user.
Other desktop environments shifted to compositing 15 years or longer ago since it performs better on modern GPU's than the old 'damage check and repaint' algorithms. I don't think it's impossible to do that with Wayland, but since nobody tried to build that I think interest is very low.
First of all, what is dead may never die. Second of all, no, it is false. The core protocol is indeed small (unix philosophy ain’t a good thing now for some reason I guess?), but the extensions are easily queriable and they undergo standardization if they are deemed useful. Would you prefer a single entity giving directions on what has to be included? That would seem pretty antithetical to the whole bazaar style of development.
- Tear free rendering and capturing.
- (Small) improved performance.
- Games are much better behaved. I can reliably window, maximize and full-screen them. They also never mess with the display resolution.
- Seems to have less windows (especially hover tool tips) just hanging around. I guess the compositor can close these at the right time under Wayland.
- Proper secure screen locking. (I think GNOME + GDM can do something safe on X but most display managers + lock screens can't cooperate well enough to manage this.)
Honestly it is nothing major (except the mixed dpi stuff) but a nice step up. And if the X devs say that X is unmaintainable and this is going to lead to many improvements and be able to be maintained for the next age of displays on Linux I'm happy to make the switch now that it is the default and I am not aware of any problems for my workflow.
I think screenshots work out-of the box for most compositors and screenshot tools but depending on your distro you may need to configure xdg-desktop-portal for screen recording. On my distro (NixOS) this seems to work on GNOME with no additional config.
For NixOS configuring GNOME which uses Wayland by default (if your GPU supports it) is just:
I'm not aware of any major issues with this and in my experience provides a better experience than using X.I'm using Gnome 40/Fedora 34 with laptop and attached 4K display. Gnome apps works absolutely fine. Some non-gnome apps do not re-scale when moved between displays and that's the only issue that I've found.
Also I run Factorio absolutely fine. No idea about other games, though.
That pushed a lot of people to use the X versin of firefox, even if on Wayland.
It seems to be fixed for me now but eh... who knows
If it's the later, would it not imply a shaky foundation if an app is able to brick the systems compositor with something as simple as clipboard access?
I think the issue was at this transit stage on Firefox side.
It didn't have any impact on the compositor, it would behave differently in the receiving app. Some would crash, some would freeze for a bit, some would be totally fine but would just fail to get the data to paste.
Back to the future...
This was how the Amiga clipboard functionality worked (at that point it was because it saved memory), though you could push the data into separate clipboard storage if necessary (e.g. if an application was about to close while a clip was active, or because an application requested a paste).
Chrome has a nice feature where you can share Chrome itself or a specific tab which somewhat mitigates this problem for me so it would be great if Firefox had the same ability. Ultimately it would be great if I could just share anything but the progress on https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issue... is not quite there yet. I just wish I knew how the stack worked so I could potentially judge what the effort would be but I feel like it would he a massive rabbit hole which I just can’t afford.
For Wayland I believe the currently accepted way if doing screen sharing is through xdg-desktop-portal which has a backend for wlroots and a bunch of other common compositors. I have gotten this to work fairly decently with Firefox at least, but some things are a bit hacky.
https://github.com/emersion/xdg-desktop-portal-wlr
[1] https://github.com/emersion/xdg-desktop-portal-wlr/issues/15... [2] https://github.com/emersion/xdg-desktop-portal-wlr/issues/10...
Exactly. Wayland is unusable for me on current Debian family distros because tools like Slack and Teams can't share screens properly and IME just about everyone now uses some tool like that for remote working. None of the other advantages matters much if I can't send essential communications without logging out and then starting a new X session first.
Percentage of users running Firefox using Wayland WM/DE or percentage of users running Firefox with enabled Wayland support?
These numbers in theory could be dramatically different, as Firefox with enabled Wayland is not a default yet.
The second reason, not related to FF, is that wine-wayland is still experimental.
Is there a summary somewhere that explains why, or if, it would benefit me to put any effort into switching?
Wayland (as a consequence of its design) isn't really a single option, rather each DE and WM does it's own implementation of lots of stuff, with different interfaces. So please don't use it as you would be supporting fragmentation and death of the Linux desktop.
Citation needed.
And no, it doesn’t support fragmentation - it is a protocol with multiple implementations - which is a good thing! It means that noone will code against the implementation, but the protocol. (And in practice, there are very few non-standard extensions that supposed to be cross-platform. Those are mostly for DE-specific functions)
> a protocol with multiple implementations - which is a good thing
The protocol is severely lacking in features. This means the "compositors" end up doing most stuff independently of Wayland, in mutually incompatible way of course. Thus the fragmentation of the Linux desktop: Gnome vs KDE vs wlroots, etc.
> fragmentation
No, Wayland introduces new sources of fragmentation that did not exist before. Imagine trying to write a screenshotting program, or an xdotool replacement.
> Good luck using anything dbus-related thing under a minimal wm like dwm.
Not sure what you're trying to say.
But unfortunately due to the bazaar style of development, fragmentation will always be a central part of linux, which is both good and bad.
?
I never had such an issue.
Wayland addresses some performance and security issues of X11 but still lacks some features. Apps need to be developed specifically for it (though dual stack is possible) which hinders adoption also. For example screen recording is often an issue. This is partly due to security but also because of it not being recognised as a major usecase from the start. Also, drivers are more of an issue with Wayland. Wayland doesn't have network transparency which I miss a lot.
Personally I still use X11 :)
Not a plus or downside but interesting thing is that the ecosystem growing around Wayland is harmonizing the desktop environments (finally!)like pipewire now replacing pulse-audio, jack and alsa together or xdg-desktop portal allowing to use the file picker of your environment rather than the one from the library an app is built with (for example, kwrite on gnome would use the gnome file picker).
The downsides of Wayland are: - A few apps are not playing nicely, like Zoom - Nvidia support is finally getting better, but from what I can read it's not totally smooth yet. - KDE is more stable on X11 than Wayland from what I read. but they are focusing on Wayland this year. - It changed a LOT recently, more conservative distro based on LTS or releases that are a few major version behind like Debian will carry issues that have been fixed since. - Some tools relying on x11 specific functionalities might not work, it can be necessary to spend a bit of time to find some alternatives.
The way I see it, if your distribution default to x11, stick with it. If it isn't, it's worth a try
Which leads to a big misconception that many users have, even here on Hackernews.
"Wayland doesn't support Y" or "Z doesn't work on Wayland" statements only make very limited sense.
Wayland is just a protocol. Unlike X, there is no shared codebase that is used by all implementations - aka compositors.
There are several important compositors, all with their own individual quirks. Which is part of the problem...
I would like to know more about that. Have you some resources that demonstrate that?
> Depending on the compositor of course.
Which one do you use?
on Gnome 41
No. Essential features depend on the "compositor" because Wayland doesn't support them. You're mixing up interface and implementation.
But the reason for that misconception is presumably that what most users would customise with X was replacing the WM - there was little demand for lots of different X servers other than for very specific needs or different platforms.
Meanwhile with Wayland, we need a compositor to replace every X wm people still care about.
For me, that's the big blocker - as long as there's no drop-in replacement for bspwm, it's a hassle for me to move over and none of the "benefits" of Wayland matter to me.
(EDIT: In fact, because of how Wayland shifts responsibilities, Wayland has led to more code being shared between compositors via projects like wlroots because the burden to implement a Wayland compositor is far higher than to implement a window manager for X, and more people care about window management functionality than the low level server functionality; eventually I believe and hope we'll end up with a couple of dominant compositors with a common set of extensions supported for all the "missing" X functionality, including a wm extension, and we'll be back at pretty much parity with X)
I'm not excited. There's no reason we should need dozens of compositors that are mostly identical apart from code that could easily live in a separate process.
That wlroots is getting better at making it easier to build a compositor is a poor bandaid from just removing the need to build a compositor at all.
It's one of many examples of Wayland throwing the baby out with the bath water.
As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit. Right now wlroots makes it easiest but if in a few years another implementation proves to be better, all those client programs aren’t going to stop working. For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.
Until there is a compositor offering the same ease, either a bunch of WM's people use and care about won't get an equivalent for Wayland, or it will take a lot more time and effort.
As it is, for example, I'm not moving to Wayland before there's a drop-in replacement for bspwm. River seems to be close-ish to being able to offer something like that, but the benefits of Wayland do not really matter to me and so I have no interest in investing time in replacing bspwm for minimal gain.
> As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit.
This is true for X11 as well. X11 is just a protocol. But in practice we ended up with a small set of implementations exactly because the pain of implementation was too high, and even most separate servers (e.g. Xephyr for example, or, in fact Xwayland) were often based on Xorg the way many Wayland compositors are based on wlroots.
But that is with the APIs allowing out of process WMs. For Wayland the lack of a WM protocol means you can't avoid a higher proliferation of compositors until someone adds such an API, and it'll hold back development by making a lot of people spend time duplicating compositor code for no good reason.
> For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.
It's great that it's getting easier, but the point is this is the "wrong order" - if you have even a fairly basic WM API very few WMs will care about the scene graph at all. It's like people are intent on ignoring the lessons of what actually worked well with X.
It's really not my problem - I'll stay on Xorg until Wayland is more suitable, however many years that might take. But anyone who cares about Wayland ought to take seriously that the proliferation of compositors will become a nightmare, whether or not more and more of them depend on wlroots, as it means more and more packages to rebuild, test and distribute whenever there are wlroot fixes, for example, for very little gain vs. simply moving the bits that will differ between wm's out of process.
I use Firefox on FreeBSD and most third party websites identify me as Linux (except Firefox itself). I can't run Wayland because KDE on Wayland is currently broken on FreeBSD :)
I don't know much about window servers and have no idea why I should use Wayland instead of X.
What to do: eat the bullet and change the default of the mainstream distros.