I didn’t even realize desktop applications could/should implement the Wayland protocol. I thought it was just WM’s (and some DE’s?) that needed to do that, basically anything that directly replaces X, but not the apps running on it. Is this something every Linux desktop application will need to do?
Desktop applications can continue to use the X11 protocol, but then they'll be talking to the Xwayland server, which in turn Wayland to actually draw its clients' windows on the screen.
But it's preferable to have applications directly use the Wayland protocol, which is what Firefox is experimenting with. For most applications, this is easy because they use some standard toolkit like GTK or Qt, which will transparently use Wayland without the application caring about it. But Firefox uses its own toolkit, so it's a bit more work.
For regular apps the toolkit (Qt / GTK / GDI / Cocoa) handles it. They hide the inner bits of the underlying OS / Graphics API from the apps. Web nowadays is a very free-form environment coming with cross-platform APIs. Using platform specific API and toolkits will create inconsistencies and performance issues. So browsers come with their own rendering engines that uses lower level APIs like Directx and OpenGL. To access GPU video decoders etc., they also need to use those lower level APIs anyway.
Regardless of the OS, when the applications want to directly render things they have to communicate with the lower level graphics backend (Wayland, X, DWM, Metal etc) to agree on a memory area and pixel format and some other things. The OS, the direct rendering system and the window management system together manages what application gets the rendering signal, what area, at what display with what metadata (e.g. DPI, or pixel bits) it is drawn.
Since browsers are writing their rendering system and the components from scratch (not everything, they still use some system GUI components or text input / font rendering stuff), they need to communicate with the lower layer directly to request screen areas to render, to get the correct display DPI/scale to draw things at the correct size with well-aligned pixels and to utilize various hardware stuff like hardware video decoders.
Yes, desktop applications need to implement the Wayland protocol in the same way they need to implement the X protocol. There is a compatibility layer called XWayland which allows you to run Xorg programs under Wayland.
However, running programs under XWayland comes with issues such as lack of proper fractional scaling. This means that although not strictly necessary, from a user's point of view it is desirable to have applications move to Wayland.
Usually, the UI toolkit (gtk, qt, ...) should take care of the X11/Wayland protocol details. But if the application is doing its own thing or at a lower level (and I guess Firefox qualifies) then that has to be adapted.
Yes this is exactly the case here. Many applications get this for free because the gui toolkit provides the abstraction - both Qt and Gtk exist to do this for cross platform purposes.
However if you want things toolkits don't provide then you need to talk to the underlying API yourself.
My distro ships both plain Firefox and firefox-wayland. I've been using it for... At least a year. No noticeable difference to normal Firefox.
The big thing I notice with firefox wayland on nixos are cursor issues. It seems to have fewer cursors and sometimes uses obviously wrong ones (text selection cursor when it should be a pointer). So I'm still using it on xwayland
Single what out, all of them? ,'Electron-the-platform' does then, via which all 'Electron apps' (single thing or not) do, which is what GP's saying? It works this way for Electron-the-platform... And therefore every Electron app that uses it?
The point is that Electron-the-platform is playing a similar role to GTK or Qt: it talks to Wayland, and the application talks to it. Therefore the application is not interfacing directly with Wayland, and claiming that it is would be singling out Electron from the category of UI toolkits.
But it depends on your definition of “application”.
Yeah, I'm not sure how now, but I think I misread/misunderstood the comment I defended. Can't now read it any other way but as a claim that they typically don't use Electron for it and instead talk to X/Wayland directly. (I have no idea, but would have assumed Electron handled it sufficiently for the vast majority.)
For most applications it's usually enough that the toolkit (GTK, Qt, whatever) supports it. However, Firefox probably does some stuff 'outside' what GTK provides, so it needs to implement those bits itself. I'm guessing stuff like <video/> support.
(Wayland is a set of protocols and the toolkit may not support all the protocols or have sub-par support -- in which case the application can choose to do those bits itself.)
Accelerated video decoding is an example. It uses VA-API or VDPAU to decode video onto a surface that is then composited into the final frame entirely on the GPU.
This is the reason there are cross-platform GUI libraries (like GTK and QT) in the first place. Without it them, an application must either sacrifice portability, or manage the same application for multiple different interfaces over multiple OSes, like X Windows, Win32, Cocoa, and Wayland.
Many applications for Windows, OS X, and Linux interface directly with Win32, Cocoa, or X11/Wayland. For example, the Foot terminal emulator only works with Wayland, because the author has chosen not to implement the X11 protocol.
XWayland is a compatibility interface for X apps to still work on Wayland compositors, so it's not mandatory to port everything over to Wayland.
But there should be performance and rendering quality advantages to speaking Wayland natively.
Core X for instance has zero concept of a frame or buffer swapping, X apps like games generally get that via GL. So your average X GUI application tends to be inherently flickery/tear-ful, since draws just get sent out to the X server and display whenever. XOrg drivers have implemented various hacks to try minimize those effects, but it's all very vendor-specific[0] and never perfect since it's a fundamental limitation of the X protocol. You can at best eliminate literal tearing[1], but nothing prevents displaying a partially refreshed window full of changing widgets, each implemented as X subwindows in the classic X fashion, because nothing in the core protocol says "Ok, this top-level window update is finished, present it (and its descendants)!".
That's not even getting into the issues of high dpi and fractional scaling...
Most X servers implement the Xdbe extension for double buffering with clients that supports it, or you can just render into an off screen pixmap first. In other words, if there is tearing or flickering, it's really entirely the clients fault for just blindly choosing to render straight to the window.
Of course you do: You need to allocate a buffer, and you need to commit it to the visible display, exactly the same amount of work to do so under X. If anything, I suggest you look at the sheer amount of code required to put anything on screen with Wayland vs. X - Wayland requires a lot of boilerplate, as the presumption is that everyone would use a widget library.
As far as design goes, Wayland is absolutely awfully verbose for no good reason.
> As far as design goes, Wayland is absolutely awfully verbose for no good reason.
Not to mention that so many fundamental things are optional extensions that there are five completely incompatible extensions for each possible API that Wayland leaves out. Like screenshotting.
I've largely come to the conclusion that 1) X got as bad as it did not for technical reasons but because of designers stuck in the past (see below), 2) Wayland inherited many of the same architecture astronaut attitudes.
You see this if you look at e.g. XRender. XRender was a big improvement for X, by providing a set of rendering primitives. Yet at the same time they repeated mistake after mistake from the core protocol. E.g. the flexibility in visuals that mattered when we did have monochrome, 8-bit palettes, 15-bit direct color, 16-bit direct color and 24-bit truecolor graphics output in the same computer lab no longer matters when you can assume that every server can provide RGB24 and RGBA32 visuals, not least because XRender demands this so if a server wants to support XRender, it must support RGB24 and RGBA32 whether or not that's a natural fit for the backend or not.
Yet it still makes you iterate through a list of every weird format known to man (and some that feel like they must be alien) even when you want to look up one of the 5 standard formats Xrender dictates that every server must support. Xrender could have just made the relevant request return 5 ints.
It's not hard to deal with the current solution, but it's pointless and it makes the server unnecessarily complicated to still support all of those extra visuals that almost nobody will be using, and nobody needs to use.
If that was all, it wouldn't be so bad, but this is typical for XRender, and this is why X became unmanageable: They both left the core protocol intact, but each extension they added was just as bloated as the core was.
Nothing would stop you from fixing this by bumping a version number and start deprecating requests and introducing replacements. But that only works if you can get buy-in into changes that actually simplifies things, and the XRender extension is a good indication that this was the real problem for X: You'd get buy-in for changes, but changes that only ever added complexity.
This was particularly idiotic because Xorg came to pretty much control this space: Almost everyone used the same X server and almost everyone used the same Xlib. They could have bumped the protocol version and started deprecating old functionality whenever they wanted while optionally papering it over in the client lib to give people time to update their clients.
So Wayland became a way of escaping that and starting over. And it could have been great if they weren't so afraid of repeating the same complexity mistakes that they repeated the same complexity mistake by proxy by forcing even basic functionality into extensions where there was no ability to reign it in. The Wayland design reliance on extensions made an explosion in complexity virtually guaranteed.
I wish they'd have forked Xorg instead, and had the guts to gut it and clean it up: Bump the major version to 12. Set out an aggressive deprecation schedule and ensure a sufficient set of apps would keep working with various calls and visuals yanked out. Optionally add a shim to xlib/xcb to temporarily handle some of the deprecated functionality client side (e.g. most old rendering calls and bitmap font handling could easily be transitioned this way). Then you'd have a base to iterate from where you could iterate step by step from a working starting point. Then maybe we'd all be on something new and working instead of having this ongoing schism that won't be resolved anytime soon.
They could not drop core functionality from X11; somewhere, there is a client that expects it and dropping it would break it.
That's exactly the reason why everything is an extension is Wayland: so the client is forced to enumerate, what features are available and adjust its behavior when something is not. It is exactly this, that allows Wayland to drop features, once they became obsolete. It is the lesson from not being able to drop core X11 primitives.
> They could not drop core functionality from X11; somewhere, there is a client that expects it and dropping it would break it.
Of course they can. Dropping it from new versions won't wipe old servers off the planet, and as we can see from the existence of Wayland, the OSS world is very much prepared ditch far more backwards compatibility than just breaking an occasional obsolete client.
If anything, it's a far easier transition because shimming some Xlib calls is far easier than migrating applications to a whole different display model.
> That's exactly the reason why everything is an extension is Wayland: so the client is forced to enumerate, what features are available and adjust its behavior when something is not. It is exactly this, that allows Wayland to drop features, once they became obsolete. It is the lesson from not being able to drop core X11 primitives.
That doesn't work that way once something becomes reasonably ubiquitous. Experience from X is that people will expect a given extension to be there (heck, most of my own X software will categorically not work on an X server without XRender, so if that extension is ever dropped from X, my software will stop working and need to be updated - that's a tradeoff I'm perfectly fine with), not have older alternatives that make sense, and obviously not be able to predict future alternatives that do not yet exist.
In other words: You'll still need to either support those APIs, or deprecate them and update the clients. Doesn't matter if they're part of the core or extensions.
I'm not convinced the Wayland approach is actually better. It "feels" to have a lot more latency on my (admittedly somewhat old) laptop, which is somewhat disappointing since "better performance" was supposed to be one of the reasons for Wayland in the first place.
"Render as quickly as possible (even if imperfect)" is also a viable strategy. Some people seem to really hate it, but I've never even noticed it, much less been bothered by it. I certainly prefer the reduced latency. I'm probably not that special. It very much seems like a trade-off thing, rather than "this is the one true correct way"-thing.
Of course, it would be better if Xorg would support both, but that also applies to Wayland.
One of the unfortunate things about Wayland is every compositor will have its own quality of implementation affecting things like latency.
With XOrg, especially in the pre-compositing days, you could choose whatever WM you want and it wouldn't have any impact on the rendering performance of X clients. Once the Composite extension was added and everyone started running composited X desktops, that started to change, and the increased latency already started appearing - in an arguably worse architecture than Wayland because there were often three processes involved with lots of IPC/context switches per draw: X-Client->X-Server->X-Compositor->X-Server->CRTC. At least in Wayland it's more like Wayland-Client->Wayland-Compositor->CRTC.
If you're unhappy with the rendering latency of your Wayland sessions, it may be worth trying alternative compositors... they likely vary significantly. The Valve/Steam folks have made a minimal one specifically optimized for games/low-latency [0]. I doubt the SteamDeck would be seeing as much success as it is if Wayland were so problematic in this department.
If most WMs are slower out of the box then Wayland is de-facto slower. "But actually, Wayland is a protocol, and you can use this specialized WM optimized for speed" doesn't change much about that.
I don't use a compositing WM. I would have to check how the performance compares to a compositing WM.
It's just one more thing that's worse-out-of-the-box with Wayland that I need to find a solution for, while at the same time solving exactly zero issues for me.
> Is this something every Linux desktop application will need to do?
The idea is that GTK+ and Qt can (and do) add support for Wayland and it's trivial for applications to support Wayland, often without even recompiling.
Yes, Wayland is a display protocol that applications need to speak in order to display on a Wayland server.
Applications built for X can still run on Wayland via Xwayland. But Xwayland is a bodge to allow legacy applications to continue running, an interim solution while toolkits, libraries, and applications are converted to use Wayland directly. To paraphrase the hit song:
Once we have enough Wayland software
At our call, hackers, at our call,
We'll throw out those dirty X code paths,
Ever more, hackers, ever more.
Lots of games won't ever be converted to Wayland (maybe some unofficially by replacing libraries with updated ones that still work with the game), we'll need some nested X server like xwayland in rootful mode once wayland compositors remove their xwm.
Reached? Win32 has been the most stable userspace ABI for Linux for more than a decade (or even 2?). Wine is a really old project and Win32 API / ABI has always been stable. The implementation of the API / ABI was very patchy earlier but the functions that defines the ABI has always been there, their signature and calling conventions are stable.
tl:dr an app connects to the Wayland compositor (like an X server) and sends it draw commands using the Wayland protocol. The compositor accepts these connections on a Unix socket, /run/user/1000/wayland-0 by default
The protocol is defined in the libwayland library. Most apps don't use libwayland directly, but their widget toolkit like GTK or Qt does it for them.
at the risk of appearing pedantic: whereas a large chunk of X11 is dedicated to draw commands (circle here, line here, pixel here): wayland doesn't have any
X was designed to be used over a network, where sending buffers would have been very slow. Sending primitive draw commands, on the other hand, was much faster.
I have been using Firefox on Wayland for years now, and for the most part it works, well, perfectly well. It's very nice on computers with mixed DPI displays, I've had no issues with any of that. (I have run into a couple situations where dragging tabs has crashed, but it's too occasional to care. I just session restore'd and went back to work. Features like Picture-in-Picture work great and I even have a special setup for Picture-in-Picture mode so it will stick across workspaces in Sway.)
I imagine there's a lot of concerns that have to be carefully considered, as it is a very non-trivial change. Like, does WebGL work? Video acceleration? Will there be a performance regression for anything? How about accessibility, do screen readers still work as intended? (They should since for now that's all out-of-band, but you never know.) Does it have trouble with any specific vendor of GPU?
An interesting consequence of Wayland's design is that a lot of the information conveyed about X windows, like ICCCM properties, are basically non-existent in the Wayland world. This means that for a tiling window manager like SwayWM, it's actually a lot harder for say, pop-up windows to not accidentally get treated like other tiled windows. So if you use e.g. Dolphin file browser, the copy dialogs will try to "tile" since there's no way for Sway to know they're supposed to be popups. This was not an issue for i3wm. This is both fixable and possible to workaround, and in the grand scheme of things not my biggest priority (I'm much more concerned about issues like stability) but I think that issues like these are of prime concern for Wayland adoption.
> I have run into a couple situations where dragging tabs has crashed, but it's too occasional to care.
Am I the only one to have the expectation that software I use should never crash?
My chair holds me up every day. My fridge keeps my food cold every day. My windows keep out the rain every day. My washing machine washes my clothes every time. Why should my firefox get a pass to sometimes randomly crash and that be okay?
I have two broken chairs. I had to replace a fan motor in a fridge once. I had a window that actually did start leaking. I have never had my washing machine break down, but I have had a dryer break down.
All of those things break. Congratulations if you've managed to experience life without that.
Anyway, comparing software to chairs is unlikely to yield any useful wisdom IMO, so I'm not actually going to attempt to make an argument based on that. I know that any non-trivial piece of software will have millions of potential codepaths, and Firefox likely has a number of potential total codepaths so large that we could not ever hope to calculate it through the entirety of humanity's existence, so I think it's just only reasonable to expect that some of those codepaths may crash.
For safety-critical applications where you can't afford to have a software bug kill a bunch of people, there's only one realistic option: you can't rely on never having a software bug. You instead must do your best to ensure that as many classes of software bug as possible can't, on their own, cause damage. Ideally you would combine safeguards at every possible level: of course try to eliminate bugs, but also add hardware protections, redundancy, and realistically any kind of mitigation you can.
I do not know how much better software engineering could be with more discipline, but I do know that simply asking humans to not make mistakes when writing millions of lines of code isn't reasonable, and the stakes are not always high enough to warrant writing everything in Ada.
Anyway, if my fridge fails, I have to order some replacement parts or worse, maybe a new fridge. If Firefox crashes, I am annoyed for like 30 seconds until I hit "Restore Session" and it happens infrequently enough that I'm not even sure when the last time was.
(P.S.: It's also worth noting that despite regulation and despite the rigor of traditional engineering, gas-lifted chairs occasionally explode and kill the people sitting on them. I don't think I've ever heard of a Firefox crash directly killing someone, so there's at least that.)
Update: In middle of trying to post this, HN stopped processing requests for maybe 15 minutes. Almost poetic.
> All of those things break. Congratulations if you've managed to experience life without that.
Physical things wear out. That's an entirely different situation from a product that breaks because it was faulty when sold.
It's true that expecting perfection from any complex system is unrealistic, but good software should at least be lacking in crashing bugs that happen with common operations (such as dragging a tab).
Just to clarify, I'm not saying that FF (or Wayland) isn't good software. I'm just saying that nobody should just shrug their shoulders and say "that's life" when common operations cause a crash.
Yeah, exactly, and that's kind of my point; there's not really much wisdom through that comparison in my opinion. I guess I am just saying that I don't agree with the sentiment behind "software I use should never crash" or the reasoning that chairs don't "crash" or something like that.
The trouble is that there's really no 'reasonable' amount of instability. The amount of instability we tolerate is essentially arbitrary. Desktop computers can have uptimes of several months to potentially years, which when I was younger (not that long ago, but long enough) would've been completely unheard of (And yeah, I'm sure microcomputers with vastly simpler software/hardware could run for a lot longer, but I think it's fair to say that's not a very fair comparison). For me Windows XP hardly lasted longer than a few days before things started to get kind of weird, and I consider Windows XP to have been amazingly stable for its time.
I think the state that we're at now is actually a result of software engineering and computers getting better. The software has gotten immeasurably more complex than say, the Windows 9x days, and yet stability has improved in many dimensions. If we were still making software with the same complexity and cardinality I can only imagine it would be significantly more stable, but it's always hard for the theoretical part of something to keep up with the practical part.
Manufacturing defects and design issues also exist in physical products, so I'm not sure that this is a relevant point.
> I'm just saying that nobody should just shrug their shoulders and say "that's life" when common operations cause a crash.
Honestly, I find it a miracle that complex software like web browsers and operating systems are able to work at all. Yes, crashes are frustrating, and constant crashes are unacceptable, but you just cannot expect such complex software to work perfectly all the time.
Case in point: Just the other day, a macOS upgrade went wrong and had to be interrupted, and now I don't have an admin user on my MacBook.
Am I the only one to have the expectation that software I use should never crash?
Firefox has 20+ million lines of code. Honestly, I can't tell: Are you trolling? A modern web browser is some of the most complex software ever written.
> A modern web browser is some of the most complex software ever written.
Case in point - I had to run some x86 Docker containers on an M1 Mac recently - PHP and nodejs ran without issue using Docker's under-the-hood emulator but Chrome continually crashed during emulation.
My expectation is that if any software comes across an unexpected situation, the software should crash rather than try and bluff its way through something it's not designed to handle -- risking data corruption or data loss which is worse than simply crashing and retaining your last known good 'save' point. This is where it's nice to have software that runs e.g. tabs in different processes, so you don't experience an overall crash but just a crash isolated to a tab running e.g. a nefarious JS application.
Your appliances are UL listed and interact with an electrical grid that is heavily regulated. Other than their extremely simple interface with that system (and your plumbing in the case of the washing machine) they entirely self contained.
If your windows do keep out the rain, they do so because they were installed properly within a much larger system of overlapping parts. Even on new construction subject to inspection, failures in this system commonly evade detection until after they have done years of damage.
Consider the impact of those things failing. Your chair breaking might injure you in a way that takes months or years to heal. The fridge failing might spoil an entire batch of food. A window failing at the wrong time could cause massive damage to the interior of the house.
Meanwhile, the browser crashing rarely makes you lose what, 15 seconds of time to start it back up and continue? It's annoying, but it's also not really... a big deal?
Your chair and your fridge, like a piece of software, can be repaired or fixed. They get worn down, especially if they're repaired many times over. Crashing, in the context of a chair or fridge, or in software, is generally not seen as a catastrophic failure which fundamentally makes the chances for repair or fixing impossible.
One would hope your chair or fridge never "crash", like one hopes a piece of software never does, but they come in all levels of quality and face all kinds of edge-cases. One day, for instance, maybe a 3 tonne man sits on your chair, which has held you up just fine every day, and the chair fails to hold him up, crashing him to the ground. You wouldn't turn around and reasonably say your chair is now a failure, really.
Can confirm video acceleration works fine on Wayland. For some years you had to turn on some knobs in Firefox but I believe recent versions simply turn it on by default as long as you have a supported GPU. I have a fairly common Intel GPU and it all just works using Firefox LTS on Debian.
Firefox Wayland is still kind of iffy when I have the Nvidia driver enabled on either of my AMD CPU/Nvidia GPU machines. Sometimes it doesn't launch, among other unreproducable things.
Of course it works perfectly if I disable the Nvidia driver. It also works fine in XWayland, but then rendering (to my eyes) looks choppier.
Firefox is one of the few apps that works flawlessly for me in Wayland (w/o xwayland).
Slack is almost there, but not perfect. My cursor becomes like 1/10th the size in Slack .. but the crisp rendering is worth it. Dragging a PNG file into it never works though, so I always need to upload via the little + button.
Spotify is 100% flawless, to my surprise. Even works flawlessly with the whole device handoff thing between iPhone, my Macbook, etc.
vscode renders much better with wayland, like the latency difference is pretty significant. but... I use Toshy to get macos keybindings on Linux and those fail to work when vscode is booted in wayland mode ... so I am still suffering with xwayland. If I do not think about it, I don't mind lol. If I go back to native and see how much better rendering is, I feel sad.
Chromium and Electron are the big kickers for me. All GPU acceleration is (silently) broken in true native Wayland when Nvidia is active.
It mostly looks fine until I stress the UI, and I can see significantly more CPU being used. In fact, I only really know its busted in VSCode because it spits out the same errors in the console as Chromium (where I can check about:gpu and see that everything is off).
Same here, but for me using launch options to force chromium apps to use wayland with ozone has fixed most of the issues. Pretty convinced its the combination of NVIDIA/XWayland/Electron that is particularly cursed.
I need wayland for correct 200% scaling on one screen. Firefox seems to work without issues. VSCode worked for some time until some update. I have no idea what changed :(.
Also its so weird that i have to launch it with some flags but they also show as errors...
How to enable VSCode wayland is mystery to me.
I’d be interested in switching to wayland but I have good knowledge of x11 cli tools - xrandr, xdotool, xwininfo, etc. is there an easy way to migrate this knowledge and accompanying scripts?
If you are scripting-heavy user, I recommend trying out one of WMs based on wlroots (or implementing its custom protocols). Core Wayland protocols are designed with security in mind, which doesn't necessarily let you have all the automation fun. wlroots protocols bring back most of X11 capabilities at the cost of having similar security model.
https://github.com/solarkraft/awesome-wlroots is a pretty nice list of various CLI utils you can use. Sadly I don't think anyone aimed to 1:1 replicate APIs of xdotool etc, so you will need to change the syntax in your scripts a bit.
Same as for Debian in my observation. Firefox uses Wayland by default out of the box for clean installs. But there may be still be legacy Debian installations which have carried over the use of X11 through upgrades etc.
I'm just a regular user who hardly ever touches a terminal window. I have a 10+ year old laptop and am running Ubuntu 20.04 LTS and am running X11. How will this affect me?
I'm on an old GTX 1060 I got off eBay years ago. I've only tried Swaywm, as I'm on i3wm right now.
Sway starts, but crashes within seconds. Longest I've got it to run was half an hour before everything froze.
Do any other WM's/DE's work better for old Nvidia cards? I don't particularly want to start installing all the Wayland things out there until one works hah.
I'm a sway user using a Maxwell Nvidia in an optimus config with an intel skylake (around your vintage, technically a generation older, we're both supported by current drivers). There's a single line patch needed for using nvidia with wlroots that upstream does not want to merge, if you don't have it screens will flicker: https://aur.archlinux.org/cgit/aur.git/tree/nvidia.patch?h=w...
Other than that for the first time in like a decade of dealing with Optimus bullshit laptops off and on everything finally works plug and play, even running different refresh rate screens at the same time. Nvidia finally shipped support for controlling gamma in wayland on Halloween so I can use gammastep to shift my screens red at night.
In short: Have that patch for wlroots (which sway uses), use newest proprietary driver, block/uninstall nouveau, and make sure the system isn't loading CPU rendering due to a misconfiguration (firefox you can check about:support, chromium/electron-based shit check chrome://gpu)
EDIT: oh and since chromium/electron will inevitably temporarily break graphics at some point due to an update... --disable-gpu is your friend to get those apps working (with CPU rendering). Obviously drop it out once those problems subside, it's happened maybe twice to me in the past few months running Gentoo unstable. Firefox seems more resilient and will find a way to run in less ideal circumstances on wayland.
If you're on arch you can use sway-nvidia from AUR. I've been using that on my desktop without significant issues. The only one are some graphic glitches on the steam interface (but not in games). I'm on a 3070ti though.
I think it's mainly just environment variables, so if you're on another distro you can have a look at the the GitHub repo and implement it yourself.
The biggest nvidia issue I encountered are problems with display managers, GDM would sometimes not start wayland compositors or not start x11 WMs. I tried several others as well and always had issues (never had issues on my previous AMD or Intel machines). I ended up just autostarting a locked sway desktop and everything just works.
slightly off topic, but does anyone have a solution for app windows not remembering position on wayland? for example on x i have firefox open in one place, sublime text in another.. but on wayland they always open in the same spot, and i have to move them. it seems such a basic thing to not work.. does every wayland user run a tiling window manager??
As I understand it, this is a current limitation of Wayland. For KDE, which is what I use, they'll be writing something too handle this since it's not possible natively.
It is possible natively. The logic, however, needs to be implemented in the compositor not the applications, because it's the compositor that keeps track of the positions of the windows.
I have been using Firefox on Wayland for a long time now. It's even nicer than with X, since pinch-to-zoom on touchscreens and touchpads is fantastic, but a Wayland-only feature.
I didn't know what Wayland is, but was curious what this article is about. I read the article, and it doesn't explain what Wayland is. So I googled Wayland and read the start of the Wikipedia page. Ok, so Wayland "is a communication protocol that specifies the communication between a display server and its clients, as well as a C library implementation of that protocol." and so on. Huh. I now know have a very, very vague idea what Wayland is. What does that have to do with a browser? How can Firefox "ship with Wayland"? I think I have learned nothing. I feel stupid. Tech news is weird sometimes.
Edit: Thanks for all the responses. But I'm still not understanding what all this has to do with Firefox. I boot up my linux machine that runs KDE, I launch Firefox and then what? Does this help with something on my local machine? Or does Firefox now provide a UI for remote systems that I SSH into? Whatever Firefox can do now, why should this be a feature of a browser?
Edit 2: Ah, I get it now, Firefox simply renders itself using the Wayland protocol, correct?
Essentially, in an operating system you need a way to "draw" things on the screen. And a way to properly "move" the boxes "draw".
Previously, the usual* way to do that was using XServer (XOrg). Now you would imagine that the server would take commands from applications, and would draw them. But it was the inverse (for various historical reasons)! However, the most egregious thing was that it ALWAYS ran as root. And while tries had been made to reduce the attack surface, it had to fundamentally change (I am skipping over other parts related to performance, scalability, or future proofing).
And that's where Wayland comes in, and literally flips the whole thing on its head. Now the issue is XOrg has been around for maybe 40 years or more ! And that was not going to change easily. Distros did their absolute best to allow double use, but adoption grew very slowly. Eventually, supporting and testing for two envs will grow complicated.
Anyway long story short, almost everything about Wayland is better IMO, actively supported and is the future. But migrating to it has been complicated because they were undoing 40 years of habits, hardcoded bugs that grew into features, and had to come up with new testing.
This is something I typed up rather quickly so please take a peek at the Wiki page for Wayland you will find a much more complete history
> However, the most egregious thing was that it ALWAYS ran as root.
That hasn't really been a thing for over a decade now. As a decent metric, https://wiki.ubuntu.com/X/Rootless says Ubuntu switched to rootless by default for most drivers in Lucid==10.04
This is about how Firefox, KDE, any app you run draws to the screen.
In the old world, they talked to an X server that implemented the X protocol. It's not KDE drawing stuff to your screen, it's X, but KDE is a little special in that it can move windows around and draw title bars and borders. This is called a window manager.
Two big issues with X, this was defined in the early 90s by a consortium of Unix vendors and is somewhat of an overly complicated nightmare.
It's also a security nightmare, any app can snoop on any other app.
Wayland is an attempt to simplify things. The server, called a compositor, is much simpler and is implemented as a library, usually by former window managers that now actually handle drawing stuff to the screen. Applications can no longer snoop, they must ask permission.
If you run an older app designed for X, it uses an almost invisible compatibility shim called XWayland, basically a tiny X server that takes in X draw commands and converts them to Wayland ones. Firefox enabling Wayland support means that on most modern systems, it no longer has to use this shim.
Wayland is a step forward for desktop Linux, but like any big change there are some annoyances. The asking for permission model means things like screensharing tools or apps that do weird shit like macros or capturing keystrokes need to be updated to ask permission. Nvidia didn't really support Wayland well until very recently because they got into some weird argument about driver APIs that took years to resolve.
Wayland is a piece of the linux desktop software stack. If you're on a Mac or Windows, it won't mean anything to you. Linux historically has used X11 for drawing the desktop. Wayland is a replacement for X11. It's big news because it's been a long time coming, and fixes a lot of longstanding issues. Unfortunately it also creates some new issues (screen sharing, hot key apps, etc), but they're being actively worked on and are very close to being completely solved.
> it also creates some new issues (screen sharing, hot key apps, etc), but they're being actively worked on and are very close to being completely solved.
To offer the opposite viewpoint, I swear I've been reading for decades that X11 would fix old issues. My last experience of X11 (less than a decade ago) had me using vi to edit a configuration file to add a line of text to enable some sort of magical feature to stop screen tearing. I've been using BSD/Linux since the late '90's and this issue has persisted for over 25 years.
Wayland meanwhile actually has 99.9% of what you need working today not 25 years from now. There's some bits and pieces already progressing well and likely to be fixed in the next few weeks/months/years and not 25 years in the future. Very different situation to X11, IMHO.
At least screen sharing has been solved. We are mainly waiting for apps that use sharing to implement the Wayland compatible to get access to screen recording.
I only know it as the thing that broke all my screen capture tools because none of them had implemented the necessary changes the last time I tried, admittedly small N years ago.
Yeah while Wayland still has some warts it seems like people say "I don't have proper color management on Wayland" with the same enthusiasm "This GNOME Wayland session crashes on boot" from a nearly a decade ago.
This Plasma Wayland session crashes (in my GPU driver):
- 3 years ago
- 1 year ago
- 6 months ago
The biggest issue I have with Wayland is that it requires a lot more out of a GPU than a framebuffer, and my experience with video drivers on Linux is that they are very buggy and not maintained for very long.
I have an older computer that I can run Xorg with compositing disabled and firefox with GPU rendering disabled. As far as I can tell I will never be able to run Wayland on it without changing the GPU.
Similar issues with some ARM based SBCs; they have varying levels of stability in their graphics acceleration capabilities, and often only on a very old kernel, but I can get a reliable framebuffer on mainline.
Wayland in itself has no special requirements on the GPU; it needs standard kernel support (KMS, dmabuf). EGL is optional, for both compositors and apps. Mutter and Sway can both happily run in QEMU framebuffer.
I think this is a problem with any highly specialized or technical topic. I vaguely recollected what wayland was, but I didn't know why I would care about it and ended up doing similar googling before realizing this news will not matter to me outside of a general technical curiosity.
I encounter the same thing when dealing with code reviews as well - people love to document the WHAT or HOW of things, but rarely if ever consider talking about WHY it matters, or WHO it matters too.
To borrow from a favourite corpo speak: answer the "so what" for the reader to make something actually useful to more people.
Wayland is a replacement for X11 which is now ten or more years old and still not feature complete. It will be the future of all graphical interfaces, or maybe we will still be running X11 with extensions in 2050.
I remember when GGI[1] was the future of all graphical interfaces. Remember GGI? 1994-2007 RIP.
Wayland looks a bit more likely to achieve its goal, but we'll see. For my part, it'll take a long time yet before it's worth the hassle to consider switching.
On a modern computer, programs that wish to draw on the screen do not interface with the hardware directly (aside from games). Instead, they communicate with another program that does the drawing on their behalf. This other program is called a "display server", a GUI program such as Firefox is a "client", and the details of the mechanism by which they communicate is called a "protocol".
Until recently, "Xorg" was the main centralized implementation of a display server on unix-likes, and any program wishing to display graphics had to speak its native protocol, "X11". Now many systems run display servers which speak a new protocol, "Wayland"[note]. While a compatibility shim does exist (XWayland), ideally a program wishing to display graphics on such a system should do so using the new protocol directly, for better performance and features.
Porting an application to a new graphics backend obviously requires some effort and testing. Until now, out of an abundance of caution, Firefox simply spoke the old X11 protocol by default, even when running on a new Wayland system, relying on the XWayland compatibility shim. Now Firefox is essentially announcing that they believe their Wayland backend is robust and complete enough to enable by default.
I hope this helps!
[note] the nature of Wayland is such that there are many implementations of such servers, not just one main one like with Xorg. This is because the semantics of the Wayland protocol have taken over some of the functions previously handled (on X11) by a separate piece of software, called a "window manager", which contributed heavily to the look, feel, and behavior of a particular desktop GUI. Thus, while Xorg was agnostic and could be shared by different GUIs, with Wayland each GUI system must implement its own display server.
>This is because the semantics of the Wayland protocol have taken over some of the functions previously handled (on X11) by a separate piece of software, called a "window manager", which contributed heavily to the look, feel, and behavior of a particular desktop GUI.
Window managers can be separate with Wayland too. It just seems like the Wayland people don't want to unify under one implementation and have separate window managers.
This is because unifying the display manager, compositor, and window manager allows for each implementation to be far more integrated. For example, this opens up the door to virtual-reality or mixed-reality Wayland display managers, that can run desktop apps without the usual overhead of screen capture. Xorg can't do that. Trying to make Xorg do that will only end in misery.
Being much more integrated isn't actually that valuable. VR compositors already render a full screen frame that goes straight to the display. The window manager for VR is typically in a separate process from the compositor.
You could add Wayland support to an existing VR compositor, but that wouldn't force you to combine the window manager into the same process.
Excuse me, but try to actually use any VR window manager, today, on an OS like Windows. It will bog down and eventually crash your GPU when you open too many windows, because it has to capture those windows from the regular desktop. A Wayland display manager on Linux would not have this issue, because it would already be the window server, so it wouldn't have to perform any extra captures. I only know about this because I have experience trying to do this exact thing.
Wayland would have the same exact problem as you described if it was implemented by copying a window's surface to the surface you are submitting to the compositor.
The solution in both cases is to just submit the original surface to the compositor.
>I only know about this because I have experience trying to do this exact thing.
Did you use Windows Mixed Reality? If you want deep integration with the operating system, you should use the implementation that is part of the operating system.
> Wayland would have the same exact problem as you described if it was implemented by copying a window's surface to the surface you are submitting to the compositor.
Sure, but as far as I can tell, Wayland seems to be the only architecture that would allow you to not do this. Windows does not hand you the original surface. Xorg does not hand you the original surface. But if you are the Wayland display server, you have the original surface because you're the one who created it. So if you start drawing to an HMD, you can place existing windows on it with no extra overhead.
> Did you use Windows Mixed Reality? If you want deep integration with the operating system, you should use the implementation that is part of the operating system.
Yes. I do use Windows Mixed Reality. Which does not support opening desktop windows into the virtual space; it only supports mirroring an entire display onto a surface, and not even capturing individual windows. For that purpose I tried XSOverlay and OVR Toolkit running on SteamVR, which have that capturing issue.
>Wayland seems to be the only architecture that would allow you to not do this
All modern operating systems use this same architecture where apps render into a texture which the compositor can use. Wayland is not unique in having applications just render to a surface which the compositor composites into the final ouput for the display. We have been doing things this way for decades. Saying that xorg cannot do it doesn't mean much because xorgs design is bad and decades behind. This ability has nothing to do with why wayland compoaitors have a wm built in instead being able to easily interface many different ones.
>Which does not support opening desktop windows into the virtual space
Look at this video. He has blender open without mirroring a display.
> All modern operating systems use this same architecture where apps render into a texture which the compositor can use.
I know, but Windows does not allow anyone to just have that texture, AFAIK.
> All modern operating systems use this same architecture where apps render into a texture which the compositor can use.
...I'm going to have to try that. You can even use your mouse with the HMD? I didn't expect that.
Edit: Okay, I've tried it.
- You can open some small portion of your desktop apps in WMR, but nine times out of ten they are just going to ignore WMR, and open on the actual desktop instead, giving you no feedback whatsoever.
- The apps that you can load often don't work properly, for example the File Explorer is a completely different version that doesn't allow you to actually view decently sized thumbnails of anything, nor open them in any sort of photo viewer.
- Once something is on the desktop, it's impossible to get it into WMR. You can only use it through the desktop view. So, apps that can't open into the WMR environment (i.e. Discord) will be impossible to view or interact with from WMR.
- WMR has this delusion that all windows have to be perfectly vertical, so it's impossible to use the headset while laying down, because a mouse cursor doesn't have enough degrees of freedom to communicate that a window should be tilted. (But even using the controllers has this issue.)
But hey, at least it seems not to have that window capturing problem. If you can bear the fact that nothing actually opens, and nothing that does open even works.
It's a very long story, but yeah, its about how the applications on your desktop can draw content inside their borders, and how those applications interact with things like keyboard/mouse/other applications drawn on the screen. One of the big things is that X11 was written for a time where everything was open with no access control. Any application can view any other application, or capture any keystroke. Wayland introduces a form for permissions control, which has been a huge ordeal to both pave the path for and to design and figure out how on earth that should work. It's great though that you can have some actual control on who can listen to keystrokes and not.
The code looks like they're just checking for the presence of GTK 3.24.30 to make that determination, that's why I was asking.
But perhaps that version of the GTK doesn't support X itself, so that's an acceptable proxy? Or perhaps that's not the real check, and it exists elsewhere?
Very glad to hear that. I am guessing in December screen sharing on secondary, non-popular DEs and distributions will break again or alternatively will finally work properly?
X is the tech we have used since the dawn of time. It was released in 1984 and so the architecture is not suited for the way modern desktops operate.
Wayland is a modern replacement, but it is not a drop-in. That is because it has a completely different architecture and approach.
I cannot ELI5 the differences between the two, because they are somewhat vast.
If you are on a platform that supports Wayland, it is undoubtedly a smoother, prettier and overall better experience. This falls apart due to the lack of direct support from certain apps, desktop environments, etc. The migration has taken some time - but alas this is an open source effort in a massive/fragmented environment so it is obviously a very hard challenge. Like herding 100,000 cats.
Unfortunately not everything will just work. A stopgap is something called xwayland which allows x apps to communicate with wayland - although it is not perfect.
Firefox will work with Wayland. It will work with X. It will work with XWayland. The default though is X or XWayland. You normally need to explicitly tell Firefox to boot up using Wayland. Firefox is now considering making it enabled by default, which would be great for those of us who run on Wayland all the time. It would of course still work on X.
>> X is the tech we have used since the dawn of time. It was released in 1984 and so the architecture is not suited for the way modern desktops operate.
X is a mature architecture which Just Works Fine. I don't know why it's considered "not suited for the way modern desktops operate", because as an X(org) user, all my desktops operate Just Fine whereas whenever I try Wayland my desktops do not operate Just Fine.
>> Wayland is a modern replacement, but it is not a drop-in. That is because it has a completely different architecture and approach.
Wayland is a newcomer and alternative to X(org) - the authors of Wayland want it to take over from X(org) and for X(org) to die off. I hope that X(org) stays.
I still don't understand the hate for X/Xorg [0]. It must be a generational thing. Maybe I'm just being a grumpy greybeard? Who knows. But I do know that whenever I try, say, KDE Plasma (Wayland) I get problems, for example, playing games with WINE, and other annoying glitches and hitches which I don't get using MATE/Xorg.
And no, I don't care if Gnome works great with Wayland - I have a visceral contempt for the modern iteration of the Gnome desktop (and had nasty experiences with the Gtk toolkit way back when which put me off developing with it forever.)
The converse is that many people including me have experienced issues with X11. I've been using X11 on BSD/Linux for 25 years and it's been a poor experience involving researching how to get a specific GPU to work correctly every time I installed BSD/Linux. This was especially frustrating when Windows/MacOS always just worked fine out of the box on the same hardware. When Debian switched to Wayland a few years back it was literally the first time in over 20 years that I had a working Linux desktop out of the box that didn't have basic issues like screen tearing. I appreciate the legacy X11 has left us but Wayland literally just works with no trouble across several machines I own.
The team behind Wayland (freedesktop.org) are also the developers for xorg, nobody wants to work on xorg anymore due to architectural and codebase issues. Most of the commits to Xorg recently have been for XWayland, not Xorg. Xorg is essentially in maintaince mode.
Whilst most of the newer things implemented Wayland could theoretically be implemented within the X architecture nobody wants to do it both due to the architecture of X and the age of the Xorg codebase.
X will presumably be around for another 50 years but it will not receive the development needed for modern tech.
Nearly all of the hate I hear for X/Xorg is from Xorg developers (modulo people complaining about video tearing). As far as I can tell they will not be contributing to Xorg anymore, so it's going to gradually fade away.
X doesn't work as well as it used to. Before all the eyecandy became routine it was normal to use it remotely over a LAN. It performed well at that job in the era of OpenLook and Motif over 10Mbit Ethernet. Nowadays X is sluggish over an SSH tunnel to a local client server, even with classic Athena apps. Something has gone astray with xorg and it's giving X in general a bad rap.
There's 2 ways to get a window to show up on a Linux desktop, the old way is called X11 and the new way called Wayland. These protocols handle putting stuff on the screen as well as input from your mouse and keyboard (and touch screen if you're one of the 2 people that have one).
Mozilla has been working toward making Firefox work with wayland for a while, seems they've finally gotten in to a shipable state.
To be fair it's probably been fine for years -- what they've proposed is how it's been done in many distros already. They're more or less upstreaming the changes many distros have already done when they switched to Wayland by default over the last couple of years.
