Running KDE Plasma on OpenBSD

November 29, 2024

I had never run a BSD before until last weekend. Curiosity and unix_surrealism propaganda finally took hold, catapulting me through the installation of OpenBSD 7.6 onto a Thinkpad X1 Carbon.

The core OpenBSD experience has been smooth, and the OS is well thought out. The Plasma experience on the other hand has some sharp edges that must be dealt with before the desktop environment is usable. It’s worth noting that Plasma and KDE are recent arrivals in the ports tree, and I would expect this process to get more streamlined in the future.

For now, though, I’m documenting my traversal of this side quest here on the off chance that it helps any other fellow travelers.

Which Packages?

For reference, I installed the kde-plasma, kde-plasma-extras, and kde meta packages. Version 6.1.4 of Plasma is what was present in ports at the time of this writing. The kde-plasma and kde-plasma-extras packages contain the desktop environment. The kde package contains the KDE application suite.

Creating an .xsession File

The usual Plasma display manager sddm was nowhere to be found, so I decided to use OpenBSD’s default xenodm with a .xsession file (when in Rome, etc). This whole process was straightforward. I just needed to figure out which command would launch Plasma. Betraying my age a bit, that command used to be “startkde” a lifetime ago, but today the command to use is startplasma-x11.

The info came from this YouTube video which provided a well put together .xsession file that I lifted completely and used as a base. On top I added a few small things like locale and trackpad settings.

My current .xsession file looks like the following:

export XDG_RUNTIME_DIR=/tmp/run/$(id -u)
if [ ! -d $XDG_RUNTIME_DIR ]; then
        mkdir -m 700 -p $XDG_RUNTIME_DIR
fi

export LC_CTYPE="en_US.UTF-8"
export QT_FORCE_STDERR_LOGGING=1
export XDG_CURRENT_DESKTOP=KDE
export DESKTOP_SESSION=plasma

xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation" 1
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Button" 2
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Axes" 6 7 4 5

/usr/local/bin/startplasma-x11 > ~/.startplasma-x11.log 2>&1

Raise File Descriptor Limits

Out of the box OpenBSD ships with conservatively low file descriptor limits. My regular user account had a soft limit of 512. This is a nice and secure configuration for a server but not for a desktop. To resolve this I needed to raise both the system file descriptor limit and my user’s individual limits.

As an aside, this issue left me scratching my head for a little bit because it manifested as the Plasma desktop reliably crashing roughly 30 seconds after login. After some random flailing about, I finally opened that .startplasma-x11.log file specified in .xsession and was greeted with lots of errors about processes being unable to create new file descriptors. Mystery solved I guess!

System File Descriptor Limit

Adding the line below to /etc/sysctl.conf raised the system file descriptor limit to 65536. For reference the default value was 7030.

kern.maxfiles=65536

User File Descriptor Limit

Since this laptop is a single user machine and my regular user account is in the staff group it was easy to modify the file descriptor limit for staff in /etc/login.conf. Adding the two new entries shown below raised the file descriptor limit to 50000 from the default of 512.

staff:\
	:datasize-cur=1536M:\
	:datasize=max=infinity:\
	:maxproc-max=512:\
	:maxproc-cur=256:\
	:openfiles-max=50000:\ # this line is new
	:openfiles-cur=50000:\ # this line is also new
	:ignorenologin:\
	:requirehome@:\
	:tc=default:

Fix Lock Screen Authentication

The last hurdle to clear was that the Plasma lock screen would error instead of unlocking. The desktop would lock okay, but upon moving the mouse to wake it the display would go black and show an (apparently infamous) error message about session unlocking being broken. There are many forum posts about this type of message appearing on Linux too, but the underlying causes here were different.

Quick and Dirty PAM Fix

There were some errors from the lock screen in .startplasma-x11.log about certain PAM configs being missing (kde, kde-fingerprint, and kde-smartcard), so I decided to cheat and look at the /etc/pam.d directory on a working Linux install. The file contents of /etc/pam.d/kde were essentially an alias to /etc/pam.d/system-login. After some contemplation this made sense because the lock screen should be checking the user’s password in the same fashion as a terminal login.

Back in BSD-land I decided to just symlink the three KDE missing PAM configs to the main system config located at /etc/pam.d/system (shown below). I should note that this hack almost assuredly will NOT make login via fingerprint reader or smartcard work, but it was enough to satisfy the lock screen and get it to prompt for the user password.

# ln -s /etc/pam.d/system /etc/pam.d/kde
# ln -s /etc/pam.d/system /etc/pam.d/kde-fingerprint
# ln -s /etc/pam.d/system /etc/pam.d/kde-smartcard

Allow Lock Screen to Check Passwords

After the PAM symlinks were in place the lock screen would now prompt for a password but nothing would happen when submitting the password. At this point I was pretty discouraged because I didn’t fully trust my PAM hack. I debated turning off the Plasma lock screen and using something classic like XScreenSaver instead.

However, present in .startplasma-x11.log was a new error about the lock screen unable to access /etc/libexec/auth/login_passwd. After another round of piecing together bits and pieces from messages boards I learned that OpenBSD, being a security conscious operating system, by default does not let regular users verify passwords.

The login_passwd program itself is only accessible by root and the auth group. The swift fix here was to find the Plasma lock screen program (kscreenlocker_greet) and use the setgid bit so that it runs with auth group permissions.

# chgrp auth /usr/local/libexec/kscreenlocker_greet
# chmod g+s /usr/local/libexec/kscreenlocker_greet

With the above changes in place the lock screen started operating normally. Success!

Features Still Not Working

There are still some smaller things not working quite right, although none of them are deal breakers for me. Similar to the lock screen it’s possible that they only need some additional manual intervention.

To be clear audio worked out of the box with OpenBSD, and I can adjust the volume with the keyboard hotkeys. The Plasma sound widget however has no knowledge of this and does not show any audio devices.

Very similar to audio, display brightness worked out of the box with the OS, but Plasma’s display widget isn’t communicating with the driver.

KDE Connect

KDE Connect is showing some sort of CLI command error in System Settings and consequently is not working. OpenBSD famously does not support Bluetooth, but I don’t think that’s the issue here. I need to investigate the error further.

Blog