Plasma6 and FreeBSD 14
I just installed a new FreeBSD desktop machine. For this one, I wanted to have KDE Plasma6, since that’s already running on my Linux laptop and gaming machine – and it’s time for me to dogfood on FreeBSD. Here’s some notes.
Base Install
FreeBSD has a Live ISO and a graphical installer. For licensing reasons,
it isn’t Calamares (which is GPLv3). So I use the text-based installer.
I downloaded the FreeBSD 14.1 memstick image.
From boot to reboot into an installed system takes less than five minutes,
but then you have an old-school UNIX system: a login:
prompt.
From there:
- log in as root
- switch the package repository to latest
pkg install pkg
, to get the package managerpkg install git cmake
, because you’re a developerpkg install plasma6-plasma
, which is an 800MiB downloadpkg install sddm
, because you’ll want a login-managerpkg install drm-kmod
, because you need a graphics driver
I have an AMD RX550 video card (cheapest I could get this year) in the machine, so then to set that graphics driver:
sysrc kld_list=amdgpu
Make sure DBus will run as a system service:
sysrc dbus_enable=yes
Create a regular user and add them to the video group.
Then reboot.
KDE Plasma6 X11 by Hand
At this point, the system has KDE Plasma6 installed, but it won’t come up (the login manager isn’t enabled, for instance) so we need some convenience things from The Before Times to do a little testing. (Installed as “automatic” so they are easy to remove later).
pkg install -A xinit xterm
As a normal user, create ~/.xinitrc
and put this in it:
#! /bin/sh
exec /usr/local/bin/startplasma-x11
Then make it executable and start X11 (like it’s 1994):
chmod 755 .xinitrc
startx
Voila. KDE Plasma6. Note that, in this state, there are no applications besides xterm and KInfoCenter (and a handful of other KDE Plasma internal things). There’s no configuration applied to the system. The window manager does not honor alt-tab or alt-F4. Use ctrl-Q to quit KInfoCenter.
But X11 is soooo passé. Let’s move on to the Future!
Any Wayland by Hand
First, let’s install some convenience things that will help in debugging.
pkg install -A river foot
Like I wrote 3 years ago about river, it just works. You’ll need the example configuration file so that super-shift-E exits the compositor and window manager. super-shift-enter gets you a terminal window.
I started river as a regular user with
ck-launch-session river
KDE Plasma6 Wayland by Hand
Yeah, right.
So there was a brief time in 2021 that it worked. Since then, not so much – certainly not for me, not from the regular ports tree. So this post is a start of “ok, let’s give it another shot”.
I know that Wayland can work on FreeBSD with hardware rendering – that’s why that river section is there.
Here is a very short script that can launch KDE Plasma6 with software rendering. The resulting desktop experience is rather slow.
#! /bin/sh
export KWIN_COMPOSE=Q
exec /usr/local/bin/ck-launch-session \
/usr/local/lib/libexec/plasma-dbus-run-session-if-needed \
/usr/local/bin/startplasma-wayland
So the TODO part of this post is: figure out why opening dri/card0
fails when kwin_wayland is not using the software renderer.
KDE Applications5 and KDE Plasma6
Yeah, right.
Most (maybe even all) of the KDE Applications – for instance, konsole, or kmail –
are still KDE Frameworks 5 based. Unfortunately,
there are KDE Frameworks that have file-collisions between versions 5 and 6.
As an example, package kf6-baloo and kf5-baloo both want to install
a libbalooplugin.so
. I mentioned the co-installability problem a half-year ago, but we haven’t fixed it since.
Edit 2024-10-08: this is entirely a packaging problem, where we could install the things to separate prefixes. That hasn’t happened, because of a lack of person-time to actually do it (and test it).
On this front I think we’re at a chicken-and-egg place: we would like to switch wholesale to newer applications releases and just drop the existing KDE Applications 5, but are so bogged down with Other Stuff that it’s not happening. On the Linux side of things KDE Applications 6 are doing fine.
All that said, there’s the KDE-FreeBSD ports development fork with a branch where newer KDE-FreeBSD packages are prepared. That already has a KF6-based KMail. So the TODO part of this section is: I need to double-check what’s holding that up.
Takeaways
- for a nice KDE Plasma6 experience on a BSD, why not try OpenBSD?
- KDE-FreeBSD has a nasty amount of hardware-testing to do.
- The future is here, just not in the ports tree.