When we first announced the transition to Plasma Wayland, one of Martin's slides from stated, "It's done when it's done!"
This is a companion discussion topic for the original entry at http://blog.davidedmundson.co.uk/blog/596/
When we first announced the transition to Plasma Wayland, one of Martin's slides from stated, "It's done when it's done!"
I’m glad that there is such strong progress on this. Hats off to all the devs.
I just have one issue with it, there is no headless remote access using Wayland, x11 is the only option.
I would love to switch over but I use my PC with my multiple screens to remote into my work laptop (with it’s one screen), and I can only use x11 for that.
Is there a solution to this coming up? I’m hoping I don’t have to stay on 6.7 indefinitely.
There is something coming out! It’s targeted for Plasma 6.8.
Its Plasma 6.8 still target for 2027 as promised?
Im still using X11 and i still rely on it, it is important for my Nvidia GPU and my Monitor because there is no Nvidia X-Server GPU Control’s available for Wayland.
When Wayland hit the market i’m forced to replace my GPU and or my Monitor.
Fake News. I see massive user’s still on X11 on many other Distro’s that data is pure propaganda.
Yes.
Well yeah, On Wayland there’s no X server. But the NVIDIA control panel software works fine on Wayland, or at least it’s supposed to. I don’t have an NVIDIA GPU, so I can’t personally verify that. But give it a try.
I gave it a try already, there is sadly absolute no option and no adjustment’s available in Nvidia X-Server Settings, the console is working and showing some minor GPU Info’s on Wayland but all the important stuff is complettly missing, absolute no adjustment are possible in Wayland with Nvidia GPU’s, GPU related bash scripts also no longer working for my Nvidia Card.
Im using Wayland on my AMD Laptop total fine, but for my PC it is a complet different story.
That you guys want to clean all X11 stuff from the Desktop Environment, is to early!
Im forced to buy new hardware when Plasma 6.8 rolled out in my Distro and i also asked in my Distro for assistant already… there is no way to use Wayland with my Monitor without the option to make adjustment, the whole screen has color grading issues and my Topic is unsolved till this day:
If that is the tool’s name then it will likely be an X11 application, which means on a Wayland session it will connect to the nested XWayland server.
Since that is not the main display server it will probably only expose interfaces that it can actually either handle internally (X server specific settings) or things that any Wayland client can ask the compositor to do.
Controlling GPU/driver settings will need a tool that actually talks to the driver.
This might originally have been integrated in to the X-Server tool but this part of the functionality might somehow assume things that are no longer true when used with XWayland.
The Nvidia will likely have a tool that is not tied to any specific display server and can directly talk to the GPU. Their chips are quite common for high end embedded systems which often don’t even run a display server as they only have a single application in control of the full screen.
At some point Nvidia might even fix their GUI tool to be able to talk to the driver when running on Wayland (directly or through XWayland).
The Nvidia settings app on Wayland can actually do this - you can still use it to set fan speeds and overclocking / undervolting.
What isn’t in the Wayland app (to my understanding) is the kind of display adjustments that can’t be done in a compositor-independent way on Wayland.
I would also expect it to be able to do things like gamma correction since even monitors can do that. Or enabling/disabling G-Sync.
Quite surprising!
Could be a limitation of their desktop stack and their embedded drivers/tools are more tailored for being display server agnostic since most of them don’t even run any.
Maybe their desktop setup still requires a hardware specific X11 backend rather than having a fully capable kernel driver the way Intel’ and AMD’s setup work.
Or their GUI tool needs some not-yet-ported user space component in order to make certain driver adjustments.
Sadly their settings tool is likely as closed source as their driver and nobody but them can investigate further, let alone address these shortcomings.
I have a question would an Electron application launched with --ozone-platform=x11 still run as an X11 client under XWayland, even though Plasma itself is running on Wayland after the X11 drop?
Yes.
The “X11 drop” is only for components of Plasma, e.g. the ability to run them as X11 clients.
For example when Plasma desktop shows the “Window overview” it has different means of communication with kwin_x11 and kwin_wayland. From 6.8 onwards only the latter.
The settings tool is open-source, but yeah, trace the breadcrumbs of the API calls and eventually you’ll get to something closed.
That said, Plasma on X11 offers gamma correction by writing to xorg config files, rather than leaving it to the Nvidia (or other vendor) app.
Quite interesting.
That would at least allow research into why certain settings are hidden/disabled and how they are, at least in principle, communicating with their driver.
A quick glance seems to indicate that they are actually not communicating with the driver much but mostly with some Nvidia specific X11 extension.
I am not really used to reading X11 code so I might be wrong but if they are indeed using some vendor specific extension then the tool wouldn’t even work on a regular X server and this fails on XWayland.
True, there will be limits on what others can do.
Right, this can probably be done on many levels.
Since it appears some monitors can do it regardless of graphics card, it should also be doable by the graphics card regardless of which software handles the output content.
The Wayland session is mostly functional with apps I happen to have, and very stable, even on an older version as a daily driver (Debian 13, Plasma 6.3 included, vintage ThinkCentre with Intel graphics) since December-ish.
Birdtray is working with XDG_SESSION_TYPE=x11 and Minimize to tray feature for arbitrary app is working for ad hoc traying of applications such as DeaDBeeF (since its own tray icon doesn’t work). Other than that the only real issue I’ve encountered in the wild is Drag and drop to folders pane causes freeze Linux Fedora 41 - XnView Software with drag-and-drop, XWayland not being a workable solution there because it interferes with window management (specifically, that kwin script). Keyboard shortcuts had to be recreated. Some timers needed tweaking. All-in-all, surprisingly friction free.
I suppose from a casual end-user perspective that’s several everyday use applications with breakage or features unavailable, which would makes Wayland still feel rather like a tech demo that doesn’t particularly add or solve things the end user cares about. But for someone who’s prepared to tinker, and appreciating that’s where development is at, it’s functional and will probably continue to be mid next year next distro update. The DE itself probably isn’t going to be the pain point for a lot of users.
My main daily driver is PCLOS Debian (“bookworm” based). They have adopted XLibre to replace X11 as an alternative to Wayland. Artix, Devuan and Q4OS are also going down this route (XLibre replacing X11).
I have also learned of a new DE, SonicDE:
Running MX Linux 25.2 here which is based on Debian Trixie (Plasma 6.3)… While I use Wayland as a daily driver and am overall content with it now thanks to the Plasma monitor system settings that replace the Nvidia settings program , I have to admit I really hope two issues will be solved before the alternative will be killed:
For VMWare, some guys found you can work around this with the help of the program status bar: Copy/Paste Broken - Wayland | VMware Workstation
Sadly I have no clue how to even find out the reason in order to tell the right people about this… I’d think XWayland should make sure such things do not happen for every GTK/QT/etc. version that is out in the wild, but I learned in the past others rather tend to reply they don’t care and the programs causing this need to be updated to the latest version of whatever libraries or frameworks they use… ![]()
Please scratch point two of my post above. Thanks to a hint in a post regarding VMWare I found the culprit - it is the libx11 that Debian Trixie provides. Updating that one (namely libx11-6, libx11-data libx11-dev and libx11-xcb1) to 2:1.8.13-1 from Debian Testing let the whole problem vanish ![]()