Thinnest way to start KDE

[Goverp]

I've been trying to switch from X11 to Wayland, but (a) for some programs, notably zoom, I still need X11 (b) Wayland is still flaky in various ways, and (c) SDDM makes a right mess of starting as a new user.

SDDM and display managers in general seem a totally unnecessary software layer. There's a perfectly good linux logon mechanism without them, so I'm writing a trivial shell script to put at the end of .bashrc or similar, to start Wayland, X11 or character-mode terminal, depending on TTY number, so I can easily choose which to start.

There's an aesthetically displeasing asymmetry between the two: Wayland starts with simple

Code: Select all

exec dbus-launch --exit-with-session startplasma-wayland

but X11 needs a call to startx, and then as far as I can tell, the startup command hidden in .xinitrc

Code: Select all

#!/bin/sh
exec dbus-launch --exit-with-session startplasma-x11

I presume there's a suitable call to startx or xinit, but when I tried the simple

Code: Select all

exec startx dbus-launch --exit-with-session startplasma-X11

X started, then closed down again, all by itself, and only then plasma complained about the missing display.
What am I doing wrong?

[Zucca]

I don't quite remember how X startup process went as I haven't used X after sway beta hit the scene, but shouldn't the command be like this

Code: Select all

exec dbus-launch --exit-with-session startx startplasma-X11

?
Or even drop 'startx' altogether. 'startplasma-X11' could itself run startx or commands similar to it.

[GDH-gentoo]

There's an aesthetically displeasing asymmetry between the two:

AFAIK, that's because on X11, there's both the X server, Xorg, and the window manager, kwin_x11. startx (indirectly xinit) takes care of starting both the server and some client (startplasma-x11, and indirectly kwin_x11), and kills the former when the latter terminates. On Wayland, there's just the Wayland compositor, kwin_wayland.

I presume there's a suitable call to startx or xinit, but when I tried the simple

Code: Select all

exec startx dbus-launch --exit-with-session startplasma-x11

[...]
What am I doing wrong?

startx is a shell script, and, AFAICT, the first argument is taken as the client program only if it starts with '/' or './'. Otherwise, it is taken as the first argument of a call to xterm. Therefore, try:

Code: Select all

exec startx /usr/bin/dbus-launch --exit-with-session startplasma-x11

[Anon-E-moose]

startx ultimately winds up calling xinit, you just don't have to remember all the details (it does it for you)

BUT

this is the output from startx <--> xinit /home/user/.xinitrc -- /usr/bin/X :0

Where it calls your .xinitrc (if there is one, otherwise uses some default), then the server, display and any options.

For reference:
xinit [ [ client ] options ... ] [ -- [ server ] [ display ] options ... ]

the only other thing startx does is keep your .Xauthority file up to date

[Goverp]

Thanks for both bits of info. I've fixed the first problem with

Code: Select all

exec startx /usr/bin/dbus-launch ...

and note that the xinit documentation explains about the special handing of client names (eugh).
A quick try with

Code: Select all

exec xinit ...

failed, so I need to look at what startx is doing properly. Its comments say it's a mess and should be rewritten - always a good sign! I suspect the whole lot can be shrunk to a line or two for my use case.
Next is to check that KDE logoff/restart/sleep and so forth work satisfactorially, and setup some sensible logging (at least with timestamps, better with colour).
I noticed that exiting from wayland leaves a broken akonadi and crash, which worried me until I compared it with SDDM's wayland log (~/.local/share/sddm/...), which shows the same crash! More eugh.

[Zucca]

Out of curiosity: You specifically want a choice to start KDE with X11.
Is there still something in regular KDE usage that might need X11, or do you have some speciality software that doesn't work even with Xwayland?

[Anon-E-moose]

startx doesn't "exec" xinit it simply calls it, when it returns, startx finishes up and cleans up.
-----------
Startx looks for a the first display it can use (without the vt arg)
Does the xauth stuff (if needed)
-----------
# This is just a sample implementation of a slightly less primitive
# interface than xinit. It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default.

xinit "$client" $clientargs -- "$server" $display $serverargs
-----------
xinit needs at least the client (so it knows what to do)
AND the server (typically X) AND which display to use.

That's all there is to startx (lots of crap, but it really doesn't do much)

[Goverp]

Out of curiosity: You specifically want a choice to start KDE with X11.
Is there still something in regular KDE usage that might need X11, or do you have some speciality software that doesn't work even with Xwayland?

Se the first line of the first post in this thread. I could also have mentioned a firefox issue where background tabs monopolize a cpu, but that might? also occur with X11.

[Zucca]

Se the first line of the first post in this thread.

Oh. I think I'm going illiterate or blind. :P
Have you tried running zoom (for example) by unsetting WAYLAND_DISPLAY?

Code: Select all

env -u WAYLAND_DISPLAY /path/to/zoom.bin

I assume Zoom is an electron based program. Some of those electron projects are tricky to run on wayland, since the developer might stick with quite old version of electron while sill making updates to the program itself. These old versions of electron are the problem usually. And I think It's not trivial or even possible to unpack the program archive and repack it with newer version of electron.

• (Really electron should have been a library or runtime environment like java... That would end up Chrome being a dependency. :P But it's still better than old, vulnerable, skeleton of chrome?)

[Anon-E-moose]

I usually add this to my .desktop files (for those that need Xwayland instead of wayland)

For gtk apps

GDK_BACKEND=x11

for qt

QT_QPA_PLATFORM=xcb

This should override the selection of wayland backend.

I usually modify the .desktop file to something like
Exec=env GDK_BACKEND=x11 GDK_DPI_SCALE=1 <rest of line>
for my gtk apps

do the same thing for qt apps but use QT* env variables


Edit to add: If the screensharing is the problem with zoom, then xwayland might not fix it, you might need to start X only.

From the zoom site

Last Updated:

The screen sharing options in Wayland are currently limited. To share just a specific application, you need to launch your Linux session with Xorg instead. This is a known issue and will be fixed in a future Zoom client release.

Evidently screen sharing works (for the whole screen)