Trying to run KDE 6 Plasma with Wayland....

I tried with lightdm. It wasn't wanting to log in at all. I didn't try with .xinitrc script. But none of the Wayland launchers wanted to work with lightdm for some reason.
C'mon fellas, I do not use Wayland nor I'll want to, ever!
But, you'll need greeter .desktop file into ../lightdm/greeters with a X-LightDM-Session-Type=wayland line.

At least, that works for Linux folks.
Try it.
 
One way to work around this Ctrl-C bug has been described very well in this post:

Re-posting this here, because it's relevant.

Would be nice to see the SDDM bug resolved, rather than employ a hacky workaround. This being FreeBSD, however.... it would not surprise me to see those directions make their way into User Handbook at this point.
 
Based on comments I was seeing in the Bugzilla ticket that Andriy linked to, it looks like SDDM is a culprit in changing the keyboard mappings, which in turn messes things up in a KDE Wayland session.

And those comments are very recent - from the past week!

Good to know that x11/lightdm is a workable alternative when I do my next round of compiling my way into Plasma Wayland, I'll keep that in mind.

Hopefully this last mile will get covered before the December release of FreeBSD 15!
 
Interesting bit of info from SDDM's Github page:

Distributions without pam and systemd will need to put the "sddm" user into the "video" group, otherwise errors regarding GL and drm devices might be experienced.

If there is a special user sddm on a FreeBSD system, this might help things... This was not verified yet, would be nice if someone could verify that.
 
I was unable to get x11/lightdm working, either... even after doing some research.

I tried to use x11-wm/slim, but that was a no go, either.

Tried to do some research on what an alternative graphical greeter might be for KDE Wayland... by googling the term wayland-compatible greeters. And that last mile is probably the hardest one.

Long story short, we may be stuck with accepting Rust into this venture. That's because the vast majority of graphical greeters that I found - they are written primarily in Rust. There is quite a few of them. But most of them are NOT in FreeBSD ports, unfortunately. And virtually all of them are frontends to greetd - which is written in Rust. Well, greetd is basically a login manager / daemon that itself is a frontend to login(1).

I did manage to verify the Ctrl-C bug on my end of things. And yeah, while I have Plasma 6.4.0 (yeah, I haven't touched my stuff since then, so an update is really in order), the Ctrl-C bug is really problematic. Not only Kate crashes along with the session (as demonstrated by LibreQuest ), it's also problematic when I try to use that same keyboard shortcut in editors/nano in Konsole! I get the same crash.

I have to wonder what will come first - solving the Ctrl-C bug in SDDM or porting a few greeters to FreeBSD. I think that both do need to happen. Which one is easier - I have no idea, I'm not a programmer.

But yeah, right now, we're stuck launching Plasma Wayland from command-line vty. Using SDDM triggers the Ctrl-C bug, and there's nothing workable in Ports that can serve as an alternative to SDDM to launch Plasma Wayland. If somebody can show otherwise, please post here with a description of how that was accomplished!
 
Well, I checked back on the FreeBSD bugzilla ticket over the SDDM / Ctrl-C bug... and oh, yeah, the issue is getting attention, so there's a good chance it'll get resolved. Ctrl-C is not the only control character sequence for the devs to worry about, apparently - there's also Ctrl-Z, and a ton of others.

KDE does have a ton of keyboard shortcuts, a lot of them are configurable, and of course it would be a major showstopper if some of those keyboard shortcuts crash a Plasma Wayland session! I see a lot of interest in getting that bug solved.
 
Isn't that one terminal-based?

I've seen other threads in here that claim it can log into a Wayland session, but those threads made no claims about KDE.

Well, if it works for KDE Wayland (and does not trigger the Ctrl-C bug like SDDM does at this time), please make a note of that in this thread!
 
Following PR 286592 (that Andriy alerted us to a few days ago) is proving fruitful - just today, the devs have tested a patch for x11/sddm that seems to resolve that Ctrl-C bug. At this point, I think it's a matter of seeing when it makes it into the Ports Collection.

As a side note - what I said about porting other graphical Wayland-compatible greeters - that path is still open. Just feels a bit less urgent now, thanks to SDDM patching making progress.

👏🎉
 
For those who is eager to test Plasma 6.5 by compiling from ports - the ports are ready in the area51 branch of my repo. You will also get KF 6.19.0 and Gear 25.08.2 as a bonus.

Unfortunately Plasma Wayland does not start for me after update, so no screenshots. X11 session works just fine.
 
For those who is eager to test Plasma 6.5 by compiling from ports - the ports are ready in the area51 branch of my repo. You will also get KF 6.19.0 and Gear 25.08.2 as a bonus.

Unfortunately Plasma Wayland does not start for me after update, so no screenshots. X11 session works just fine.
Well, it's supposed to work as specified on ADG's euroquis.nl blog: https://euroquis.nl/kde/2025/09/07/wayland.html

Does Plasma Wayland start from command-line for you?
 
For those who is eager to test Plasma 6.5 by compiling from ports - the ports are ready in the area51 branch of my repo. You will also get KF 6.19.0 and Gear 25.08.2 as a bonus.

Unfortunately Plasma Wayland does not start for me after update, so no screenshots. X11 session works just fine.
Mk/Uses/kde.mk in the Codeberg repo needs to be updated to reflect the fact that the repo has Plasma 6.5 stuff...

I jumped the gun, and downloaded the wrong stuff to compile... 😰 fortunately, I'm not too far into the process.
 
Does Plasma Wayland start from command-line for you?
Turns out Plasma Wayland 6.5.0 does run (both from the terminal and sddm) only if I start it without ck-launch-session, i.e. `plasma-dbus-run-session-if-needed startplasma-wayland`. But I don't get any keyboard and mouse input, and can't even switch back to the terminal.
 
Turns out Plasma Wayland 6.5.0 does run (both from the terminal and sddm) only if I start it without ck-launch-session, i.e. `plasma-dbus-run-session-if-needed startplasma-wayland`. But I don't get any keyboard and mouse input, and can't even switch back to the terminal.
hmmm... off the top of my head, I know I've seen info that if you enable / install pamd, then you don't need the ck-launch-session part...

but being unable to start at all... that's something new.

Yeah, gotta nail things down a bit more thoroughly around here.

I'm still in the process of compiling my way into 6.5.0, I expect it to take another 2-3 days with my Ryzen 5 7600. Well, I'm compiling the whole thing from ground up. I installed FreeBSD Beta 3 normally, and started from there. No packages, all ports.
 
Well, I'm building 6.5.0, starting in /usr/ports/x11/plasma6-plasma, as per hint in ADG's blog... and there's a build error that I have been encountering every single time I built KDE 6.x:

in devel/qt6-tools there's a build error that has been persisting for a long time, ever since 6.0 days:
Code:
===>   Registering installation for qt6-tools-6.9.3 as automatic
pkg-static: Unable to access file /usr/ports/devel/qt6-tools/work/stage/usr/local/bin/qdoc6:No such file or directory
pkg-static: Unable to access file /usr/ports/devel/qt6-tools/work/stage/usr/local/lib/qt6/bin/qdoc:No such file or directory
*** Error code 1
 
Stop.
make[5]: stopped making "install" in /usr/ports/devel/qt6-tools
*** Error code 1
 
Stop.
Just doing /usr/bin/touch on the missing files resolves the build error (just for devel/qt6-tools) and KDE continues to build. But that does mess things up down the road:

sysutils/accounts-qml-module (which gets compiled later along the way) really needs to have /usr/local/bin/qdoc6 to have 755 permissions, because that stops the compilation, as well!
Code:
root@way_kde6:/usr/ports/sysutils/accounts-qml-module/work/stage/usr/local/share/accounts-qml-module/doc/html # ls -Alh
total 512 B
-rw-r--r--  1 root wheel   71B Oct 28  2023 .gitignore
root@way_kde6:/usr/ports/sysutils/accounts-qml-module/work/stage/usr/local/share/accounts-qml-module/doc/html
^ This is the basic issue with sysutils/accounts-qml-module, that directory is empty because qdoc6 (from devel/qt6-tools) did not build properly! I have to do /usr/bin/touch on 20 files that are missing. Slows me down quite a bit.

This does NOT affect Wayland, but it is an annoying hiccup that nobody rectified yet. It does stop the whole build process, I have to manually rectify the error and restart the build to coninue.
 
ouch, this is weird. Qt6 ports are sensitive to the environment, that's why we recommend using poudriere for building your own packages. Please, fill a bug with the full buildlog for qt6-tools or send it to kde@freebsd maillist.

Instead of faking qdoc, which may case cryptic errors further, you can install qt6-tools package from the official repo.
 
Instead of faking qdoc, which may case cryptic errors further, you can install qt6-tools package from the official repo.
Thing is, I kept having that error even with the qt6-tools package that was in the official repo. I've had that same error with earlier versions of QT, it happened every time I build KDE 6, starting with 6.0...
 
Well, I finished compiling Plasma 6.5.0 on my end, but I get exactly the same results as makc_ reported in post #643... That prompted me to reboot a few times.

I accomplish the same result with x11/lightdm and x11/sddm, AND from command-line. Yeah, sysutils/consolekit2's
/usr/local/bin/ck-launch-session seems to be problematic, but I'm thinking it may be a problem with Pipewire or ENV variables again!

Thing is, I tried the ck-launch-session /usr/local/lib/libexec/plasma-dbus-run-session-if-needed startplasma-wayland just to see what errors I get on command-line (launching from vty). And, I got errors about Pipewire and amdgpu not playing well together. It was some text that I saw on the command line. But when I decided to capture that text into a file with help of script(1) (and issuing the same ck-launch-session /usr/local/lib/libexec/plasma-dbus-run-session-if-needed startplasma-wayland), I got VERY different-looking text captured, AND Plasma Wayland actually started. I could see the desktop, but could not use keyboard/mouse!

This has me thinking that the culprit is NOT sysutils/consolekit2, but Pipewire... the output of my attempts to launch Plasma Wayland is attached as typescript.txt.

This all happened on a 15-Beta 3 installation of FreeBSD. I'm kinda reluctant to repeat the process on 14.3-RELEASE (I spent more than 2 solid days on this), but if someone can report different results on 14.3-RELEASE in here, I'd be interested!
 

Attachments

Update:

I decided to try the following (still on FreeBSD 15-Beta 3):
  1. Turn on SDDM in /etc/rc.conf
  2. Edit /usr/local/share/wayland-sessions/plasmawayland.desktop to have the Exec line read: Exec=pipewire && /usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/startplasma-wayland.
  3. Restart SDDM via service sddm restart.
And, got observations:
a. when the Exec line reads simply /usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/startplasma-wayland, I get just the desktop, no keyboard/mouse. And I get the following output as shown in attached out_a.txt: (followed by a need to reboot)

b. when the Exec line reads pipewire /usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/startplasma-wayland, I get no desktop, a static mouse cursor that I can't move, in the middle of the screen. Fortunately, SDDM can be restarted with service sddm restart... And I get the following output as shown in attached out_b.txt:

c. when the Exec line reads wireplumber && /usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/startplasma-wayland, I get some screen flashes, and then returned to SDDM. And I get the following output as shown in attached out_c.txt:

d. when the Exec line reads wireplumber && ck-launch-session /usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/startplasma-wayland, I get same visual result as in observation C, but somewhat different output - the greeter seems to try to start an X11 session!. And I get the following output as shown in attached out_d.txt:

e. when the Exec line reads ck-launch-session /usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/startplasma-wayland, I get same visual result as in observation C, but somewhat different output - some process crashes!. And I get the following output as shown in attached out_e.txt:


Sometimes, it feels like i'm playing wolf, goat, cabbage with different details, and not getting desired results, certainly not with FreeBSD 15-Beta3 and Plasma 6.5.0. Makes me question if ConsoleKit2 is really at fault. Kinda reluctant to go back to older versions (14.3-RELEASE and Plasma 6.4.5), even though those do offer a chance of Plasma Wayland actually working...
 

Attachments

Back
Top