KDE Plasma 6.8 Drops X11: Switch to Wayland and Keep X11 Apps

KDE Plasma 6.8 means your next login is a Wayland session, whether you planned the move or not. Plasma 6.8 shipped on 14 October 2026 without the Plasma X11 session, and on Arch the upgrade deletes the plasmax11 session file once you accept one package conflict. Your X11 apps keep running through XWayland. What sat around them is another matter: an autologin entry that names the old session, and login scripts built on xrandr, setxkbmap, xdotool or xclip.

Original content from computingforgeeks.com - post 176602

This guide takes you from a Plasma 6.7 X11 desktop to a working Plasma 6.8 Wayland setup on Arch Linux, where 6.8 arrived first: the pacman prompt, the login screen fix, what replaces each X11 tool, and the settings that control X11 apps. Other distros reach this later, and KDE supports the 6.7 X11 session into early 2027. I tested every step on Arch Linux in October 2026, upgrading a real Plasma 6.7.5 X11 session to 6.8.1, so every prompt and error below comes from that machine.

Check whether you’re still on X11

If XDG_SESSION_TYPE prints x11, the upgrade changes your next login, so check it before you touch pacman. Open Konsole in your normal desktop session, not over SSH, because an SSH login is its own session and reports tty:

echo "$XDG_SESSION_TYPE"
loginctl show-session "$XDG_SESSION_ID" -p Type -p Desktop

On the test machine both commands agreed that Plasma was running on X11:

x11
Desktop=KDE
Type=x11

That is the Plasma 6.7 X11 desktop we upgraded. The screenshot below was taken before the upgrade, with the session type, the Plasma and KWin versions and the output of a typical X11 login script on screen. Keep a picture like this of your own setup, because once the session file is gone you can’t log back in to check what it did:

The session files tell you what the login screen can offer. Before the upgrade there are two, one for each display server:

ls /usr/share/xsessions/ /usr/share/wayland-sessions/

plasmax11.desktop is the entry that disappears in Plasma 6.8:

/usr/share/wayland-sessions/:
plasma.desktop

/usr/share/xsessions/:
plasmax11.desktop

A few checks in this guide use small tools that a Plasma install doesn’t always include. They’re all in Arch’s extra repository, and --needed skips any you already have:

sudo pacman -S --needed wev xclip xdotool xorg-xlsclients xorg-xeyes wl-clipboard

Before you upgrade, take five minutes to list what your X11 session does for you, because each item needs a Wayland answer and the rest of this guide follows the same order:

• You know whether your display manager logs you in automatically, and which session it names.
• You’ve found every login script or autostart entry that calls xrandr or setxkbmap.
• You know which of your scripts drive other windows or the clipboard with xdotool or xclip.
• You’ve noted any X11 app that relies on global shortcuts, such as a push-to-talk key.

If none of those apply to you, the upgrade is mostly a reboot, and you can stop after the next two sections.

Upgrade to Plasma 6.8 and accept the X11 session removal

Arch’s Plasma 6.8 plasma-workspace declares a conflict with plasma-x11-session, so pacman stops and asks before it removes the X11 session. The default answer is No. That matters if you update with --noconfirm or from a script, because the whole upgrade then fails instead of going ahead:

:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
:: plasma-workspace-6.8.1-1 and plasma-x11-session-6.7.5-3 are in conflict. Remove plasma-x11-session? [y/N] error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: plasma-workspace-6.8.1-1 and plasma-x11-session-6.7.5-3 are in conflict

Nothing was changed when that error printed, so it is safe to retry. If you use an AUR helper or a cron job that passes --noconfirm, run this one upgrade by hand so you can answer the question yourself. Do it from a text console (Ctrl+Alt+F3) rather than from Konsole on the X11 desktop, because the upgrade replaces the files of the window manager you’re running on, and if it crashes halfway it can’t restart:

sudo pacman -Syu

Answer y at the conflict prompt, then again at the usual “Proceed with installation” question. On the test machine that was 96 packages and about 256 MiB to download:

:: plasma-workspace-6.8.1-1 and plasma-x11-session-6.7.5-3 are in conflict. Remove plasma-x11-session? [y/N] y

When pacman finishes, plasma.desktop is the only Plasma session left. If you installed Plasma through plasma-meta, the upgrade also pulls in plasma-login-manager, because plasma-meta now depends on it, but Arch doesn’t enable services on install, so SDDM keeps running until you switch yourself. One package doesn’t go with it, though. kwin-x11, the X11 window manager, has no conflict declared against it, and it isn’t in the repositories any more, so pacman leaves the old build installed as a foreign package. List foreign packages to see it:

pacman -Qm

The leftover shows up with its 6.7 version:

kwin-x11 6.7.5-3

It is dead weight. The 6.7 binary was built against libraries that 6.8 replaced, so it will not even print its version, let alone start a desktop:

kwin_x11: symbol lookup error: /usr/lib/libkwin-x11.so.6: undefined symbol: _ZN12ScreenLocker7KSldApp4lockENS_13EstablishLockEi

Remove it. Pacman also takes qt6-sensors, which nothing else on a Plasma 6.8 desktop needed here, and frees about 27 MiB:

sudo pacman -Rns kwin-x11

Reboot once the upgrade and the clean-up are done. After that reboot, you should be able to tick off each of these before you move on:

• You land in a Plasma session where echo "$XDG_SESSION_TYPE" prints wayland.
• You get an empty result from pacman -Qm for anything named kwin or plasma.
• You see only plasma.desktop when you list /usr/share/wayland-sessions/, and /usr/share/xsessions/ is gone, unless another X11 desktop such as Xfce or i3 still puts a session there.

If the first one fails because the machine stopped at a login screen instead of your desktop, that is the autologin problem in the next section, and it is the one most people hit first.

Fix SDDM autologin after the X11 session is gone

If SDDM logged you in automatically into Plasma (X11), the first boot on 6.8 stops at the login screen instead of your desktop. SDDM still looks for the session it was told to start, can’t find it, and gives up on autologin. The journal says so plainly:

journalctl -b -u sddm | grep -i autologin

These two lines are the whole story:

Oct 21 21:28:50 lorna-laptop sddm[608]: Unable to find autologin session entry "plasmax11"
Oct 21 21:28:50 lorna-laptop sddm[608]: Autologin failed!

The greeter you land on has Plasma (Wayland) already selected in its session list, because it is the only entry left. If you type your password, you are in. That is normal, and it is also why people who do not use autologin often notice nothing at all on their first boot, while the autologin crowd gets a login screen they have not seen in years:

To get autologin back, point SDDM at the Wayland session. Find the file that sets the session name first, since distros and installers name it differently:

grep -rs '^Session=' /etc/sddm.conf /etc/sddm.conf.d/

Here the setting lived in a drop-in file:

/etc/sddm.conf.d/autologin.conf:Session=plasmax11

If you turned autologin on in System Settings, look for /etc/sddm.conf.d/kde_settings.conf instead, and the value may carry the extension, as in Session=plasmax11.desktop. Both forms point to the same session. This sed rewrites either one to plasma, the Wayland session, in every file the grep finds, so you don’t need to type the path:

sudo sed -i 's/^Session=plasmax11\(\.desktop\)\?$/Session=plasma/' $(grep -rls '^Session=plasmax11' /etc/sddm.conf /etc/sddm.conf.d/)

Run the grep again and every line should end in Session=plasma; I checked the command against both file styles. Reboot rather than restarting sddm from a desktop session, because restarting the display manager kills the session you are typing in, along with anything unsaved. After the reboot, autologin brought the test machine straight to a Wayland desktop with no greeter in between.

Move the login screen to Plasma Login Manager

You don’t have to replace SDDM, because it still worked with Plasma 6.8 on the test machine. Its greeter, though, runs on Xorg by default: while the SDDM login screen was up, loginctl reported the greeter session as Type=x11, and Arch’s sddm package depends on xorg-server. Plasma Login Manager is KDE’s replacement, forked from SDDM, and Arch’s plasma-meta now depends on it rather than on SDDM. Its greeter runs on kwin_wayland, which is what lets you drop the Xorg server later. Switching makes sense when these are true for you:

• You want the login screen on Wayland like the rest of the desktop.
• You plan to remove the Xorg server, which the next section does.
• You can set up autologin again in a new settings page if you use it.

If none of that matters to you, SDDM is fine and you can skip to the script fixes further down.

Install it, then swap the service that starts the display manager:

sudo pacman -S plasma-login-manager
sudo systemctl disable sddm
sudo systemctl enable plasmalogin

The disable and enable steps move the display-manager.service link from SDDM to the new service:

Removed '/etc/systemd/system/display-manager.service'.
Created symlink '/etc/systemd/system/display-manager.service' → '/usr/lib/systemd/system/plasmalogin.service'.

Keep SDDM installed until Plasma Login Manager has brought you to a desktop at least once. If the screen stays black after the reboot, switch to a text console with Ctrl+Alt+F3, log in, and put SDDM back with sudo systemctl disable plasmalogin followed by sudo systemctl enable sddm and a reboot.

After a reboot you get a lock-screen style clock first. Press any key, and the user list and password field appear. Press Backspace if that first key landed in the password field. While this greeter was up, its session reported Type=wayland, and there was no Xorg process on the machine:

Logging in through it gave a normal Plasma Wayland session, with Service=plasmalogin in loginctl. Your old SDDM autologin file isn’t used, though: /etc/sddm.conf.d/autologin.conf still named the Wayland session, and Plasma Login Manager showed its greeter anyway. It reads /etc/plasmalogin.conf instead, with the same [Autologin] keys, and the Login Screen page under Security & Privacy in System Settings edits it for you. To set it by hand on a fresh install, write the file with your own username. This replaces the whole file, so if it already exists, add the three lines with an editor instead:

printf '[Autologin]\nUser=%s\nSession=plasma\n' "$USER" | sudo tee /etc/plasmalogin.conf

After the next reboot the test machine went straight to the desktop, and loginctl showed the session as Service=plasmalogin-autologin with Type=wayland.

Remove the Xorg server you no longer need

Do this only after Plasma Login Manager has logged you in at least once, because removing SDDM takes away your fallback. On the test machine SDDM was the only thing holding xorg-server. Removing SDDM with its unneeded dependencies takes the Xorg server with it, plus two smaller packages you should look at before you say yes:

sudo pacman -Rns sddm sddm-kcm

Pacman prints a warning about OpenSSH before the package list:

:: openssh optionally requires xorg-xauth: X11 forwarding
Packages (5) xf86-input-libinput-1.5.0-1  xorg-server-21.1.25-2  xorg-xauth-1.1.5-1  sddm-0.21.0-7  sddm-kcm-6.8.1-1

Total Removed Size:  9.96 MiB

xorg-xauth is the one to watch. If you ever run ssh -X into this machine to display a remote app, X11 forwarding needs it on this end. Put it back, marked as explicitly installed so the next cleanup leaves it alone:

sudo pacman -S xorg-xauth

That only happens if xorg-server came in as a dependency. If you installed it yourself, or the whole xorg group, for the old X11 session, it stays. Check how it got there:

pacman -Qi xorg-server | grep -E 'Install Reason|Required By'

If it says Explicitly installed and Required By is None, nothing needs it any more and sudo pacman -Rns xorg-server removes it. Don’t remove xorg-xwayland. That package is XWayland itself, the X server that runs inside your Wayland session for X11 apps, and it’s separate from xorg-server. With the Xorg server gone, xeyes still opened normally, and xlsclients listed it as the one X11 client on the desktop:

Konsole doesn’t appear in that xlsclients output, because it’s a native Wayland app. That split, X11 apps on XWayland and everything else talking Wayland directly, is the reason the scripts in the next section stop working.

Replace xrandr and setxkbmap in your login scripts

Under Plasma Wayland, xrandr and setxkbmap talk to XWayland, not to your screens or to KWin. The part that trips people up is that they don’t fail loudly. The test machine’s X11 login script set the screen mode and mapped Caps Lock to Escape, and on the first Wayland login it wrote this to its log:

== 2026-10-21T21:29:16+00:00 XDG_SESSION_TYPE=wayland DISPLAY=:1 WAYLAND_DISPLAY=wayland-1
WARNING: running xrandr against an Xwayland server. See the xrandr man page for details.
xrandr output: Virtual-1
WARNING: running xrandr against an Xwayland server. See the xrandr man page for details.
xrandr rc=0
WARNING: Running setxkbmap against an Xwayland server
setxkbmap rc=0
WARNING: Running setxkbmap against an Xwayland server
options:    caps:escape

Both commands exited 0, so a script that checks return codes thinks everything worked. The xrandr call only succeeded because the screen was already at the mode it asked for. Asking XWayland for a real change fails:

xrandr --output Virtual-1 --mode 1280x720

XWayland refuses to resize the screen and the command exits 1:

WARNING: running xrandr against an Xwayland server. See the xrandr man page for details.
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Serial number of failed request:  22
  Current serial number in output stream:  23

The keyboard option is quieter still. setxkbmap -query reported caps:escape, but a native Wayland app never saw it. Pressing Caps Lock in wev, a small Wayland event viewer, still produced sym: Caps_Lock. The table lists what replaces each tool and how each replacement behaved on the same machine:

X11 tool	Plasma Wayland replacement	What happened in the test
xrandr (mode, scale)	kscreenctl, new in Plasma 6.8 (kscreen-doctor still works)	Mode and scale changed on the real output
setxkbmap -option	Options= in ~/.config/kxkbrc, or System Settings, Keyboard	Applied after logging out and back in
xdotool	ydotool	Typed into a native Wayland Konsole once the user was in the input group
xclip	wl-copy and wl-paste	Read and wrote the Wayland clipboard; xclip could not read it

Set the screen mode and scale with kscreenctl

kscreenctl works on connector names, so start by listing the outputs that are switched on. On a laptop you’ll see something like eDP-1, and on a desktop DP-1 or HDMI-A-1:

kscreenctl list-outputs --enabled --names

The test VM has a single output:

Virtual-1

Store the name in a variable so the next commands work as written on your machine, then list the modes it accepts:

OUT=$(kscreenctl list-outputs --enabled --names | head -1)
kscreenctl "$OUT" list-modes

Each mode carries an index and an exact refresh rate. The * marks the current mode and the ! marks the one the monitor prefers. The list is sorted by index as text, so 10 to 19 come before 2:

1:[email protected]!
10:[email protected]
11:[email protected]*
12:[email protected]
13:[email protected]
14:[email protected]
15:[email protected]
16:[email protected]
17:[email protected]
18:[email protected]
19:[email protected]
2:[email protected]
20:[email protected]
21:[email protected]
22:[email protected]
23:[email protected]
24:[email protected]
3:[email protected]
4:[email protected]
5:[email protected]
6:[email protected]
7:[email protected]
8:[email protected]
9:[email protected]

set-mode takes the index, the mode as listed, or just the resolution, which picks the highest refresh rate for that size. A rate you add yourself has to be within 0.01 Hz of the real one. 1920x1080@60 worked here because that mode is 60.00 Hz, but 1280x1024@60 printed Unknown mode: 1280x1024@60 and exited 1, because that mode is 60.02 Hz. Plain 1280x1024 switched the screen. When in doubt, drop the rate or use the index. Scale takes a percentage:

kscreenctl "$OUT" set-mode 11
kscreenctl "$OUT" set-scale 100%

You may need set-scale sooner than you think. The X11 session on the test machine ran at 100%, but the first Wayland login picked 135% on its own for this 1920×1080 output, which reports a 325 mm wide panel, so the desktop’s logical size dropped to 1423×800. If everything looks bigger after the upgrade, that’s why, and set-scale or the Scale slider in Display Configuration puts it back.

Set keyboard options in kxkbrc

KWin reads keyboard options from kxkbrc, which is the file the Keyboard page in System Settings writes. Set the same option your setxkbmap line used, with kwriteconfig6:

kwriteconfig6 --file kxkbrc --group Layout --key ResetOldOptions true
kwriteconfig6 --file kxkbrc --group Layout --key Options caps:escape
cat ~/.config/kxkbrc

The file should now carry both keys:

[Layout]
Options=caps:escape
ResetOldOptions=true

Log out and back in. I also tried sending KWin the org.kde.keyboard.reloadConfig D-Bus signal to apply it live, and Caps Lock was still Caps Lock afterwards, so don’t rely on that. After a fresh login, the same Caps Lock press in wev -f wl_keyboard:key arrived as Escape:

                      sym: Escape       (65307), utf8: '\e'

Unlike the X11 setting, this one sticks across logins and reboots. You only set it once, so it does not belong in a login script, and if you prefer clicking, the Key Bindings button at the top of the Keyboard page in System Settings writes the same file.

Run display commands at login

Plasma remembers the mode and scale you pick for each output, so most people don’t need a login script at all. If you do want one, for a docking setup or a kiosk, the script below is the one that replaced the X11 version on the test machine, and it writes a log so you can see whether it ran. Create it in your home directory:

mkdir -p ~/bin ~/.config/autostart
vim ~/bin/display-setup.sh

Paste this in, swapping [email protected] for a mode string from your own list-modes output:

#!/bin/bash
exec >>"$HOME/display-setup.log" 2>&1
echo "== $(date -Is) XDG_SESSION_TYPE=$XDG_SESSION_TYPE"
out=$(kscreenctl list-outputs --enabled --names | head -1)
echo "output: $out"
kscreenctl "$out" set-mode [email protected]; echo "set-mode rc=$?"
kscreenctl "$out" set-scale 100%; echo "set-scale rc=$?"

Make it executable and open an autostart entry for it:

chmod +x ~/bin/display-setup.sh
vim ~/.config/autostart/display-setup.desktop

Add these lines, using your own username in the Exec path:

[Desktop Entry]
Type=Application
Name=Display setup
Exec=/home/lorna/bin/display-setup.sh

To test it, I set the screen to 1280×1024 at 135% and logged out. On the next login the script put it back to 1920×1080 at 100%, and its log showed both calls succeeding:

== 2026-10-21T21:41:53+00:00 XDG_SESSION_TYPE=wayland
output: Virtual-1
set-mode rc=0
set-scale rc=0

Delete the old X11 entry from ~/.config/autostart/ at the same time. It does no harm under Wayland, but it’s confusing to find later.

Swap xdotool and xclip for Wayland tools

xdotool only sees X11 windows, so on a Plasma Wayland desktop it is blind to most of what is open. With Konsole open on screen, xdotool search --name Konsole found nothing and exited 1. Even windowactivate on an XWayland window hung until my 8-second timeout killed it. ydotool works at a lower level: it creates a virtual input device through /dev/uinput, so its key presses and mouse moves reach any window, native or not.

Arch packages it with a user service. Install it and enable the service:

sudo pacman -S ydotool
systemctl --user enable --now ydotool.service

Check it with systemctl --user status ydotool. If it reports active (running), skip ahead to typing. On a fresh Arch install it most likely won’t be, for the reason below.

Error: “failed to open uinput device: Permission denied”

The service failed straight away and hit systemd’s restart limit. Its journal, from journalctl --user -u ydotool -b, explained why:

ydotoold[2396]: failed to open uinput device: Permission denied
ydotoold[2396]: You're advised to run this program as root, or YMMV.

/dev/uinput is owned by root:input with mode 0660, and a normal Arch user isn’t in the input group. Adding yourself fixes it, but know what you’re granting: the same group can read /dev/input/event*, which means every keystroke on the machine. On a single-user desktop that’s usually an acceptable trade. On a shared machine, don’t do it:

sudo usermod -aG input "$USER"

Log out completely, or reboot, so that both your session and your systemd user manager pick up the new group. After that, systemctl --user is-active ydotool printed active, and a typed command landed in Konsole. ydotool key 28:1 28:0 is a press and release of Enter, using Linux key code 28:

ydotool type 'echo typed-by-ydotool on $XDG_SESSION_TYPE'
ydotool key 28:1 28:0

The focused Konsole window ran the typed command:

ydotool can’t search for windows by name the way xdotool can, so a script that found a window and then typed into it needs rethinking. It types wherever the focus already is. For window search, KDE’s own Wayland FAQ points to kdotool, which works through KWin scripting. It’s in the AUR rather than the official repositories, and I didn’t test it here.

Use wl-copy and wl-paste for the clipboard

The clipboard crossed from XWayland to Wayland, but not the other way in a script. Text copied with xclip came out of wl-paste fine, while text copied with wl-copy wasn’t there for xclip to read:

echo from-wayland | wl-copy
xclip -o -selection clipboard

xclip came back empty-handed and exited 1:

Error: target STRING not available

That is deliberate on KWin’s part, not a bug. When a Wayland app owns the clipboard, KWin lets an X11 client read it only while that X11 window has focus, so pasting by hand into an X11 app still works. What breaks is a background script, which never has focus. Switch scripts to wl-copy and wl-paste from the wl-clipboard package. They read and write the clipboard your Wayland apps use, which on Plasma 6.8 is nearly all of them.

Tune how X11 apps behave on XWayland

Two settings pages decide how X11 apps fit into a Wayland desktop, and both are worth a look on the day you upgrade. The first controls what X11 apps can hear from your keyboard. On X11 any app could read every key you pressed, which is how global shortcuts in older apps worked. Under Wayland, KWin passes keys to X11 apps only within the limit you set here. Open it directly from Konsole:

systemsettings kcm_kwinxwayland

The default is the third option: X11 apps see presses of Meta, Control, Alt and Shift on their own, plus any key pressed while Control, Alt or Meta is held, which covers most global shortcuts. Mouse buttons are off by default:

A push-to-talk key in an X11 voice chat app is the usual casualty. A modifier such as Right Ctrl already works on the default. A plain key such as ` needs “Always allowed”, which also hands every keystroke to every X11 app, passwords included. If your push-to-talk is a mouse button, tick Allowed under “Listening for mouse buttons” instead, which is the smaller grant. Pick the least you need.

The second page is Display Configuration, which holds the Legacy applications (X11) scaling choice next to the Scale slider:

systemsettings kcm_kscreen

At 100% the choice doesn’t matter, so the screenshot shows the default, “Apply scaling themselves”:

It starts to matter at a fractional scale like the 135% Plasma picked on its own. With “Apply scaling themselves”, X11 apps get the full resolution and stay sharp, but an app that doesn’t scale its own interface comes out small. “Scaled by the system” has KWin stretch them to the right size instead, which can look soft. Try your X11 apps both ways and keep whichever you can live with.

Common misconceptions about the X11 removal

Most of the worry around this release comes from three beliefs that the test machine didn’t bear out.

“My X11 apps will stop working”

They won’t. What KDE removed is the Plasma X11 session, meaning the option to run the whole desktop on an X server. xeyes ran on a machine with no xorg-server package installed at all, because XWayland ships separately. KDE’s Wayland FAQ says X11 forwarding keeps working through XWayland too, and on Arch the machine you connect to still needs xorg-xauth for it, as pacman’s removal note showed. The Plasma 6.8 announcement says the same about X11 apps, and adds that KDE applications will keep supporting X11 for the foreseeable future, so apps like Dolphin and Konsole aren’t tied to the Wayland session either.

“I can keep the old X11 session by keeping kwin-x11”

Not once the rest of Plasma is on 6.8. The leftover 6.7 kwin_x11 on the test machine failed with a symbol lookup error before it could even print its version. If you truly need a Plasma X11 desktop for a while longer, KDE’s answer is a distro that stays on Plasma 6.7, since KDE supports the X11 session into early 2027 and is exploring extra 6.7 bugfix releases, or an LTS distro such as AlmaLinux 9, which keeps the X11 session until 2032. On Arch, holding every Plasma package back at 6.7 is a partial upgrade, which the distro doesn’t support. A better use of that time is the pacman cheat sheet section on downgrades, so you know your way back if 6.8 breaks something you depend on.

“Wayland means my scripts need root now”

Only ydotool needs extra access, and that is the input group, not root. Every other replacement in this guide ran as the normal user in the test. If you set up Plasma from scratch rather than upgrading, the archinstall walkthrough gets you to the same Wayland desktop. Other distros follow the same pattern, as the guides for KDE Plasma on Fedora and Plasma on Debian show. If you’re weighing whether Plasma is still the right desktop at all, our desktop environment RAM measurements compare it with the others on the same hardware.