Raspberry Pi 4: Chronicling the Desktop Experience – Remote Desktop – Week 8

Last Updated on April 12, 2020

This is a weekly blog about the Raspberry Pi 4 (“RPI4”), the latest product in the popular Raspberry Pi range of computers.

I really appreciate receiving suggestions from readers of this blog. I’ve received a few requests to see how the RPI4 fares as a remote desktop client. I can see this could make sense. The RPI4 offers dual monitor support. It should have sufficient CPU and GPU resources to act as a functional remote desktop, particularly when connecting to servers that have better system resources.

Remote Desktop Control displays the screen of another computer (via Internet or local area network) on a local screen. This type of software enables users to use the mouse and keyboard to control the other computer remotely. It means that a user can work on a remote computer as if he or she was sitting directly in front of it, regardless of the distance between the computers.

While readers’ suggestions were focused on the RPI4 acting as a client, my more immediate concern was to use the RPI4 as a host rather than a client. I’ll explain why. For the past week, I’ve been travelling around the country, staying with a few friends. Friends that run Windows only. No one is perfect! And the week before this trip, my Linux laptop gave up the ghost. Reliant on Windows machines with only an Android phone as solace for an entire week wasn’t a tempting prospect. So what better time to access my RPI4 remotely and continue my Pi adventures.

In the realm of remote desktop software, there’s lots of choices for the Raspberry Pi. The obvious focus is VNC related software. There’s lots of VNC clients available in the Raspbian repositories. Popular ones such as VNC Viewer (realvnc), Remmina, TigerVNC, TightVNC, Vinagre are all present.

But the host Windows machines only had TeamViewer installed, and I never force ‘alien’ software on my (dinosaur) mates.

TeamViewer offers remote access to a wide variety of operating systems including Linux distributions. It’s proprietary software, so you won’t find the source code available. But you can use the software free of charge to access private computers. For the RPI4 (and earlier versions) TeamViewer is only available for the RPI4 in a host edition. This means that the software is designed to receive connections and act as a server. But that’s sufficient for my week away.

Unsurprisingly, TeamViewer isn’t present in the Raspbian repositories. But installation is straightforward. Point your web browser to the download site and grab a package (.deb) for TeamViewer Host for Raspberry Pi (it’s somewhat tucked away on the right hand side of the page). Once downloaded, type:

This command didn’t complete successfully because my system was missing a variety of packages (specifically qml-module-qtgraphicaleffects, qml-module-qtquick-controls, qml-module-qtquick-dialogs, qml-module-qtquick-layouts, qml-module-qtquick-privatewidgets, qml-module-qtquick-window2, and qml-module-qtquick2).

The installation was completed with the command below. This installs the missing packages and completes the installation of TeamViewer too.

There’s a few more jumps to clear before the software is ready to use. Choose a password, connect the device to your TeamViewer account, accept the license agreement, associate your RPI4 with your TeamViewer account (you can connect via the TeamViewer ID instead), grant easy access, and assign your account.

My friends already have TeamViewer running on their Windows machines. Connecting to my RPI4 was straightforward. How’s performance?

To start with, I opened a terminal remotely on the RPI4, and ran top. On the host machine (RPI4), CPU usage is minimal when the host machine is idle. The software consumes about 7% CPU of 1 core for the TeamViewer_Desktop process, around 2.6% CPU for the TeamViewer daemon, and less than 1% for the TeamViewer process. Here’s the memory consumption for the 3 processes:

A pretty hefty memory footprint. I wouldn’t recommend using the software on the 1GB RAM model of the RPI4.

Interactivity with the RPI4 host was very good even with 2 monitors running at 2560×1440 resolution. I tried various custom settings ranging from the highest quality (colors set to true color and quality set to highest quality), to the quickest setting (grayscale and the quality slider set to highest speed). Dragging windows around the desktop is a bit laggy even with quality settings set fairly low, but that’s more of a limitation with remote ‘desktoping’. It’s heavy on CPU resources. For example, simply moving a window around the desktop consumes almost the entire CPU of one of the 4 cores.

There’s no noticeable lag navigating desktop menus, and performing basic GUI tasks such as moving files between directories works like a charm. Of course, if you tax the X server (Xorg) to any significant degree, interactivity isn’t perfect, but again there’s always limitations with remote desktops.

Summary

I was more than happy with performance. TeamViewer allowed me to write this week’s blog, tinker with some of the RPI4’s recommended software including dabbling with Mathematica, have full access to the power of the command-line, and much more.

I really like TeamViewer’s multi-monitor support. It was really useful to be able to view each monitor individually, or as a super-desktop. And I could move between these sessions instantly.

TeamViewer has a ton of other functionality although many of the features aren’t supported with RPI4 running as the host machine. But for my purposes, the functionality is more than adequate.

TeamViewer is a remote-control app that is often used by scammers, but that’s mainly because of the free-for-personal-use aspect than anything inherently dangerous about the software. It has a fairly sophisticated security model.

I also ran TeamViewer on my Samsung mobile phone. For some desktop functions, it performs quite well. Speed wasn’t an issue. But the lack of a proper keyboard and mouse limits its usefulness.

In a future blog, I’ll report on using the RPI4 as the client rather than the host machine. The host machines will be desktop PCs running Linux and Windows. But tests running Windows 10 as the host and RPI4 as the client will be limited. I won’t be able to use Microsoft’s Remote Desktop Connection as only Windows 10 Professional machines can be remotely controlled in this way — not Windows 10 Home machines. My only Windows licenses are Windows 10 Home. And as an impoverished student, that’s unlikely to change any time soon.

Read all my blog posts about the RPI4.

This blog is written on the RPI4.