Dropping GNOME's X11 session approved for Fedora 41
pagure.io
pagure.io
- 2009 - Python 3.0 came out at the very end of 2008 so let's count it as from 2009.
- 2011 (2 years later) - Six the compatibility library to ease the transition releases 1.0.0
- 2013 (4) - On Fedora's Bugzilla "Replace Python 2 with Python 3 in default installation" issue was created [1]
- 2015 (6) - Python 3.5 (introducing typing module)
- 2016 (7) - "Replace Python 2 with Python 3 in default installation" closed.
- 2017 (8) - Python 3.6 (f-strings introduction, for me privately first 2/3 difference that makes me consider Python 3).
- 2020 (11) - Last release of Python 2.7: 2.7.18. python-is-python3 package available in Ubuntu 20.04 (not default AFAIK).
- 2021 (12) - So far the last Six release (1.16.0)
In comparison with GNOME/Wayland:
- 2013 - Wayland 1.2 - wayland-server API becomes stable
- 2015 (2 years later) - Wayland introduction in GNOME with version 3.20
- 2016 (3 years after Wayland 1.2; 1 year after GNOME 3.20) - Mainlining Xwayland in xorg-server 1.16 release. Drag and drop actions are now added to the Wayland API. Fedora 22 defaults to Wayland session.
- 2024 (today - 11; 9)
For me: I will switch when Xfce will.
Edit: Added Six to the timeline per aragilar suggestion below and a bit more points.
1. Wayland was actually started in 2008
2. Wayland API is not stable even today
2. I meant a first meaningful stable release for both [2]. Python 3 is also seeing new releases.
[1] https://peps.python.org/pep-3000/
[2] https://lists.freedesktop.org/archives/wayland-devel/2013-Ju...
I wonder if/what the X/Wayland equivalent of six will be: XWayland lets existing X clients continue, but for things coupled to X servers, there doesn't seem to be anything yet.
I no longer can edit my comment, but I would also add:
- 2017/2018 - Wayland 1.12: xdg-shell protocol becomes stable. An interoperability milestone in my opinion.
It is feasible to just run X and have a passable desktop experience. I don't think it is feasible just running a vanilla Wayland compositor, it needs to support a bunch of non-Wayland technologies and extensions to be useful. I'll point at Pipewire as the major example. And the kernel plays a more active role than X11 was designed to handle.
So it is similar to Python 2->3, but if major parts of the standard library were being shed. Given the screenshot situation, I'd say it was a Python 2->3 except the core team insisted that printf among other things be implemented outside the language core. Wayland explicitly doesn't cover the same design space as X11 and in most cases that is intentional and an improvement.
Amen! No XFCE, no switch!
- Many apps were flickering between the actual content and black rectangles
- Games didn't work at all, most without any error messages or discernible reasons, some told me they couldn't find a GPU
- I couldn't use CUDA at all
- Firefox couldn't use WebGL or play content with hardware acceleration
After debugging this for multiple days I switched to X11, and everything immediately worked. I'm relatively proficient with Linux, and I have no idea what the issue was or how I could continue debugging it.
So, at least for me, NVidia is still completely broken with Wayland.
It works very poorly otherwise, especially XWayland apps and anything 3D - flickering, stuttering, artifacts, out of order frames.
Also if you like a stable system without early adoption features you should not be on Fedora.
Just a few examples:
- Fedora 8 changed to Pulseaudio by default [0]
- Fedora 15 adopted systemd [1]
- Fedora 34 default PipeWire [2]
Sometimes these things don't work out like the attempted switch to Wayland for Fedora 25.[3] This attempt now is really nothing out of the ordinary for Fedora and with the current state of Wayland I am in no doubt that this time they will stick with Wayland.
[0] https://fedoraproject.org/wiki/Releases/FeaturePulseaudio
[1] https://fedoraproject.org/wiki/Features/systemd
This issue doesn't seem to indicate support is disappearing completely, you'll probably be one dnf command away from getting back X11 if you're running on Nvidia or really old AMD/Intel.
Fedora was similarly crazy for making it the default when they did. I remember trying out Fedora around that time, not being aware that Wayland was even a thing. I installed it on my machine, I attempted to login, the screen goes black and then after a second I'm back at the login screen. I ended up installing another distro, not realizing what the problem was.
Wayland is wonderful if your hardware supports it well, but even then it is not without problems and regressions.
A mindset that says a piece of software should be the only option because it works for all your fellow developers on their standard Intel Dell laptops is not one I put much stock in.
X is dead, long live X.
It makes zero sense to spread a team that thin on handling some edge case no one uses. There are only finite resources, and it makes sense to focus on a smooth experience for the vast majority of people.
How have you measured that?
The sales pitches seem to revolve around the architecture being more secure because random window A can't read random window B (and BTW that means your media player's global hotkeys stopped working). It's hard to not see that as a "the killer is already inside your house, so locking yourself in the linen closet is really effective" perspective.
I can recall looking at galleries in the late 1990s thinking "I really want to get Linux on my 486 clone because I want those awesome window managers". I don't look at what Wayland has to offer the same way.
There are a few compositors lean into the eye-candy mindset (Wayfire comes to mind), but they don't shout out with the boldness of an old Enlightenment release, or even the classic dignity of WindowMaker or FVWM, just some worn-out "let's add transparency and make the windows wobble when you drag them" tropes that were nifty for 10 minutes when we first saw them under X11+Compiz.
The question is what can it do that X can't, and there are plenty of examples mentioned in this thread (including no tearing, high refresh rates, multiple monitors with different DPI, etc).
I'm guessing that's on KDE 5. They have made a lot of progress on Wayland in KDE 6 and in fact made it the default there as well.
Yes, a broken Wayland session won't be much better. But if the Wayland session is still not suitable for a majority of users by the time Fedora 41 ships, whatever window of opportunity exists for Linux is going to just get missed entirely.
I read the exact same things about it a decade ago, and I remember that Fedora 31 (maybe 32?) defaulted to Wayland. Just as it was then: I get breakage whereas with Xorg I get none. And a trivial search reveals there are _many_ more for who Wayland creates issues or showstoppers.
Once people in the Wayland sphere start to realize they'll need to cover those 1001 Xorg edge cases _on top_ of enabling the good stuff that they've done, sure, we'll be getting there. However, that interest doesn't seem to be there, counting by the #worksforme's...
Unfortunately you didn't list any of the shortcomings, just vaguely that there are breakages, but my point isn't that Wayland is perfect, it's that X11 is effectively non-viable for many people due to shortcomings that are difficult or nearly impossible to fix that nobody is working on. Meanwhile, one of the biggest showstoppers for Wayland isn't even Wayland, it's that the Linux graphics infrastructure Wayland compositors rely on isn't well-supported by the official NVIDIA driver.
Unfortunately you hand wave away Xorg being not an option an account of not much more than fractional scaling issues, which is pretty easily worked around in my experience, while many people happily use it daily, and have for decades.
I'm not saying things can be better, I'm saying Wayland proponents are always devvy types doing same-ish things on same-ish hardware. No wonder that by now Wayland supports this well!
(Of course, Pop!_OS, being pragmatic, is just going to move to its own Wayland compositor and sidestep all of that non-sense.)
Anyway, the true irony is that Xorg doesn't actually have especially great support for a wide range of use cases and hardware, it's more just that NVIDIA specifically holds Wayland compositors back for desktop support. I use AMD graphics and it works great. Intel graphics works, too. Raspberry Pi computers on VideoCore now run Wayfire by default and its about as smooth as it ever has been. Wayland has seen adoption across different use cases, from embedded machines to powering "Linux" features in ChromeOS and Windows, to the Steam compositor on Steam Deck. To paint it as though Wayland only supports developer desktops running Intel graphics is just silly.
Anyway, yes, I am not volunteering to debug your machine, but the vast majority of complaints about what Wayland can't do aren't even correct. The common wisdom is still that Wayland can't even do screen capture when I was using it in Zoom calls two years ago, not to mention the newer developments like XWayland Video Bridge in KDE. Obviously, it sucks that people are having stability issues with this switch, but just like "Works on my machine" is not a meaningful retort to issues, "Doesn't work on my machine" is also not a good excuse to hold back the future forever. Whether Wayland compositors are ready or not, X11 is not a viable future. For many users, it's not a viable present. So, if you're not willing to debug your Linux issues, I can't blame you. But, in return, you can't blame the rest of us for continuing without debugging your personal machine issues, either.
Even more niche. And I'm not saying it's not worth solving, I'm saying your niche isn't more important than other niches.
> it's more just that NVIDIA specifically holds Wayland compositors back for desktop support.
As I wrote, my issues were all on Intel graphics. From 3 different generations.
> So, if you're not willing to debug your Linux issues,
I literally wrote the opposite of that.
Happy to see you confirm the impression I initially put forth though.
It was niche, but partly thanks to Apple, laptops started getting high DPI screens. Now even relatively cheap laptops have high DPI screens, but many monitors that you would dock to are not high DPI. Hence... Many people run head-first into this when they dock, connect a display, plug their laptop into a TV, or simply have a multi-monitor setup with one that would look better at 125% scale anyways.
It was niche. It stopped being niche thanks in part to Apple and hardware manufacturers chasing them, and that's when Windows started to support it better, too.
> As I wrote, my issues were all on Intel graphics. From 3 different generations.
I don't believe you are lying here, so please believe that I am not lying either. I have plenty (frankly too many, it's a bit absurd at this point) Linux desktop/laptop machines, and of the one UHD Graphics 600 machine (a GPD MicroPC), two Tigerlake machines (a Lenovo and a Microsoft Surface Laptop 4 Intel), and one Intel Arc A750 desktop machine, all of them work very well. And while I don't use all of those constantly, I use the MicroPC and Surface Laptop a lot, and they are among the most stable Linux devices I own.
So while I believe what you are saying, what I'm trying to suggest is that they're probably not endemic issues. This is pretty important for the sake of this discussion.
> Happy to see you confirm the impression I initially put forth though.
I hope you are not expecting people who are simply trying to discuss the future of Linux desktop stacks to be volunteering to debug your personal issues. Don't get me wrong, I'd actually love to help if I could, but debugging hangs and freezes that could be an interplay of any of hardware, driver and compositor is not fun and doing so over the Internet indirectly is even less fun.
I fully acknowledge the caveats of running bespoke Linux configurations on unsupported hardware. I don't advocate for normal people to do this. For friends who are stubborn and want to run Linux now on hardware they already own, of course I am supportive and try to help debug it, since I do this same thing all the time. But to me, these are issues that your system vendor should be helping to sort out, not something most people should be expected to figure out on their own. Even for the tech-savvy, it's not fun.
As for figuring out where to go to debug a hang, there's no particularly special advice for Wayland versus anything else that may cause systems to lock up, since Wayland compositors are just normal DRM/KMS programs that happen to speak the Wayland protocol. If the machine is not kernel panicking and can be accessed over SSH, I'd wager to guess there is probably something indicative in dmesg.
(Lack of support for screensavers is a real but not very important issue. The ext-session-lock-v1 protocol provides everything needed, and wlr supports it, but jwz doesn't like its design, which means xscreensaver is not getting ported. Also Gnome and KDE are yet to come on board.)
That said, I am really hoping that GNOME Foundation donation from the Sovereign Tech Fund comes to the rescue here. I was very happy when I read the whitepaper[2] for the accessibility protocol that was being worked on, as it looks like it is being designed with the right priorities to build real and robust accessibility technology. These technologies aren't just great for accessibility but also for automation, and I think that putting them into Wayland protocols (as opposed to off to the side like what is being done with libei) is the right way to go.
[1]: https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/
[2]: https://gnome.pages.gitlab.gnome.org/at-spi2-core/devel-docs...
You are you talking about Wayland. Wayland has no or severely lacking mechanisms for screenshots, screen sharing, positioning of windows, window management, window icons, drag and drop, ...
Many of the issues are duck-taped with a clusterfuck of incompatible external protocols which turns the whole ecosystem into a complete mess.
But what do you expect from a severely lacking protocol designed for digital signage and car entertainment systems that is being shoehorned into a desktop protocol.
> Everybody keeps treating this issue like it's just programmers deprecating old code for fun
No. It's all about funding. DARPA (=RedHat) used to fund X11, now it's funding Wayland. That's it. X11 is still to this day the better solution for Desktops, by a long shot.
> while it's easy to downplay the importance of its shortcomings
The only shortcomings that are consistently being downplayed are those of Wayland.
This seems like high level tin foil hat wearing.
Are there any publicly available sources that tie up DARPA, Red Hat and Xorg? I’m not even sure what to Google tbh.
> Many of the issues are duck-taped with a clusterfuck of incompatible external protocols which turns the whole ecosystem into a complete mess.
As opposed to the mess of X protocols which are elegant and working great?
- The X11 protocol itself is insane. Obviously any reasonable person is going to want to write an app that just uses bindings like XCB, but if you venture into the protocol from the ground up you will quickly run into weird concepts like visuals and colormaps that beckon back to the days of 256 color graphics, and protocols whose endianness depended on the host machine.
- There is an input method protocol called XIM. It has not been updated or improved at all in 30 years, and nobody has ever attempted to make a successor to my knowledge. It is essentially completely useless, and thus all of the modern UI toolkits, IME buses, and input methods have to implement their own communications. It winds up being N x M, twice (once for UI toolkits to buses, and a gain for buses to input methods.) When people run into an issue and IBus or FCITX stop working, they usually just give up, because fucking with environment variables and UI toolkit plugins to try to get everything to work again is just not worth the trouble. Wayland does not have a perfect world here, but what it has is real life progress on this issue, wherein one can install Sway, fcitx5 and a GTK-4 app and everything works.
- X has some core input events, but it's not enough, so there is XInput. XInput was also not enough, so there is now XInput2. XInput2 is not new but it is still not the default in many apps, like Wine's graphics tablet support or Firefox (which has XI2 code, but it's still disabled.) This is the short version, because I value my sanity. But as someone who tried using a touchscreen on Linux in 2013, I assure you I have more experience with the "robust stability" that Xorg is known for.
- Inter-app communication is handled via ICCCM, which isn't an X protocol per se but more of a way of catastrophically abusing X properties, including using them as synchronization primitives for makeshift data channels. To this day, QXcb is known to have race conditions in its implementation of bulk clipboard transfers in some (thankfully rare) circumstances, and nobody has figured out what causes it.
What is true is that over the years, Xorg has been improved greatly. It has hotplugging. Modeswitching has been moved to the kernel. It no longer requires root. It is no longer literally a print server. There are far less segfaults hiding in XI. However, the design issues that X ran into are basically cemented into history at this point, and that's why it is not a viable path forward.
> But what do you expect from a severely lacking protocol designed for digital signage and car entertainment systems that is being shoehorned into a desktop protocol.
Wayland was definitely not originally or especially designed for embedded use cases. It was explicitly developed as a successor to X11 that reflected the direction the Linux graphics stack was moving in. It was indeed developed by Redhat, but also by a prominent developer that worked on Xorg.
I am aware that Weston has indeed gained some success in automotive and embedded environments, but this makes sense, it's well-suited for that. Xorg wasn't fantastic for these use cases for a variety of reasons, but Wayland offers much more flexibility for vendors. You can relatively easily extend Weston or even write your own compositor using just standard Linux graphics technology, seems pretty convenient.
> No. It's all about funding. DARPA (=RedHat) used to fund X11, now it's funding Wayland. That's it.
Not that this is relevant or anything but... man. No comment.
> X11 is still to this day the better solution for Desktops, by a long shot.
It is definitely the best solution for desktops that have the exact same set of needs they had 20 years ago. I'm not even disputing that, I'm dead serious. If your needs for a desktop haven't dramatically changed in the last couple of decades X11 is objectively better.
What you are missing is that for a lot of people, it has in fact changed quite a lot, and this is legitimately holding back Linux. I'm not arguing Wayland is a beautiful and elegant design. I'm arguing that we need something that we can actually fucking improve and build the future on top of, and between X and Wayland as a base, it's not even close. It's Wayland. It has been Wayland.
> The only shortcomings that are consistently being downplayed are those of Wayland.
The reason why people think this is simple. When most people talk about Wayland shortcomings, they're talking about things that actually can be improved and fixed, in some cases they're being fixed right now, in others it might take time but there's paths forward. When most people talk about X11 shortcomings, they're talking about things that will never, ever be fixed. Ever.
The only thing that's been entertaining to me is that X was always the bane of our existence and the butt of many Linux user's jokes in around 2004, but somehow there is amnesia. Now the impetus to move on from X11 is suddenly seen as hasty, despite the fact that it is definitely severely overdue.
They are clearly better, simpler and more tested then the conglomerate of protocol mess pertaining the Wayland ecosystem.
> The X11 protocol itself is insane.
According to whom? I would call Wayland insane. This is just your personal opinion
> Wayland does not have a perfect world here
X11 is not great, but Wayland is far worse also in this case. I agree.
> XInput was also not enough, so there is now XInput2.
X11 is designed to be extended. Wayland manages to be worse than all of that.
> Inter-app communication is handled via ICCCM
Wrong! ICCCM standardizes communication between window managers and clients. Which is one of the strengths of X11 and allowed a plethora of niche window managers to flourish.
X properties are not "abused" for IPC. They are a central part of it and far more elegant than abominations like dbus or Wayland.
> QXcb is known to have race conditions
Qt is more concerned with portability than being a X11 toolkit. That's why they are having problems.
> However, the design issues that X ran into are basically cemented into history at this point, and that's why it is not a viable path forward.
There are zero design issues with X. With the right extensions it can be a "viable" path forward.
> If your needs for a desktop haven't dramatically changed in the last couple of decades X11 is objectively better.
Indeed but even for today's needs in a world where screen sharing is one of the most important tasks of desktop computers X11 manages to be miles ahead of Wayland which does not even standardize basic functionality like screen sharing.
> I'm arguing that we need something that we can actually fucking improve and build the future on top of, and between X and Wayland as a base, it's not even close. It's Wayland. It has been Wayland.
What is your argument here? Wayland is shit but it is "the future"?
X11 is extensible by design and has been extended many times. In this way it "survived" many generations of graphics hardware starting from dual ported RAM and ending with GPU's where one is more powerful than all computers in the world combined at the time X11 was introduced.
> When most people talk about Wayland shortcomings, they're talking about things that actually can be improved and fixed, in some cases they're being fixed right now, in others it might take time but there's paths forward.
Waylanders are "fixing" things for 16 years now. This mantra is getting bit stale to say the least.
> When most people talk about X11 shortcomings, they're talking about things that will never, ever be fixed. Ever.
What exactly can never "EVER" be fixed on X11. Can't think of a single thing.
> The only thing that's been entertaining to me is that X was always the bane of our existence and the butt of many Linux user's jokes in around 2004
X11 was bad in 2004. But so was every other operating system that had to deal with a new type of graphics hardware. It was a symptom of technological progress.
Wayland was never great and due to the politics, its idiotic design and protocol hell it will never be.
> Now the impetus to move on from X11 is suddenly seen as hasty, despite the fact that it is definitely severely overdue.
The only thing that is overdue is putting Wayland into the trash where it belongs.
I just installed Fedora 40 (KDE 6) using the Fedora-40-20240304.n.0 nightly ISO. I then enabled the NVIDIA and Steam repos and installed both. Also installed asusctl. Everything seems to work perfectly.
This is on a Asus ROG Zephyrus G14 from 2021 (GA401QM) laptop with a Ryzen 9 5900HS + NVIDIA 3060. The screen is at full resolution at 120 Hz. Keyboard lights work, audio works, WiFi worked out of the box, sleep works etc.
I tried a few games on Steam and they all worked out of the box without any tweaks what so ever. I also find I am really enjoying KDE. It must be over 15 years since I last tried KDE but now I really think it is way better than Gnome.
My desktop is still on Windows, I'm waiting for HDR support. I'm so excited to get off Windows forever. It really feels like Linux is finally good enough.
What HDR content would you like to view? I think my screen supports it, but I have long forgotten about that feature — maybe it wasn't even working when I tested it with a MacBook, but I couldn't tell any difference.
"KDE#Plasma 6.0 introduced experimental HDR support for Wayland session: System Settings > Display & Monitor > High Dynamic Range > Enable HDR." according to https://wiki.archlinux.org/title/HDR_monitor_support
Making it completely disappear to a tray icon.
> 1 less v8 instance running
I doubt. With process isolation, I guess every tab runs its on V8. Otherwise, oh boy.
Btw, this isn't for slack but teams: I use the website because their Linux app blows, but I actually use a totally different browser (chromium) to my main browser (firefox) intentionally. Occasionally when teams takes 100% cpu and memory for no reason, I can 'pkill chromium' without nuking firefox. So the "one less engine" argument wouldn't convince me.
The good thing with the browser version is rolling updates are immediate, no need to upgrade a flatpak or rpm. And if they fuck up, rollback is also immediate.
Also this is about removing the gnome x11 session package from the default install. That doesn't mean you can't run X11.
Having said that I don't know who would want to keep using X11 AND choose Fedora as its goto distro. This is a distro whose purpose is to push forward these kind of stuff, there are a number of much more conservative distros available and one could argue that if you are conservative and want to stay in the RPM/RH family you can use RHEL or a derivative distro such as Almalinux or Rocky. That is what I use on the media center computer in my living room for other reasons[1]. Back in the day someone would complain about outdated package but nowadays with tools like flatpak, podman and the toolbox this is just not true anymore.
[1] I don't power it up so often. I don't want to have tons of packages to update every time I power it up to watch a show on streaming. All I want is to be able to upgrade the browser's flatpak.
What do Discord, Slack, and Nvidia all have in common?
Yes, it'll push developers a little harder, but we will see tons of complaints in the beginning. This will take another ~2-3 years to be sorted out. While X11's codebase is known for its state, it's working well at this point.
I have experienced "very fun" problems with a "supported NVIDIA card with official drivers that support that card", while people said that they are using theirs without any problems for years.
Thankfully enough people have made it for Fedora to be convinced it's a good idea. Other distros will soon follow (as always) and X11 will wither. Finally.
X11 will not wither overnight. There are still things which are very dependent on X11. Remote connections comes to my mind, for example.
Lastly, not all distributions are followers. Debian (testing at least), installs Wayland by default, but not enables it. It's installed on my system for a couple of years now.
Thankfully I don't have to, I want shiny new software thanks.
> Remote connections comes to my mind, for example.
Nobody uses them any more.
That's a choice. I prefer uptime more, for example. I use boring technology to create fun things.
> Nobody uses them any more.
You should follow X2Go users' & OpenOnDemand mailing lists. They're very heavily used by some significant groups (e.g. scientists).
There is also a VNC server for fullscreen sessions (only supports wlroots compositors for now): https://github.com/any1/wayvnc
Lol, I almost spit my coffee all over the keyboard... That timeframe is wildly unrealistic.
It will take the best part of a decade from the time all major distros switch their defaults (i.e. RedHat, Debian, Ubuntu, SuSE) to get to a point that could be considered stable (i.e. where the average user won't encounter breakage as soon as they run an app that was not part of the default install). And even then, lots of debris will be left floating, because nobody is going to update some small app from 2005 or even old releases of QT and GTK.
The Linux desktop is currently going through its Vista moment, and it's going to go on for a very long time.
I don't know about RedHat, but Debian already ships Wayland in Testing. Maybe current stable also has in its default installation I need to check. Tons of people are using it on Ubuntu, too.
So while ironing out everything will take even more than that, I assume a full decade starting today, first 90% will take ~2-3 years. As we know, second 90% doesn't really finish. Even today, X11 can be broken in interesting ways.
OTOH, there'll be always some debris left. It's same for Windows and macOS, too. Only difference is, Windows ships its old versions as WoW subsystems or invisible diversions for more than two decades now.
People always see the applications they use, but there's another world where people update extremely old programs or develop shims to keep them working. Linux ecosystem is an elephant now. And since people can see and feel different parts of it, everybody tells something different about it. It's much more complex and layered than it seems.
Vista moment? Even KDE4.x was better than that thing with all its bugs. Hah.
FWIW I tried to switch to Wayland 3 times in the last year before finally making it stick. I had to change a ton of silly little things, like:
- grepping through my .config and /etc for any mention of xclip and switching to wl-copy (vimrc, tmux.conf to name two)
- enabling webtrc on browsers so that screen sharing works in web apps (MS Teams still refuses to work)
I don't know if there's a good source of migration tips that covers all of these things in one place so you can search for the things that affect you. But on a work machine, switching across can result in random minor disruptions over a week, some of them in the middle of meetings. And if you're having "one of those weeks" you need to switch back to what works.
Even now on OpenSUSE Tumbleweed, a bleeding edge rolling distro with excellent wayland + kde plasma support, I still run into the odd issue that makes me wanna switch back. Disappearing cursor is one. It's totally random, but if I click on a text input box on a browser, I get no text cursor. WTH.
This is the kind of thing that makes it harder on people to switch
The lack of focus and backwards compatibility in the open source world is appaling. As much as I like to complain about systemd it is not surprising it came to replace 3 scripts in a long coat
Someone eventually has to break the stalemate, and Fedora is usually the distro making the switch first. Its users are used to stuff like this, and it serves as a nice heads-up for app developers to get to work because it'll land in RHEL within a year or two and you can't really claim Linux support if your app doesn't work on RHEL.
Besides screensharing, which from what I hear is still a clusterfuck (i.e. it can work just fine, but any given app might or might not work), I've whittled it down to two, seemingly very basic and essential-to-me features, that for some reason still aren't supported:
Window positioning:
As in, the ability for an app to request a specific position for a window. Like when I minimize my music player to the tray, and when I open it again I want it to appear in the same location. Or when productivity apps remember the positions of their tool windows, or I want to script apps to start in specific positions using the near-universal "--geometry" flag of old. Wayland doesn't want to expose global coordinates, supposedly for security reasons (which I call bullshit on), and in order not to discriminate against non-finite/non-square displays (which I guess could just ignore the position requests, but apparently that's not good enough).
One of the proposed solutions for this is the "xdg-session-management" protocol, where it would be the compositor's job to remember window positions for client apps. But to me that only sounded like a partial solution that probably won't ever work consistently, and anyway there hasn't been much progress on the MR for this which was started a full 4 years ago. There's been a lot of activity recently with the "ext-placement" protocol, which from what I understand introduces an application-local "zone" system which will allow window positioning in a very roundabout way that will hopefully please everyone. I appreciate everyone's work on this, but at this rate it will probably take a couple more years until compositors support this new protocol, and client apps have made the necessary changes.
Refresh rate changes:
I have a HTPC connected to a TV. No refresh rate changes means I get constant micro-stutters when watching 24fps content. And yes, I do notice them, and no, turning on motion smoothing doesn't make them go away (and looks even crappier anyway). There are protocols to request refresh rate changes (last time I looked, at least four of them), but client apps like Kodi are not allowed to use them (only system management tools), and proper support for apps to signal a desired refresh rate is tangled up in discussions about achieving the perfect design to support VRR. So I'll give this at least a couple more years too.