I'm running Sway WM right now, a Wayland compositor that implements an i3-compatible window manager, and in fact working on the code (hopefully merging my first contribution soon.)
I'd say the biggest issue is really maturity. I actually find Wayland to be a surprisingly nice piece of software engineering. I don't know if I like the architecture really, but it comes together fairly nicely in the end.
For example, there's unanswered security questions. It would be good if applications couldn't just go and manipulate and spy on other apps like they can with X11. Wayland indeed solves this issue, but it leaves other problems. How do I capture the desktop?
wl_roots offers some extensions that help alleviate the problem, but they don't solve the full problem; for example, you can capture the screen, for which programs and an OBS plugin exists, but there's no upstream Wayland extension that can make WebRTC desktop capture work. I think what we really need is the ability to integrate policy and consent requests, but I'm not sure whether there's progress on that front, or how long it will take. Once the problem is solved, upstreamed to WebRTC, and that upstream version trickles down to Electron apps, Firefox and Chrome stable versions... well, things will be in a better place.
Speaking of web browsers, today Firefox still has some issues to go before it is fully working in Wayland natively. You can do it today, but it is not perfect; there are sometimes places in the code where it assumes it is running on X11, and things simply break. The screenshot tool is just flat out not present when running under Wayland due to the above issue.
Applications are slow on the uptake too. XWayland covers most of them, but it is not perfect. Like anything that captures the screen, of course, is not going to work under XWayland, but also, XWayland apps may behave a little off. In Sway WM, one bug is that when the mouse travels from an X window to a Wayland window, sometimes it behaves as though the mouse is still hovering over the X window at the last position it touched, which leads to tooltips showing up where they shouldn't. There's still a decent amount of GTK2 apps, and even Qt apps aren't all Wayland yet; Krita plans to start working on support I believe next year.
In my case, here's the itch I'm currently scratching: Sway WM also does not have support for drawing tablets. I found this out, by, well, loading up a drawing program and noticing the lack of pressure sensitivity. So, that's what I'm currently working on. Needless to say, this is a non-starter for anyone that relies on a graphics tablet, although if you are just using GNOME 3 it is unlikely to be an issue since I'm sure GNOME 3 supports graphics tablets just fine.
NVIDIA drivers are still a pain in the neck. I gave up and bought an AMD graphics card, and frankly I can't recommend it enough. Basically everything works better on Linux, but certainly Wayland works better. It's worth giving up some raw power. Still, for many people the proprietary NVIDIA drivers are going to need to work, and today support varies from lackluster to poor depending on what compositor you use.
So Firefox supports screenshots when running on the Gnome compositor, but not running on sway? Looks like we're heading into interesting times where applications are getting tied to certain DEs with little to no cross-compatibility.
IDK. Sway is my daily driver. I just checked Firefox, and the screenshot tool works as expected (including clipboard). So unless GP is talking about capturing non-Firefox windows with that tool, I do not have that issue.
This Firefox instance is running on native Wayland. The only issue I have with it is sometimes the coordinates for the context menu are wrong.
But yeah, there might be compat issues, if some protocols are required for stuff. But Wayland itself is the baseline: you'll always be able to draw windows and interact with them.
What's left to extra protocols isn't guaranteed to work: control of the compositor with a client, for instance (color correction, virtual keyboard, screenshots, window placement, screen geometry, window decorations, etc.) is completely up to the compositor (and the protocols it can speak with the client). So is other stuff, like graphics tablet input (with pressure sensitivity, tile, etc), minimizing windows, window miniatures as used for KDE's taskbar as well, I think.
But then, it's not like everything worked flawlessly everywhere on X either :)
And as long as the baseline is solid, we can build on it.
I may have done something wrong. I am not highly knowledgable here. For example, I just learned of Pipewire.
That said, the problem occurred for me when using the NixOS package firefox-wayland. It is possibly better to use upstream firefox with Wayland, but I have not tried; I am just running firefox on Xwayland for now.
I think capturing desktop and screenshots should be addressed by standard Wayland extensions with integration with something like Pipewire as far as I know. I didn't follow the progress of that though.
As for Nvidia - don't waste your time on their proprietary drivers on Linux. They don't to play by the rules (refuse to upstream), so no need to spend time supporting their blobs.
Like I said... I gave up and bought an AMD card. Not everyone is going to do this. It's a step down from my NVIDIA card.
I think there is still hope. Obviously today's reality is still bleak with signed blobs and plenty of question marks, but I think open-gpu-doc is a sign that NVIDIA does actually want to square away this problem, maybe they're just not sure how.
I do believe NVIDIA is mostly responsible for Wayland's poor adoption, and I firmly believe that this also lead to Wayland not getting as much developer attention as it could've gotten. The fact that one company wields this much power is a serious problem. I kind of understand the hostility Linux kernel developers seem to have towards proprietary drivers under Linux now.
Kernel developers are right to push back against blobs. Nvidia is the bad player here.
AMD is doing fine though. I have RX 5700 XT, and besides for some rough edges due to it being very new and drivers still fixing bugs, it's a very good card.
I expect Nvidia usage on Linux to plummet, due to their refusal to provide open drivers. It's already happening, just will take some time for it to drop to the point where they have little influence.
Personally I’m not the biggest fan of wayland (I haven’t found a compositor I like and using OpenGL for everything including VTEs feels like a mistake.) but I will say it’s common knowledge (as far as I’m aware) that nvidia drivers on Linux are pretty bad and you’re not going to have a good experience with them no matter what kind of display manager you use.
In what world are nVidia drivers crap? I'm regularly doing some pretty funky stuff with OpenGL on top of X11 and nVidia and this setup fails me less often and less hard than any equivalent AMD setup has done so far. Unless I'm trying to allocating tons textures or ridiculously sized vertex buffers, I don't see any hickups at all.
In the Linux world. All of their problems (roughly you can call them poor integration with the Linux stack) are consequences of them refusing to upstream their kernel driver.
The fact that Nvidia blob fails you less is not a good indicator for you, unless you test with Mesa as well in each case. Mesa is a lot stricter about OpenGL spec compliance. So if you only test on Nvidia, you likely have bugs that you didn't notice.
Every time I tested with Mesa and had issues, it turned out that Mesa was out of spec and quite specifically lying about that fact. And this was with absolutely essential features like rendering into floating point textures. So no, Mesa is not an indicator for spec compliance, either.
So when was it exactly? I doubt recently. Mesa progressed to the point of full compliance a few years ago. Today, it's trusted a lot more than the blob, due to the later silently swallowing errors frequently and messing around with substituting shaders behind the scenes.
Try testing current Mesa versions. Previous experiences are no longer relevant.
> Sway WM also does not have support for drawing tablets. I found this out, by, well, loading up a drawing program and noticing the lack of pressure sensitivity. So, that's what I'm currently working on.
Hey, thank you for working on this! The other day I plugged a tablet in, and found myself quite dumb with it not working properly. I wanted to have a go at implementing the tablet v2 protocol under wlroots, but it sounds like I'll hack on something else : P
It has been an interesting exercise so far, and frankly a quite pleasant one. Rather than autotools or CMake, many of these projects are using Meson, which is just so much nicer. I also really have learned to appreciate Sway WM's code, which I personally think is quite nice now, after having worked with it (though, admittedly, the ease of segfaulting does make you long for something like Rust.)
wlroots already has first-class drawing tablet support, but the "process input events" parts and the "dispatch input events to clients" parts are separated and it's up to the compositor to connect them in the ways they best see fit.
I'd say the biggest issue is really maturity. I actually find Wayland to be a surprisingly nice piece of software engineering. I don't know if I like the architecture really, but it comes together fairly nicely in the end.
For example, there's unanswered security questions. It would be good if applications couldn't just go and manipulate and spy on other apps like they can with X11. Wayland indeed solves this issue, but it leaves other problems. How do I capture the desktop?
wl_roots offers some extensions that help alleviate the problem, but they don't solve the full problem; for example, you can capture the screen, for which programs and an OBS plugin exists, but there's no upstream Wayland extension that can make WebRTC desktop capture work. I think what we really need is the ability to integrate policy and consent requests, but I'm not sure whether there's progress on that front, or how long it will take. Once the problem is solved, upstreamed to WebRTC, and that upstream version trickles down to Electron apps, Firefox and Chrome stable versions... well, things will be in a better place.
Speaking of web browsers, today Firefox still has some issues to go before it is fully working in Wayland natively. You can do it today, but it is not perfect; there are sometimes places in the code where it assumes it is running on X11, and things simply break. The screenshot tool is just flat out not present when running under Wayland due to the above issue.
Applications are slow on the uptake too. XWayland covers most of them, but it is not perfect. Like anything that captures the screen, of course, is not going to work under XWayland, but also, XWayland apps may behave a little off. In Sway WM, one bug is that when the mouse travels from an X window to a Wayland window, sometimes it behaves as though the mouse is still hovering over the X window at the last position it touched, which leads to tooltips showing up where they shouldn't. There's still a decent amount of GTK2 apps, and even Qt apps aren't all Wayland yet; Krita plans to start working on support I believe next year.
In my case, here's the itch I'm currently scratching: Sway WM also does not have support for drawing tablets. I found this out, by, well, loading up a drawing program and noticing the lack of pressure sensitivity. So, that's what I'm currently working on. Needless to say, this is a non-starter for anyone that relies on a graphics tablet, although if you are just using GNOME 3 it is unlikely to be an issue since I'm sure GNOME 3 supports graphics tablets just fine.
NVIDIA drivers are still a pain in the neck. I gave up and bought an AMD graphics card, and frankly I can't recommend it enough. Basically everything works better on Linux, but certainly Wayland works better. It's worth giving up some raw power. Still, for many people the proprietary NVIDIA drivers are going to need to work, and today support varies from lackluster to poor depending on what compositor you use.