I'm a longtime X user, and I specifically don't want Wayland libraries or methods used on my computer.

Most KDE components that don't require KWin seem to work fine without Wayland, and the main reason KWin seems to require it is because of something called KScreenlocker.

I don't even need a screen locker on this particular system, so... is there any way to get around the KWayland/KScreenlocker related dependencies? I don't need/want to run any Wayland applications, so it seems superfluous to me.

The people who created the Gentoo ebuild I'm using couldn't think of a way around it, but I wanted to make absolutely sure that it's a requirement that can't be configured or patched around easily before I give up.

It looks like KDE is so tightly integrated with Wayland now that if I don't trust Wayland yet, then I'll have to wait until it's more mature to use KDE. Some developers have made it very clear that they don't want to support anyone who wants to use KDE without KWayland.

I managed to trace the Wayland dependency to the Greeter submodule in KScreenLocker. It wasn't easy because I've only had one C++ class in my entire life and had to look a lot of things up. There's no alternative code path that it uses on X11, it uses KWayland acting as a KWayland client, and hence the Wayland protocol/library, even on X. Which is exactly what I'm uncomfortable with and won't accept. Unfortunately, this means that it will be harder than just ripping out the Wayland specific code or telling it not to build Wayland-related targets in the CMakeFiles. If I did that, there would be no Greeter and thus the package wouldn't do anything useful.

At this point, I'm not expecting to get this working overnight, and I understand that I'll be doing this on my own. I'm now wondering about substituting XScreenSaver for KScreenlocker. KDE is supposed to be modular... so maybe I can find a way to "trick" KWin into accepting XScreenSaver as a substitute for KScreenLocker? I'm expecting to find a few more Wayland-related "gotchas" though. So I might end up spending a few months thinking up workarounds for the problem, and it will probably never work in any version of KDE newer than the one I'm playing around with as they plan to make more Wayland/KWayland dependencies on X. I don't have anything better to do until class starts back, though, and I've put so much effort into this already. If I figure it out, I'll post again.

I just thought people should know that by default, it's not possible and not supported, so if you want this functionality, you'll have to seek out or work on some unofficial patches, and essentially work at cross-purposes with the KDE developers. LOL.

Bug report - Bug 361954 - Make kwayland backend optional : https://bugs.kde.org/show_bug.cgi?id=361954
Review Request #128073 - Make Wayland optional: https://git.reviewboard.kde.org/r/128073/

Thanks for the info, but It doesn't help at all with KWin, though. Those bugs are about LibKScreen, which already has an unofficial patch floating around.

Well, I ended up talking to someone about the issue. They haven't put X on the back burner quite yet. It seems that Wayland being used for IPC is actually faster even on X based systems. I thought that this was going to be one of those things that made KDE work faster on Wayland, but slower on X11. Apparently it's a benefit for everyone. They did benchmarks, and they had X11 and DBus for IPC at one point. So what I'm trying to do has already been done before in the past, and putting it back the way it was it won't make anything work better than it already does.

Most applications don't support multiple backends properly, and if you build in support for something you don't plan to use, you invite problems and risk segfaults occurring when the application tries to use something you don't have setup properly, instead of the thing you DO have setup properly. Like Alsa or PulseAudio, GStreamer or QtMultimedia, etc. KDE is very different. Apparently it can be built with every backend it supports and sort out which one it needs at runtime without actually breaking anything.

I would suggest that unless you're on something like Solaris or AIX where Wayland cannot be built at all, there's no advantage to building it without Wayland support. Most people would just take that at face value without needing to know why there's no advantage, but I had to learn it the hard way and see all the diagrams and benchmarks. I'm not sure if that means I'm too stupid for my own good, or too smart for my own good.