[FAILED] How do I install KDE without Wayland?

[Athenian200]

I've put "X -wayland" in my USE flags, and tried emerging kde-plasma/plasma-meta. I couldn't stop it from trying to emerge Wayland, so I went through the packages it was trying to install one by one.

The culprit appears to be KScreenlocker, which KWin seems to depend upon. Try as I might, I can't figure out how to get KScreenlocker to build without Wayland support.

I find the idea of having pieces of both X and Wayland on the same system to be "junky," and I really only want one or the other on a given system.

Is Wayland absolutely a hard dependency of KScreenlocker? I really don't need a screen locker on my system anyway, so failing removing the Wayland dependency, can I make KDE work without KScreenlocker? I'd kind of like to have KDE on my system, but I'm not sure I'm willing to be saddled with an X/Wayland Frankensystem in the process. :/

EDIT: Apparently the geniuses responsible for KDE decided to force Wayland on people who have no interest in using it. Now there's no way to do this without actually trying to patch it out.

[asturm]

Yes, it is required, no that makes it no Frankenstein system. Kwayland is already in use even in an X session.

[Athenian200]

[mv]

Slightly OT: To find out whether it is really needed or somehow optional, you can use the command

[asturm]

[toralf]

You can login into KDE using "plasma" or using "plasma/wayland" (among 3 other wm) - I choosed the first (palsma/wayland never works BTW).

[Athenian200]

Well, thanks for the tip, mv. I didn't have eix installed, so I'll look into getting that. Based on the information that KDE5 requires Wayland and won't work with just X anymore, I've decided that I don't want it on my system after all. I'll just install all the pieces of KDE that work without Wayland and see if I can find substitutes for the pieces that don't. It looks like all the important KDE applications/programs work fine without it, it's just the main desktop itself that has this weird dependency.

I never thought that "making KDE independent of X," meant making it depend on Wayland instead to the point that you now have to have Wayland methods going on top of X even if you use X. Wayland should really be optional...

I really think KDE might be great when they finish transitioning from X11 to Wayland... but until they do, I don't really want to use this weird messy compromise system they've made trying to get Wayland features without going whole hog. Plasma is obviously half-baked. It's had all sorts of odd problems when I used it on other distributions, was hoping I could remove the features causing issues on here. Oh, well.

[asturm]

Of all the problems that exist for some people with Plasma-5, though, none are related to KWayland.

[Athenian200]

Well, after some fairly extensive research into this, I learned the following:

1. KDE developers really, really don't like how Gentoo does things, and get more complaints on that platform than any other. They expect a distribution maintainer to compile everything on a build system and then separate everything into binary packages for end users. The way things are on Gentoo, everything KDE supports WILL be built and installed whether you need it or not. Which really wasn't the intention of the developers, and leaves the system in a configuration that's more suited for developing/packaging KDE than for just using KDE. There was a nice analogy to KDE's size and complexity making it more like a mass production line. You can't have as many configuration options when doing mass production as you can when you have a small custom-order shop.

2. X is such an inefficient IPC mechanism that there's no additional overhead to running a Wayland server in addition to the X server and routing IPC around X, even though it sounds like a terrible waste of a perfectly good X server conceptually. It is a frankensystem, but one that works better than using the X server natively. They explained that the pipeline through the X server is so long that going around it takes a shorter path to the underlying hardware even when it's already running. So I wouldn't get any performance benefit at all out of, say, paying someone to recode KDE so it uses X11 as an IPC mechanism. It would be the same or slower, with no real change in overhead. Apparently they tested performance back when it still used a different IPC mechanism and were as reluctant and skeptical as I am now until they saw the results themselves. I think I even got shown a diagram of abstractions between X and the hardware, and then between Wayland and the hardware showing that it shortens the pipeline even in my specific use case, along with an explanation of how lightweight the library and the protocol actually is. That "extra" KWayland server running alongside the X server takes about as much additional overhead as running an XTerm, and ends up paying for itself by reducing strain on the X server's slower pipeline that legacy applications rely upon.

3. The best argument for continuing to support X as an IPC mechanism is that Wayland doesn't always work properly on non-Linux platforms. But there's absolutely no reason for anyone using Linux to avoid Wayland.

Those KDE developers and maintainers will get very long-winded about this.

[asturm]

Except there is no wayland server.

[Athenian200]