LinuxLinks has kindly given me space for a semi-regular blog about open source, Linux, Windows and whatever else catches my attention. This is a place for personal opinions, with all the preferences and prejudices that come with them. The views expressed here are my own.
I use KDE Plasma on Wayland, and most of the time I forget about it. Applications open, I move between windows and I get on with my work. After years of arguments about whether Wayland was ready, that ordinary experience counts for quite a lot. I don’t need to be impressed by my display server every morning. I need it to stay out of the way.
Ubuntu 26.04 LTS brings the change home to another large group of users. The standard GNOME desktop no longer offers an Xorg session. Ubuntu made that move with 25.10, but people upgrading from 24.04 LTS may be encountering it for the first time. Their older X11 applications can still run through XWayland, and other desktops can still offer Xorg sessions. The familiar option of choosing “Ubuntu on Xorg” at login, however, has gone.
There are worthwhile benefits. Put a high-resolution laptop screen beside an ordinary monitor, or a 144 Hz display beside a slower one, and you want each to behave properly without hours of fiddling. Wayland gives desktops a better foundation for handling different scaling factors and refresh rates. Plasma’s work on HDR is another useful development. These are good reasons to move on. Simply telling me that X11 is old isn’t. Age alone is a poor argument for replacing software that works.
The security improvements are worth having too. In a typical X11 session, applications have considerable freedom to observe and interfere with one another. Installing a small utility can mean trusting it with much more than the job you want it to do. Native Wayland applications normally have much narrower access to the rest of the desktop. My text editor has no business watching me type a password into another application.
Where I become less enthusiastic is when a useful tool stops working and the explanation ends with “that’s for security”. The explanation may be correct. The user still has a job to do. Linux users have spent years putting together small utilities and scripts to fill gaps in their applications, and some of those depend on the access X11 provides.
Take xdotool. Finding a Firefox window, bringing it to the front and sending Ctrl+L to select the address bar is exactly the sort of task it was built for. Its documentation warns that typing, window searching and many other functions don’t work correctly on Wayland. A script containing those operations may need a replacement, a rewrite or a different way of doing the job. That is real work for somebody whose existing setup was doing what they needed.
I want to be able to authorise a trusted tool to operate my own desktop. I also want that permission to mean something, with a clear way to withdraw it. Leaving every application free to poke around everywhere was a poor arrangement, but making a useful task difficult isn’t an achievement in itself. The person at the keyboard should have a reasonable way to decide what their software is allowed to do.
Desktop portals provide part of the answer. An application can request permission to share a screen or window, with PipeWire carrying the captured video. The Remote Desktop portal provides access to keyboard and pointer control and supports persistent permissions. There are proper mechanisms for granting access without making it available to every application. The application, desktop and portal backend still have to implement them correctly. When they do, the user should see a straightforward request and a working feature. When they don’t, explaining the architecture is little consolation.
Remote support is a good example of why the details matter. Sharing a window in a meeting, helping somebody who is sitting at their computer, and connecting to an unattended machine are different requirements. Before relying on a tool, I would want to know what happens after a restart, whether it works when the session is locked, and whether someone must accept a prompt at the other end. A successful screen-sharing demonstration doesn’t answer those questions. Software documentation should.
Advice also needs to be specific about the desktop. KWin and Mutter are separate compositors, and portal support comes through desktop-specific backends. A KWin script may be a useful answer for a Plasma user; it won’t help somebody running GNOME. Saying that an application “supports Wayland” leaves too much unsaid if an important feature works only on certain desktops. Tell people what has been tested and what they can expect. They shouldn’t have to piece that together from old bug reports.
XWayland has saved a great deal of trouble. Many older applications can carry on displaying their windows without being rewritten, and users may never notice the difference. The limits become apparent with software that tries to inspect or control other applications. Running an X11 utility through XWayland doesn’t give it general access to native Wayland windows. Nor does it remove all the old security concerns: X11 applications sharing an XWayland server generally retain the ability to interact with one another.
Accessibility needs particular care. Plasma already provides screen readers, sticky keys, desktop zoom and other features, but KDE acknowledges limitations with some third-party accessibility tools. For somebody who depends on one of those tools, a regression can make the whole computer unusable. Describing that as an edge case tells us how common it is. It doesn’t make the consequences any smaller. Those users need a working replacement before their fallback disappears.
I don’t expect developers to maintain two desktop sessions forever. That means more code, more testing and more bugs to chase, all competing with work on the desktop most people now use. KDE plans to remove the Plasma X11 session in Plasma 6.8, with upstream support for that session continuing into early 2027. I can understand the decision. Once the fallback is gone, though, good migration instructions and answers to outstanding problems become more urgent. “Use the X11 session” will no longer be advice those developers can give.
I am happy using Wayland, and I would choose it again for my own desktop. Before recommending it to somebody with a working X11 setup, I would check the tools they depend on. Their remote support software, automation scripts or accessibility requirements matter more than my trouble-free experience. I want to be able to recommend Wayland to those people with the same confidence I have in my own setup. Getting their everyday jobs working reliably is the part of this transition that still deserves our attention.
Please read our Comment Policy before commenting.