Wayland on KDE Blogs

Going all-in on a Wayland future

The Plasma Team — Wed, 26 Nov 2025 00:01:00 +0000

Well folks, it’s the beginning of a new era: after nearly three decades of KDE desktop environments running on X11, the future KDE Plasma 6.8 release will be Wayland-exclusive! Support for X11 applications will be fully entrusted to Xwayland, and the Plasma X11 session will no longer be included.

For most users, this will have no immediate impact. The vast majority of our users are already using the Wayland session, it’s the default on most distributions, and some of them have already dropped — or are planning to drop — the Plasma X11 session independently of what we decide.

In the longer term, this change opens up new opportunities for features, optimizations, and speed of development.

Because we’re certain that many people will have questions about this change, the Plasma team has prepared the following FAQ:

Plasma 6.8 means the X11 session will be supported by KDE until…?

The Plasma X11 session will be supported by KDE into early 2027.

We cannot provide a specific date, as we’re exploring the possibility of shipping some extra bug-fix releases for Plasma 6.7. The exact timing of the last one will only be known when we get closer to its actual release, which we expect will be sometime in early 2027.

What if I still really need X11?

This is a perfect use case for long term support (LTS) distributions shipping older versions of Plasma. For example, AlmaLinux 9 includes the Plasma X11 session and will be supported until sometime in 2032.

Will X11 applications still work?

Outside of rare special cases, yes, they will still work using the Xwayland compatibility layer. It does a great job of providing compatibility for most X11 applications, and we provide several additional compatibility features on top, namely improved support for fractional scaling and (opt-in) backwards compatibility with X11 global shortcuts and input emulation.

In certain cases, 3rd-party applications doing specialized tasks like taking screenshots or screencasting need to be adjusted to work as expected on Wayland. Most have already done so, and the remaining ones are making progress all the time.

Does X11 forwarding still work?

Yes, Xwayland supports it. Waypipe exists for similar functionality in Wayland native applications as well.

Can I still run KDE applications on X11 in another desktop environment?

Yes. There are currently no plans to drop X11 support in KDE applications outside of Plasma.

This change only concerns Plasma’s X11 login session, which is what’s going away.

What about gaming?

Games run better than ever on the Wayland session! Adaptive sync, optional tearing, and high-refresh-rate multi-monitor setups are all supported out of the box. HDR gaming works with some additional setup, too!

What about NVIDIA GPUs?

While Wayland support in the proprietary NVIDIA driver was quite rocky a few years ago, it has matured tremendously. Graphics cards still supported by the manufacturer work just fine nowadays, and for very old NVIDIA GPUs, the open source Nouveau driver can be used instead.

What about accessibility?

Accessibility is a very broad topic, so it’s hard to make any definite statements, but we’re generally on par with the X11 session. All the basics already work as expected, including screen readers, sticky & bounce keys, zooming in, and so on.

Some things are better, like touchpad gestures for adjusting the zoom level, and applying systemwide color filters to correct for colorblindness. And even more improvements are expected by the time Plasma 6.8 rolls around.

However, accessibility features provided by third-party applications may be worse in some aspects. Please open a bug report if you have any special requirements that we don’t cover yet! This is an active topic we’re very interested in improving.

What about automation?

Many tools can be used for automation in the Wayland session; for example wl-copy/wl-paste, ydotool, kdotool, kscreen-doctor, and the plasma-apply-* tools. Generally Plasma is extensible enough that you can add what’s still missing yourself, for example through KWin scripts or plugins.

What about the Significant Known Issues?

While we can’t promise all problems will be completely gone (some depend on application support), we’re actively working on addressing the last stragglers on that Wiki page.

Some of them are really close to being fixed; for example, the issues around output mirroring will be gone in Plasma 6.6. Session restore and remembering window positions are also being actively worked on.

What about Plasma on the BSDs?

FreeBSD is already shipping a working Wayland session, so there should be no upstream problems on that front. If there are any remaining issues we can help with upstream, please reach out to us!

What about the kwin_wayland and kwin_x11 split?

In Plasma 6.4, we split KWin into separate X11 and Wayland versions. This allowed KWin to go all-in on Wayland earlier, without being held up so much with legacy support for X11. For users with remaining edge-case requirements for X11, we put in the extra effort to keep X11 support for the rest of the desktop since then.

While the split helped a lot, KWin is only one piece of the puzzle. The Plasma desktop as a whole has many places where development is held back by the need to support the lowest common denominator of the two window systems.

The bottom line

This is happening because we believe that eventually dropping the Plasma X11 session will allow us to move faster to improve stability and functionality for the majority of our users — who are already using Wayland.

If we want to keep producing the best free desktop out there, we have to be nimble enough to adapt to a rapidly changing environment with many opportunities, without the need to drag forward legacy support that holds back a great deal of work.

The Wayland transition has been long, and at times painful. But we’re very close to the finish line. Passing it will unlock a lot of positive changes over the next few years that we think folks are going to appreciate!

Revisiting X11 vs Wayland With Multiple Displays

Tracey Clark — Mon, 02 Jun 2025 00:00:00 +0000

The things I do for QA...

A few years ago, I was among those who found Wayland too painful to use every day. Over time, I gave Wayland a try now and then. It finally got usable enough for me to switch to as my default a couple of years ago.

Recently, during the soft freeze before the Plasma 6.4 Beta was released, I used mainly X11 on both my laptops - for science! And by science, I mean regression testing. I was curious what the experience was like compared to what I've become accustomed to with Wayland.

In short, Wayland supports multiple displays and color so much better. It was painful using X11 again.

My setup for daily work

I was using two laptops and two external monitors. Both were running Plasma built from git-master.

Main: Dell XPS laptop, plugged into a dock. This is connected to 2 ultrawide monitors - one via Displayport, the other via HDMI.
Secondary: Lenovo Flex laptop, usually just using its built-in screen. Sometimes I swap the right hand monitor over to it, for testing display shenanigans.

Initial impression - so limited

I fired up the XPS, did updates, and booted into an X11 session. Next, to Display Configuration to re-enable the right hand monitor (disabled the night before). Immediately, I was struck by how bare the settings window looks compared to Wayland. Here are screenshots of the settings for same HDR monitor on 6.3.5.

Wayland:

X11:

Second thoughts and hello, Dr Konqi

Time to enable the display. For reference, this takes moments in Wayland. It was just a wee bit longer and more fraught with X11.

After enabling the monitor and clicking Apply, all 3 screens went dark. After about 20s the laptop display came on. After about another minute, the right hand display finally got output before all 3 displays were dark again. I unplugged the laptop from the dock. It came up to the login screen. After logging in I saw the good Dr Konqi telling me there was a crash in plasmashell. We were off to a great start.

Like a good tester, I sent the crash report off. With some trepidation, I plugged the docking cable back in, as similar struggles from years past came back to haunt me. All three displays were black, although I could move the cursor around in them. It took a good couple of minutes for plasmashell to display everything, along with window decorations and panel contents. It was faster later, but wow, was this a noticeably worse experience than Wayland.

Other observations, or third thoughts

Wayland advantages

Fractional scaling - the ability to have a screen at, say, 110% zoom. See that lovely screenshot, above.
When paired with how easy it is to change font face and style, this is great for accessibility. Being able to read the text on any display at whatever resolution can't be overstated. When I have to use Windows, where you can't adjust text separately from resolution, I have sadness. I also have eyestrain trying to read tiny text in dialogs.
Scaling per display - so my laptop's high resolution display can be at 150% and my external displays at 100% to make things readable on all of them. Another plus for accessibility.
HDR and color profile (ICC) support. This is important for getting the mos out of my monitor with games and more. Also... preeeetty.
Snappier overall performance (on my systems).
The ability to send a window to multiple desktops, or just one. In X11, you can ....THNG

Wayland pain points

These are the things I ran into personally. There's also the list of Plasma/Wayland Known Significant Issues.

The most annoying problem for me is with LibreOffice, since I use Calc almost daily. There's a bug (on their tracker) where, with multiple monitors with different scale factors, UI elements are too big.
Lack of a robust, easy to use text expander with a GUI - that actually works out of the box. Autokey has been on my installs for many years, used for work and personal stuff. While it launches, and I have access to my phrases, there's no actual text expansion. There's an open issue for Wayland support (that pre-dates the Pandemic) but it hasn't gotten much traction. I've been keeping an eye out for years for a decent replacement, and have tried a few things but not found what I'm looking for, yet.
Copy and paste to and from VMs I use VMs a lot for testing things on different Linux distros. My workaround for this is to have text files saved in a directory that's shared from host to guest.
It took time and a few forks to get KVM software that was reliably developed and worked with Wayland.¹ I had been using barrier on X11. A few software forks and experiments later, I've settled on deskflow.

X11 Advantages

Remembering window positions across reboots.
Working text expansion.

X11 pain points

Drawing the screen is slower after logging in or restarting plasmashell, for example, with the same hardware and open applications.
Floating panels and adaptive opacity are known to cause performance issues with X11 with an NVIDIA GPU.
Lack of scaling per-monitor.
Text on my XPS's screen is too small to be readable if the external monitors are at a comfortable scale. I had to move any window I needed to read text on (most of them) to the external monitors.
The HDMI monitor was set to the wrong resolution and refresh rate if I connected it to the second laptop. I had to manually correct it.
After enabling HDR on that monitor with the Flex in Wayland, and switching to an X11 session, the monitor enabled HDR but the colors were over-saturated.
After working with a few windows, fonts in Firefox became badly hinted. This made characters look weirdly colored instead of white / black, and made reading things difficult.

Final thoughts

Once upon a time, Wayland was too painful for me to use as a daily driver. It didn't support some of my utilities and it wasn't stable enough with my multi-monitor setup.

These days, Wayland is so much more usable and stable with multiple displays that it makes using X11 painful by comparison. While there are still those few issues I mentioned, I feel Wayland's advantages outweigh them.

The KVM software journey... The first one I used was Synergy, which was amazing to me. Being able to use the same keyboard and mouse on both a Linux laptop and Windows desktop at the same time was magic. Unfortunately, Synergy took their UI in directions I didn't like. An open source fork named barrier emerged, which aimed to restore the simplicity I was looking for, so I switched to it. This served me for a long time, but development stopped in 2021. With the advent of Wayland, barrier was forked to input-leap which implemented Wayland support. Sadly, development seems to have languished. There is yet another project, deskflow, which is also free and open source. It's sponsored by the Synergy folks. We end where we began. ↩︎

Linux desktop shell IPC: Wayland vs. D-Bus, and the lack of agreement on when to use them

Eike Hein — Sun, 11 Oct 2020 00:00:00 +0000

On the Linux desktop today, we have two dominant IPC technologies in use between applications and the desktop environment: Wayland and D-Bus. While created for different reasons, both are generically extensible and can be used to exchange data, synchronize state and send requests and signals between peers. A large number of desktop use cases are implemented using either technology, and some use cases are already distributed across both of them. The status quo is mostly the result of organic growth, with individual implementation choices down to tech friction or the lack thereof.

For some use cases the choice of which to use is not obvious. This is one of the factors still slowing down the standardization and hence adoption of Wayland-based sessions currently.

The overlap

While the semantics of Wayland and D-Bus are really pretty different, both enable the exchange of structured, typed data between peers along with RPC-shaped uses. While D-Bus supports many more connection topologies than just one process talking to another, for applications interacting with the desktop environment via protocols both parties agree on the difference is small and usually hidden by toolkit abstractions.

More importantly, both technologies were created to service the same key users - desktop environments and application toolkits - and widely adopted protocols layered over both transports deal in some of the same primitives coming from that ecosystem. For example, .desktop file names as stable application ids are referenced in both the Wayland xdg-shell protocol as well as well as <a href="https://www.freedesktop.org/wiki/>freedesktop.org's <a href-"https://specifications.freedesktop.org/notification-spec/latest/>notifications protocol.

The current usage split between the two protocols is a result of tech friction and little planning - some things are easier to talk about on a Wayland connection, others are easier to talk about on the D-Bus. It's down to the protocols we already have in hand now, adoption in various codebases and a spectrum of opinions.

Tech friction

Wayland (cool book link this time!) is the designated successor to the venerable X windowing system. Born from the same community, it's certainly informed by some of X's successes, but also many of the pain points experienced by implementers of X over the years. A lot of the advances in Wayland relate to the particular problems of windowing and presentation, but its heritage also did much to set the scene for revisiting what really belongs into the core windowing system and what doesn't. D-Bus and even its own direct predecessors did not exist for much of X's long and storied history. Conversely, in the Wayland world it has become a lot harder (in terms of scrutiny applied by the community) to get a desktop feature into a widely-adopted spec than it was in X, which for a long time was the only widely adopted transport medium in place.

D-Bus is a far more generic IPC/RPC technology supporting a wider variety of connection patterns between parties. Service activation through the bus, multicast signals open to any participant, pervasive introspection of interfaces - you won't find much of this in Wayland, and D-Bus is the latest in a chain of technologies driven by genuine needs for such capabilities.

There's a third element to the discussion, and it's the rise of the freedesktop.org standards ecosystem, broadly promoting interoperability between desktop environments and the portability of apps between them. Put on a timeline, freedesktop.org and D-Bus happened a decent number of years prior to the arrival of Wayland - D-Bus, therefore, has a headstart in being the medium of choice for freedesktop.org specs and fd.o standards being referenced in protocol and service designs.

In the end:

Wayland is the natural transport between the application and the compositor, one of the key services of the desktop environment. Windowing being the goal, a lot of the protocols in place now make it easy for the two parties to converse at the level of windows. In xdg-shell, the application can also let the compositor know its application id as part of window metadata. This is one of several established ways for the compositor to know what application it's talking to. (A more recent aid is mapping from the client to a cgroup set up by the application launcher, e.g. Flatpak or Plasma, which can improve the security of this type of authentication. In both Wayland and D-Bus, you sometimes see this need - and much more - addressed by inserting a protocol proxy like xdg-dbus-proxy or Sommelier, respectively.)
D-Bus is the transport used for many other app-to-service interactions, e.g. notifications. On D-Bus it's often convenient to find the application id of a participant, but it's hard to relate the conversation to the windowing system. For example, efforts to relate a D-Bus notification event to a particular window to jump to are fairly recent and not yet widely implemented.

The decision vacuum

There's a particular snag in the timeline: With D-Bus arriving on the scene a lot later than X, a lot of interactions between apps and the desktop environment were spec'd into the X medium in the past. For example, various forms of window or broadly application state (e.g. requesting user attention) or requesting focus/activation from the window manager. No one thought to put onto D-Bus what was widely adopted and working already, although sometimes more comprehensive replacements gravitated towards using D-Bus instead and managed to get traction.

With X being replaced, a lot of the stuff in ICCCM and EWMH/NetWM is now up for grabs for either Wayland- or D-Bus-based specs.

Current trends: Plasma vs. Gnome vs. wlroots/Sway

Wayland is the natural choice for a compositor service to talk to apps. D-Bus is the most popular option for other desktop environment services to talk to apps. In some desktop environments, the compositor and other services may live in the same process (Gnome Shell in particular), others distribute services over few or many processes.

In Plasma, the compositor and the desktop shell are two seperate processes. The compositor implements the window management policy, and the desktop shell process draws your wallpaper, your panels and your menus. The notifications service lives in the Plasma desktop shell process as well. This architecture is a straight port-over from the X way of doing things, but it remains advantageous - for example, a crash in the shell won't bring your compositor (and then your apps) down with it. In fact, we're aiming for still more process isolation in future generations of Plasma.

The compositor and the shell being in different processes requires them to synchronize state. The shell also needs to pose requests to the compositor. In Plasma, this communication happens through a set of Plasma-specific Wayland protocols. This is a good example of a friction-driven implementation choice: As the shell and the compositor want to mainly converse about windows, using Wayland posed the least friction. On the other hand, in cases of the compositor talking to support processes such as the screen configuration service or the System Settings app, the choice of transport varies - Wayland protocols in some cases, D-Bus interfaces for others (notably virtual desktops configuration). Overall, we don't have a clear IPC usage policy at the moment.

For other desktop environments I cannot speak with any true authority, especially make no claims about implementation policy. Perhaps owing to the single-process shell architecture, I see our friends at Gnome using D-Bus-based protocols in a few places where we use Wayland-based ones, e.g. for screen configuration (edit: lack of friction between D-Bus and XDG desktop portals has been pointed out to me as another factor; makes sense).

The wlroots community (consisting of Sway and lots of other users) seems to broadly prefer Wayland over D-Bus to run protocols through. It's easy to surmise why - wlroots' raison d'être is to enable building shells on top of Wayland, and in particular shells built up of interoperating pieces made by distinct authors. Enabling this interoperability through the community's Wayland-based tooling must come naturally, and the wlroots community is no doubt leading this particular effort at the moment. Some of these protocols are great, and it's likely Plasma will implement more of them in the future.

Unresolved cases

An example where the lack of a clear choice has been slowing the desktop community down is focus/activation requests. Consider the following common usage pattern: The user clicks a link in a chat app. It opens in the default browser. For convenience, the user might want the browser window to be raised to the front now, the click being an instruction to the system to form a smooth workflow from one app to the other.

It might come as a surprise, but 12 years in, there's no good, widely-adopted solution to making this work in Wayland-based desktops.

It should not come as a surprise, however, that this an example handled in the past by an X-based protocol that's now out of the picture. The X way of doing things wasn't very robust - it put a lot of trust into the application posting a legitimate request to be activated, and it required the window manager to implement complicated heuristics to filter out illegitimate or just ill-timed requests. These heuristics are collectively known as "focus stealing prevention", e.g. sticking to the current window while the user is typing into it. For now, Wayland-based desktops by and large are skating by on even poorer semantics - giving focus to any new window while relying on heuristics, with partial solutions to the problem of already-existing windows not pervasively implemented across apps.

It's a good example of a case where the community really doesn't want to miss a chance to get it right this time. While trying to do so, a lot of more or less related desktop features have been looked at as well - for example, the X convention of apps placing attention hints on their windows to blink them in the taskbar, to be cancelled by the window manager when the window is raised and focused. Also the case of applications posting notification events through D-Bus carrying a link back to particular window, e.g. to jump from a chat message alert bubble to the specific conversation window.

Over the last couple of years, many different approaches have been proposed and tried, and we still don't have the One True Spec.

There seems to be fairly solid agreement on the need for a token exchange mechanism to clear the focus handover in the compositor - the chat app requests a token from the compositor, hands it to the browser handling the link (e.g. through an environment variable) and the browser may use it to request focus from the compositor. But there remains a lot of division over whether the activation request (along with other use cases) should be layered over the D-Bus-based notification spec, or whether all of this should remain solidly Wayland territory:

The argument for D-Bus is that a mechanism to relate notification events to particular windows (by including a window handle in the metadata) is needed anyway, and once that's in place, it's easy to add in the focus token. Using special notification events to inform about window-specific ongoings is an extensible pattern potentially spanning all of activation and attention-seeking, along with things like taskbar job progress meters and others. The event spec also already has fields useful for accessibility - imagine a system where a blind user gets a "app X wants attention for Y" readout, without needing to craft a new protocol to tell the compositor specifics about Y. On the other hand, going this route clearly also requires some spec work for existing notification service implementations to be able to do the right thing when processing these special events.
The argument for Wayland is that the above requires a lot of translation forth and back (or rather, import and export of handles and tokens), and in the case of multi-process service architectures, expensive chaining of IPC. Plus it requires a Wayland-based desktop environment to use D-Bus for a core use case, while an X11-based desktop environment could do without a second transport for the same features. For some projects, this is an unattractive expansion of their current dependencies.

In conclusion

I suspect the above example of focus/activation requests will ultimately be addressed by a token exchange via Wayland, and the notification spec way of doing things will be implemented alongside it as well, rather than picking one way of doing things. And perhaps that's fine.

But it's worth stopping for a moment and being conscious of what's going on. We would all benefit from some commonly agreed-upon guidelines on where the scopes of Wayland and D-Bus end in our application platform, and where they overlap. Where does the windowing system start and end? Where should new protocols go? We also want to be smart in spec'ing out how the two mediums relate to each other, and making translations from one of the other safe and robust.

In addition to our regular comm tools of forges and merge requests, a natural venue for these kinds of discussions is the Linux App Summit, an event co-hosted by KDE and Gnome. LAS 2020 is just one month away. Perhaps it's a good chance for a sit-down about these things.