Less Than 10% of Firefox Users on Linux Are Running Wayland
phoronix.com
phoronix.com
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
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.
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.
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.
[1] https://github.com/emersion/xdg-desktop-portal-wlr/issues/15... [2] https://github.com/emersion/xdg-desktop-portal-wlr/issues/10...
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).
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
- 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:
services.xserver = {
enable = true;
displayManager.gdm.enable = true;
desktopManager.gnome.enable = true;
};
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.
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
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.
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.
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.
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.
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
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.
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.
[1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Also, there is some ongoing work on Wayland in Java - https://www.phoronix.com/scan.php?page=news_item&px=Wakefiel...
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.
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.
I 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...
I don't know much about window servers and have no idea why I should use Wayland instead of X.
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...
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 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
Is there a summary somewhere that explains why, or if, it would benefit me to put any effort into switching?
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
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 :)
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.
?
I never had such an issue.
> 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.
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.
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.
The second reason, not related to FF, is that wine-wayland is still experimental.
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 :)
What to do: eat the bullet and change the default of the mainstream distros.