Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[FAILED] How do I install KDE without Wayland?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
Athenian200
n00b
n00b


Joined: 27 Nov 2005
Posts: 18
Location: Dallas, TX USA

PostPosted: Sun May 29, 2016 7:59 am    Post subject: [FAILED] How do I install KDE without Wayland? Reply with quote

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.


Last edited by Athenian200 on Sun May 29, 2016 10:28 am; edited 1 time in total
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6831
Location: Austria

PostPosted: Sun May 29, 2016 8:27 am    Post subject: Reply with quote

Yes, it is required, no that makes it no Frankenstein system. Kwayland is already in use even in an X session.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Athenian200
n00b
n00b


Joined: 27 Nov 2005
Posts: 18
Location: Dallas, TX USA

PostPosted: Sun May 29, 2016 8:32 am    Post subject: Reply with quote

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


Well, I don't want KWayland either. I don't have that installed and I have no intention of installing it. I don't have any need to run Wayland applications. I really have no interest at all in running Wayland on top of an X session, and I don't think very highly of developers who write their applications that way.

I disagree respectfully about it not being a frankensystem. I don't want pieces of Wayland being installed on my system, so I just won't use it then.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6276

PostPosted: Sun May 29, 2016 8:58 am    Post subject: Reply with quote

Slightly OT: To find out whether it is really needed or somehow optional, you can use the command
Code:
eix -vle kscreenlocker
Obviously dev-libs/wayland and kde-frameworks/kwayland appear unconditionally (not within an ||-clause or after a conditional "use?") in RDEPEND and thus are hard requirements at least in the opinion of the ebuild author.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6831
Location: Austria

PostPosted: Sun May 29, 2016 9:20 am    Post subject: Reply with quote

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


Well, I don't want KWayland either. I don't have that installed and I have no intention of installing it. I don't have any need to run Wayland applications. I really have no interest at all in running Wayland on top of an X session, and I don't think very highly of developers who write their applications that way.

I disagree respectfully about it not being a frankensystem. I don't want pieces of Wayland being installed on my system, so I just won't use it then.

It's not for Wayland applications, and it won't 'run'* Wayland actually, kwayland is used internally by some plasma components, iirc to not rely on insecure X mechanisms.

*One does not run Wayland in the way you run X, anyway.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3648
Location: Hamburg

PostPosted: Sun May 29, 2016 9:23 am    Post subject: Reply with quote

You can login into KDE using "plasma" or using "plasma/wayland" (among 3 other wm) - I choosed the first (palsma/wayland never works BTW).
Back to top
View user's profile Send private message
Athenian200
n00b
n00b


Joined: 27 Nov 2005
Posts: 18
Location: Dallas, TX USA

PostPosted: Sun May 29, 2016 9:55 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6831
Location: Austria

PostPosted: Sun May 29, 2016 10:38 am    Post subject: Reply with quote

Of all the problems that exist for some people with Plasma-5, though, none are related to KWayland.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Athenian200
n00b
n00b


Joined: 27 Nov 2005
Posts: 18
Location: Dallas, TX USA

PostPosted: Fri Jun 03, 2016 2:52 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6831
Location: Austria

PostPosted: Fri Jun 03, 2016 6:11 am    Post subject: Reply with quote

Except there is no wayland server.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Athenian200
n00b
n00b


Joined: 27 Nov 2005
Posts: 18
Location: Dallas, TX USA

PostPosted: Sat Jun 04, 2016 3:52 am    Post subject: Reply with quote

genstorm wrote:
Except there is no wayland server.


Well, I know for a fact that there are Wayland clients that communicate over the Wayland protocol. I know that KWin can function as a Wayland compositor, and that KWayland implements a client-side Wayland protocol. I know, I know... Wayland clients talk to a compositor directly.

I'm so used to working with X and talking about things in terms of clients and servers, that I probably meant to say Wayland compositor rather than Wayland server. I misspoke. My point was that X already has its own compositing mechanism, so having a separate Wayland compositor that operates independently of whatever X is using for that function seems like something that would add overhead. Sure, it makes things more secure, but it seems like it would eat more RAM or be slower than using the compositor that's already available and loaded up.

Unless the point all along has been that the Wayland protocol can speak directly to the exact same compositor that X uses while bypassing the X server that's also using that compositor? If that's the case, then there aren't two compositors, and there aren't two servers... there's just another protocol (Wayland) that talks to the compositor directly, while the X server also talks to that same compositor.

I understand X pretty well because I've used it for years. I'm not used to dealing with Wayland or talking about it intelligently.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum