Does Plasma require XWayland?

Does Plasma have a dependency on XWayland?

I have been troubleshooting certain issues on development-version Plasma. These issues didn’t affect Debian’s Plasma packages; this is apparently because Debian’s kwin-wayland package has a dependency on xwayland. Contrarily, installing development Plasma doesn’t require installing XWayland.

If it is intended to be possible to run Plasma without XWayland, I intend to file a bug report regarding my issues.

KWin requires it at build time unless you explicitly disable it, yes. See CMakeLists.txt · master · Plasma / KWin · GitLab

What might be happening is that kde-builder might not be pulling xwayland dev libs for your distro (Debian?). I see it for Fedora and Arch in xwayland path:distro-dependencies · Search · GitLab

I doubt the problem is with libraries, because KWin builds fine. Yet, you are right that on Debian, kde-builder installs no XWayland dependencies, but xorg-x11-server-Xwayland is required on Fedora.

Are you sure that Fedora’s xorg-x11-server-Xwayland contains libraries? Debian’s xwayland package only contains a single executable.

It seems that it’s a packaging decision to force the install of Xwayland on Fedora.

I’m guessing that this is on the assumption that most users get a better experience with it install as there are apps that only support X11 that are important still.

You can stop Xwayland from starting up by adding an override to the like this:

# /home/barry/.config/systemd/user/plasma-kwin_wayland.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/kwin_wayland_wrapper

Actually I was looking at the wrong place, the right ones are the ini files… :sweat_smile:

Okay, TIL that XWayland is just a binary, it doesn’t provide any accompanying libraries and KWin just checks if the binary exists. repo-metadata/distro-dependencies is probably pulling it implicitly via another dependency.

It should, it’s just finding the binary instead (which you are very likely to have on your system).

No, XWayland isn’t installed; apt list --installed | grep -i xway doesn’t output anything. (The development Plasma installation is on a virtual machine, which is based on an image I downloaded from Debian’s website. I have already reported some issues that arose from repo-metadata leaving out dependencies which are commonly pre-installed, but weren’t present on the VM.)

I found something interesting – CMakeLists.txt for KWin contains the following:

    find_package(Xwayland 23.1.0)
    set_package_properties(Xwayland PROPERTIES
        URL "https://x.org"
        DESCRIPTION "Xwayland X server"
        TYPE RUNTIME
        PURPOSE "Needed for running kwin_wayland"
    )

So, maybe repo-metadata/distro-dependencies should be modified to list XWayland as a dependency?

I activated a dropdown selector on the login screen to switch between wayland and X11, so wayland isnt’t neccessarily required. Some apps might not work without wayland though.

The OP wants wayland but not the X11 Wayland server, Xwayland which is not what you get when you choose X11 as a login option. Further that option is going way in 6.8.

Thanks for clarifying!

Probably so others don’t experience the problems you had, yeah. But…

I just noticed that the find_package() call does not use REQUIRED, and you said above that KWin builds fine without the xwayland binary (a.k.a. it passes the KWIN_BUILD_X11=ON check).

A bug report to KWin detailing the specific issues you’ve had without XWayland makes sense since apparently XWayland is not a hard requirement for KWin like I previously thought.

Thanks for advice, I reported the bug:

I wonder if there is a systemd sock activation unit for Xwayland that needs removing?

(I went to check the bug but the kde bugtracker is down)

It could also be that kwin_wayland binds the Xserver socket but only launches XWayland on demand.

In this case the X11 client would be able to initiate the connect but KWin can’t start XWayland and hand over the socket for actual connection processing.

At least then kwin_wayland does not have the --xwayland option it does not bind the socket.

True but I would assume this to be the default in most setups.

There might be no check in KWin that verifies the XWayland executable can be found before doing the bind.

And/or missing close/unbind when the on-demand launch attempt failed.

Anyway, I was just adding that additional to systemd socket activation another thing to consider would be potential similar code in KWin itself.