KDE Plasma On WSL On Ubuntu 20.04 On Surface Pro 3

Was that enough ON’s in the title? LOL. Anyway – earlier in the year I wrote a very long article outlining how to get a full desktop experience under WSL2 using Ubuntu 20.04. I wrote it with a view to the Surface Pro 4 as that’s what I was using at the time. For various reasons (notably my touch no longer working on the SP4 and needing extra RAM) I’m using a Surface Pro 3 at the moment.

It should also be noted that this article actually applies to any Windows 10 PC running Windows build 2004 or later (which is likely to be most by now). The more beefy your processor the better it’ll run to be fair. But it runs pretty well even on the SP3.

I followed my own instructions because I’m good like that. During which time I discovered that some of things have changed so updated the article. And when I came to set the display scaling to 150% that the Surface Pro 3 looks best at, the whole thing fell apart… Native Gnome and native Ubuntu 20.04 both support fractional scaling. But it didn’t work at all well on WSL2 for some reason. It went too big – or didn’t change at all. Or some aspects of the display scaled properly but others were overscaled. It was a mess.

KDE Plasma On WSL? Why?

I’d pretty much given up on the idea of a full GUI desktop on WSL on Surface Pro 3 because XFCE doesn’t even support fractional scaling yet. 200% is way too big, 100% is way too small.

That was until I was reading Reddit and someone (FriendlyJewThrowaway) posted about KDE on WSL2 running nicely with VcXsrv as the X-Server. Sounded interesting. I’d already had a play with KDE Plasma a few weeks ago for reasons that I can’t even remember and I was fairly sure that it’s fractional scaling worked on the Surface Pro 3 so I thought it was worth a play.

And I’ve got to say I agree with u/FriendlyJewThrowaway that it’s actually working really well. There’s a little bit of lag between the WSL2 system and the VcXsrv windows – most notable when scrolling a web browser. But Dolphin file browser for example works nicely. The Nextcloud client even seems to work so far (and is nicely integrated into the task bar, unlike in Gnome).

Install KDE Plasma On WSL With Ubuntu 20.04 For Surface Pro 3

Install WSL2 and Ubuntu 20.04 On It

I’m going to assume that you have WSL 2 setup on your Windows computer and know how to install Ubuntu 20.04 onto it. You can use other distributions for this if you like but I’ve stuck with Ubuntu (though Fedora is really good too) and these instructions assume Ubuntu. If you don’t know how to install WSL or Ubuntu 20.04 on WSL, have a look at this article and read up until the instructions to use TaskSel (it’s not actually needed). Then come back to this article 🙂

Install Kubuntu Desktop Components

The Ubuntu distribution that’s installed from the Microsoft Store doesn’t come with any GUI components installed. This is fine, we’re going to install them now. To install KDE we’re going to use the Kubuntu meta-package to install KDE and all the other components it needs. For our purposes there’s probably a bunch of dependencies that aren’t actually needed, but unpicking them all isn’t something I can be bothered to do, so I just installed it all.

sudo apt update
sudo apt upgrade
sudo apt install kubuntu-desktop

This may take a while, might be a good time to grab a cup of tea. Of course it depends on the speed of your machine (but this is written for Surface Pro 3 users) and internet connection…

Install and SetUp LightDM

KDE Plasma comes with a display manager called SDDM. But SDDM deliberately does not support XDMCP which is what we’ll need to use later. So we might as well set it up now.

sudo apt install lightdm

During the installation you should be asked which display manager you want to use. It’ll default to SDDM. You need to switch it to LightDM.

Edit LightDM Configuration

Out of the box, lightdm won’t work for Plasma – it will work for Gnome but that’s not installed. So we need to tweak it.

We need to create a LightDM configuration using the command below;

sudo nano /etc/lightdm/lightdm.conf

Then add the following contents to that file and save and exit

[Seat:*]
user-session=plasma

[LightDM]
start-default-seat=false

[XDMCPServer]
enabled=true
port=177

The above commands tell LighDM to start the plasma desktop for every person that uses this machine. It also tells it not to start an X-Window server on the WSL machine (because we’ll use VcXsrv for that under Windows) and finally it tells it to run an XDMCPServer on Port 177 (the default) to allow us to login using a nice greeter under X-Windows.

Install SystemD-Genie

Even WSL2 doesn’t have the full environment installed by default and SystemD cannot install in WSL2 because of the way it ‘boots’ up. This is by design but it does mean that some things, such as graphical user interfaces that expect to be run at boot time won’t generally work properly. There’s all sorts of messaging daemons that are pre-set to run at boot as well. If we can’t rely on SystemD to be present you might be forgiven for thinking we’re slightly screwed at this point.

Fortunately Arkane Systems have rescued us and provided Genie in a bottle 🙂

Follow the link above to Arkane Systems to get detailed instructions for installing Genie. You’ll need to install the Microsoft modules before installing Genie. Microsoft’s documentation isn’t especially beginner friendly or clear – so you can follow the instructions below (but bear in mind they may change the way it all works and this advice will then stop working) before visiting Arkane Systems to install Genie.

Install DotNet Dependencies

wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb

sudo dpkg -i packages-microsoft-prod.deb

sudo apt update

sudo apt install dotnet-runtime-3.1

Once you’ve done that, visit Arkane Systems Github Page to find out how to install Genie.

Start SystemD-Genie

Once Genie is installed, you can start it with the command

genie -s

The only thing you’ll see to show you that it’s successfully completed will be that your command prompt has changed to include a -wsl suffic on your hostname. But in the background, your LightDM should now be running and waiting for you to point your VcXsrv or other X-Windows server to.

This command is only for initial testing – once you’re sure everything is setup correctly, I recommend using genie -i from a startup script, which I’ll go into later.

Grab the X-Windows Server Software for MS-Windows

You’ll need some software that understands the X-Windows protocol. For this I use the excellent VcXSrv software which is free and Open Source. It provides an X-Window server on Microsoft Windows. You can download VcXsrv for free at https://sourceforge.net/projects/vcxsrv/

Install that software as per the instructions.

Setup VcXsrv With XDMCP

From this point onward, the setup of the system is very much the same as it is for the previous article based on Gnome, so rather than repeat all the same steps, click here to read the previous article information.

When you reach the end of that article, come back to this article to read on about specific KDE Plasma settings that will help you speed up or improve your experience.

Speed Up KDE Plasma on WSL

The default installation of KDE Plasma on WSL seems to insist on using OpenGL to accelerate the X-Windows sessions. The problem is that in fact, on a normal Linux installation this would probably be a good choice, on WSL it’s just bad. I only found this out thanks to u/FriendlyJewThrowaway – but the difference is night and day for browsing the web with Firefox…

To sort it out (and I’m not aware how you can do this on Gnome, so there’s another plus for KDE Plasma) you need to open up the KDE System Settings -> Compositor and change the rendering backend to XRender as per the screenshot to the right.

Doing this, ironically causes scrolling in Firefox to be very nearly as smooth as native.

Setup Sound On KDE Plasma On WSL

This is, quite frankly, a bloody nightmare. Hopefully this article will help because it’s taken me all afternoon into the evening to get working and again only ended up solving it with the help of u/FriendlyJewThrowaway who provided the missing piece of the puzzle.

Anyway, to get sound working inside your WSL environment you’re going to need a Windows PulseAudio server.

Download PulseAudio For Windows

Pulseaudio is maintained only for Linux – but someone in the dim and distant past has created a Windows binary installation. Everything I saw online suggested using this version, not any of the others that come up in a Google Search. So I recommend this one too because, I’ll jump on that bandwagon 🙂

Using the Windows browser (ie, outside of WSL) download the zip file from the following location;

https://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Windows/Support/

When it’s downloaded you’ll need to unzip it. I recommend unzipping into C:\PulseAudio for ease of setup.

Configure PulseAudio For Windows

You’ll need to edit some configuration files to make it work. You can use Notepad, though if you have Visual Studio Code that’ll work too – and is probably the nicer way to do it 🙂 Anyway, the files you’ll need to edit are;

C:\PulseAudio\etc\pulse\default.pa

Change Line 42 from

load-module module-waveout sink_name=output source_name=input

to

load-module module-waveout sink_name=output source_name=input record=0

This will stop your Plasma Desktop under WSL from being able to access the microphone on your Surface Pro 3. Don’t change it if you’re not worried about it – but be aware if you don’t you’ll get the little microphone show up in your Windows Taskbar while PulseAudio is running.

Next, edit line 61 from

# load-module module-native-protocol-tcp

to

load-module module-native-protocol-tcp auth-ip-acl=172.0.0.0/8 auth-anonymous=1

This will let your PulseAudio client from WSL to connect to your Windows PulseAudio server. Be aware, everywhere else on the internet tells you that 127.0.0.1 is the appropriate auth-ip-acl here. It’s not – that’s for WSL1. The above command tells PulseAudio to allow connections from any IP address that begins with 172 – which is the address range that WSL allocates. You can’t narrow it down any further than that because WSL2 will change its IP address after every reboot – which is right annoying.

Now edit C:\PulseAudio\etc\pulse\daemon.conf and change Line 39 from

; exit-idle-time = 20

to

exit-idle-time = -1

This will stop the PulseAudio daemon from shutting down when the last client disconnects – as it might

Give it a test run by executing C:\PulseAudio\bin\pulseaudio.exe

You MUST allow Public networks through the firewall despite what other places tell you – again this is due to it being running on WSL2 instead of WSL1

Setup Plasma To Use Network PulseAudio Server

There’s three places that you need to set this up. I’m not entirely sure if it needs to be in all these places, but that’s where I set them up.

sudo nano /etc/environment

#Add these lines at the bottom
LIBGL_ALWAYS_INDIRECT=0
PULSE_SERVER=tcp:`route | grep default | awk '{print $2}'`

nano ~/.bashrc

export LIBGL_ALWAYS_INDIRECT=0
export PULSE_SERVER=tcp:`route | grep default | awk '{print $2}'`

mkdir -p ~/.config/plasma-workspace/env
nano ~/.config/plasma-workspace/env/sound-server.sh

export PULSE_SERVER=tcp:`route | grep default | awk '{print $2}'`

chmod +x ~/.config/plasma-workspace/env/sound-server.sh

Set PulseAudio Server to Start When You Login To Windows

From a command prompt, type

notepad C:\Users\[yourusername]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\wsl.bat

And add the following code, then save it

REM Start The PulseAudio Server On Windows Side
start /min c:\pulseaudio\bin\pulseaudio.exe --exit-idle-time=-1

REM Automatically start SystemD-Genie
start /min wsl genie -i

REM Automatically start the VcXsrv X-Windows Server. Note you might want to change some of the
REM parameters to better suit your useage
REM Also note, this relies on you having installed Shane Sweeney's Go-WSL2-Host app to
REM create the hostname to IP address mapping for ubuntu2004.wsl
start "" "C:\Program Files\VcXsrv\vcxsrv.exe" :0 -query ubuntu2004.wsl -nowgl -fullscreen -clipboard -ac

Set Display Scaling For Surface Pro 3

If everything is up and running you can set the display scaling to 150% under KDE Plasma to make it look better. You can find this setting under System Settings -> Display Configuration

Fix Permissions for Muon Package Manager

I’m not too sure of the ramifications of this, or indeed why it’s necessary – this is another recommendation from our friendly Jew Throwaway and is not something I could have discovered myself because I don’t tend to use a GUI package manager. Nevertheless, if you want to use Muon Package Manager to update your system or add new packages, you’ll need this;

sudo nano /usr/share/polkit-1/actions/org.kubuntu.qaptworker3.policy

This is an XML file and requires some additions. You’ll need to add <allow_any>[matched_text]</allow_any> to the defaults sections of every action that’s listed within. The [matched_text] will need to be replaced with whichever text is in between the <allow_active></allow_active> sections in the same section.

For example;

<action id="org.kubuntu.qaptworker3.updatecache">
    <description>Update software sources</description>
    <message>Update software sources</message>
    <defaults>
      <allow_any>yes</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

Notice that the text between the allow_any and the allow_active is set to yes? In the original file, the allow_any section is not present and you will need to add it.

Do this for all actions in that file. Save the file and restart Muon if it’s open.

Struggling With Go-WSL2-Host Starting Up?

If you can’t get the Go-WSL2-Host service to start because you’re logging in to Windows with a Microsoft Account instead of a Local account, there is a (somewhat fiddly but perfectly doable) fix here.

Credits

This article is inspired almost in its entirety by Reddit User u/FriendlyJewThrowaway from their original post at https://www.reddit.com/r/bashonubuntuonwindows/comments/j2i5ix/fully_working_kde_on_bash_on_ubuntu_2004/ and subsequent comments. They had some knowledge about some of the finer details of KDE that I’d never had because I’ve generally used Gnome.

Also thanks to Arkane Systems for coming up with Genie to emulate a normal systemd setup for WSL2. Without this work, none of this would be possible.

Then there’s Shayne Sweeney who produced the Go-WSL2-Host package that makes it easy to use a hostname rather than IP address making the whole XDMCP connection so much simpler and more reliable. Fix permissions for Microsoft Account login for Go-WSL2-Host here.

Finally, there’s more credits for the underlying knowledge I gained from writing the original article at Ubuntu 20.04 Desktop GUI on WSL2 on Surface Pro 4 from which much of this article is taken.

If there’s anything I’ve missed, or you have any comments please drop me a line below. I’ve got to say this is the best GUI experience in WSL2 that I’ve had – it’s almost as good as native, without the hassle of dual boot. The image below shows a screenshot of my desktop, writing this article in Firefox on KDE Plasma on WSL running Ubuntu 20.04 on a Surface Pro 3 – enjoy!