

However, with the Raspberry Pi 4, I wanted to get to a desktop without fishing up a spare monitor. I’ll show you two ways to get a full graphical KDE desktop running with nothing more than a network connection. The same principle applies to most other desktop environments, but I am using KDE and Ubuntu on the Pi, even though something lighter would probably perform better. But before we get there, let’s talk about how X11 has had a big identity crisis over the years. There are many ways to remotely access X programs, many of which are rarely used today. However, for this purpose, we are going to use SSH tunneling along with some special tricks to get the entire desktop running. It is easy to just run a single X program over SSH, and you’ve probably done that often. If you haven’t done SSH tunneling before, don’t worry it is easy. When you start ssh to the Pi, just include the -X or -Y option. You can also configure that in the ssh config file ( ForwardX11 yes or ForwardX11Trusted yes) so you don’t have to type it in all the time. The SSH programs also have to be configured to allow that, but that’s usually the default behavior. That would run konsole on your Pi, but the screen appears on your main machine.

That’s fine, but it isn’t the entire desktop experience. Plus, some programs really expect support from other services that a desktop environment like KDE starts. So the trick is how to start the desktop? The Tunneling Desktop If you want to start a modern version of KDE, you can run startplasma-x11. The obvious thing to do is to try that over an SSH connection with X forwarding. Your screen is already managed by something else - maybe even KDE. The trick is to create a new X server just for the Raspberry Pi. While you could start a new server, it is easier to create a fake server that lives in a window on your main server’s screen. There are two ways to do this: Xnest and Xephyr. Xnest is very old and creates a simple server with very few features.


It depends on the host X server for most functions. It provides lots of modern features no matter what the host server provides. It basically uses the host server as a frame buffer. Of course, this all assumes you have the KDE desktop installed on the Pi. A simple apt install for kubuntu-desktop will take care of that if you haven’t done it already.
