RDP is a convenient way to connect to Windows and also other operating systems with RDP host software, e.g. Linux. RDP transmits display information more efficiently than VLC, as it sees the structure of the screen and it’s elements. It also allows to transmit audio information both ways – playback and recording, share printers, drives, and more. As it is an extensible protocol, efficient video / multimedia playback can be implemented – and has been implemented, albeit apparently only in Windows Media Player.
The Raspberry Pi is a low-power device, with Full-HD (and audio) capable HDMI output.
FreeRDP is a mighty utility to connect to RDP servers, and utilize many of their possibilities. It even supports the video extensions for RDP (in RDP lingo: video redirection virtual channel extension) with ffmpeg. Don’t get your hope up too high right now, though: while theoretically feasible in software, it still would have to be written for both the Raspberry AND the host (it is not a “plug & forget” solution, but the software run on the server has to support it specifically).
The current state: A marriage made in heaven?
Not quite. FreeRDP is easily installed, and used from an X session. But it is … agonizingly slow. Audio playback is in a bad state.
The problem: X adds a very high overhead to any application, but even more so a graphics intensive, such as FreeRDP. Even super-charging the Raspberry Pi with overclocking, Class 10 SD cards, a beefy power supply, etc. will NOT solve this problem! An RDP client compiled specifically for Wayland might, but this is still some way off.
FreeRDP can be compiled to draw to the Direct Frame Buffer. This eliminates all of the overhead, which X would add. This is perfect for people really trying to use the Raspberry as Windows / RDP thin client. It will work in FullHD resolution (over the local network), with sufficient performance (and 16 bit color depth).
Kudos are in order to the Tao of Mac blog, which had the idea, and the instructions to get me up and running. You rock!
We will release a hardware & software package RDP client, based on the Raspberry, really soon now. If you’re interested, hit me up in the comments.
Step-by step instructions
With all that out of the way, let’s jump into the instructions!
We suggest to use a Class 10 SD card, with ample space for the installation & build of the packages (8 GB Class 10 seems sensible). Install the newest Raspbian image, set up your locale and keyboard layout, aptitude update and aptitude upgrade.
Install the necessary packages:
aptitude install build-essential git-core cmake libssl-dev libx11-dev libxext-dev libxinerama-dev libxcursor-dev libxdamage-dev libxv-dev libxkbfile-dev libasound2-dev libcups2-dev libxml2 libxml2-dev libxrandr-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libavutil-dev libavcodec-dev libcunit1-dev libdirectfb-dev xmlto doxygen libxtst-dev
This should take quite a while.
Download the FreeRDP package (use a sensible location, we will be compiling there later. If in doubt, a sub-folder in your home folder is OK):
You might also consider checking out the 1.0.3 pre-release version. It might turn stable in a couple of months.
Set up the build environment – this is analoguous to ./configure seen in many other compilations:
cmake -DCMAKE_BUILD_TYPE=Release -DWITH_FFMPEG=OFF -DWITH_XINERAMA=OFF -DWITH_XCURSOR=OFF -DWITH_DIRECTFB=ON -DCMAKE_INSTALL_PREFIX=~/freerdp
A couple of hints for this:
- You might want to adjust the –DCMAKE_INSTALL_PREFIX to something more suitable – if you compile as root, it will install the application and the libraries into the folder /root/freerdp otherwise.
A good choice could be /usr – this way the binaries and libraries will be in the normal search path.
- turning off FFMPEG means turning off virtual video extension. As discussed before, this is of limited use anyway, right now. But some experimenting might be interesting. FreeRDP also is built modularized on top of FFMPEG, so exchanging that for an omxplayer-like code thingy SHOULD be feasible.
- Xinerama – is an X extension which allows X applications to span two or more displays a one large virtual display.
Check for the output of this command. It will tell you about skipped options and missed packages. It should find DirectFB amongst others (Found DirectFB: /usr/lib/arm-linux-gnueabihf/libdirectfb.so).
- pulseaudio: this is a sound server, and another layer on ALSA. It is network capable. Users report varying mileage with pulseaudio and good playback quality. We have tested without the pulseaudio package, future tests will show whether there is an advantage in using it.
- pcsc – this is for smart card support, most likely you will not need it
- CUnit – a lightweight system for writing, administering and running unit tests in C – most likely you will not need this, either.
Compile the DirectFB RDP client:
cd client/DirectFB/ make #optionally sudo make install #for sound support cd ../../channels/drdynvc make sudo make install cd ../rdpsnd make sudo make install
This is all – but this will take quite a while (some hours).
Set up some configuration files
Edit your /etc/udev/rules.d/99-input.rules to be:
SUBSYSTEM=="input", GROUP="input", MODE="0660" KERNEL=="tty[0-9]*", GROUP="root", MODE="0666" KERNEL=="mice", MODE="0666" KERNEL=="fb0", OWNER="root", MODE="0660"
The first line should aready be in the file, add the other three lines.
Optional, but recommended: Edit your /boot/config.txt to contain the following settings:
framebuffer_width=1920 framebuffer_height=1080 framebuffer_depth=16 # for other stuff gpu_mem=128 arm_freq=800 disable_overscan=1 hdmi_drive=2 hdmi_ignore_edid=0xa5000080
- set your resolution as fixed [framebuffer_width, framebuffer_height] – be sure to adjust to your needs!
- set bit depth to 16 – as we will connect to the RDP server using this depth for better performance.
- ignore anything the monitor will tell the Raspberry – it might lead to blurry edges, otherwise [hdmi_ignore_edid=0xa5000080]
- overclock the raspberry just a little [arm_freq=800]
- disable the overscan – remove the black area around the display output on modern LCD monitors [disable_overscan=1]
- set up the HDMI output to be a real HDMI output and carry audio – this will fix “no sound output” problems [hdmi_drive=2] don’t use this if you connect your Raspberry via DVI or VGA to the monitor
Edit /etc/fb.modes and add a new mode:
# Added as per taoofmac instructions mode "1920x1080-24p" geometry 1920 1080 1920 1080 32 timings 13468 148 638 36 4 44 5 endmode
You will have to adjust this if you use a different resolution than FullHD. The original article at Tao of Mac has some more resolution examples for you.
Create a new file /etc/directfbrc with the following contents:
system=fbdev autoflip-window desktop-buffer-mode=auto vt-switching graphics-vt no-deinit-check no-motion-compression no-translucent-windows memcpy=arm mode=1920x1080 depth=16 dma hardware # for the moment, we need DirectFB's own cursor sprite cursor
If you specified –DCMAKE_INSTALL_PREFIX to be /usr, you should be able to use FreeRDP DirectFB client without any path prefix, else just prepend your path:
dfreerdp -u "user name" -p secret_password_here -f -g 1920x1080 -x l -z --disable-full-window-drag --gdi hw --plugin rdpsnd --data alsa -- host:port
Be sure to adjust this command:
- “user name” should be your user name. If it contains a space, you should keep the quotation marks, else you can loose them.
- secret_password_here should be your password, obviosly.
- -g specifies the geometry. Adjust, as necessary.
- -x = experience (l for LAN), will enable different bells and whistles. You might want to modify that, or use a more finegrained control of which features to enable, and which to disable
- -z enable compression (useful)
- –gdi hw – I’m not sure whether this is really necessary
- –plugin rdpsnd –data alsa — – this will enable remote sound output on the Raspberry. Drdynvc is said to have better quality, but I could not get it to work unfortunately. And, yes, the trailing double dashes are part of this option.
- server:port – can be specified as domain or IP adress. The :port can be omitted, if you are connecting to the default RDP port (3389)
If you want sound output on the remote machine, use the –o switch.
What about keyboard layout?
It will work exactly as you see your keyboard input on the Raspberry console itself. Even the Windows key should work. If your layout does not work on the Raspberry console, consider setting it up using raspi-config
Will this work over WLAN?
Sure it will. Just adjust your WiFi dongle for optimum throughput and latency (yes, literally change its position, tilt, etc. until you find the best performance spot!)
We recommend you the following packes for graphical / console adjustment of Wireless settings:
aptitude install wicd wicd-gtk wicd-curses
Will Skype work?
Not tested yet – enlighten us This will need microphone redirection, too.
Will forwarding of devices work?
Not tested yet – inform us about usb printers, thumb drives, etc.
How can I test sound output on the Raspberry?
aplay /usr/share/scratch/Media/Sounds/Vocals/Singer2.wav -v -V mono
Will performance over WAN networks be OK?
Yes, pretty much – sound output will suffer (a lot), but the GUI will still be quite usable. You might want to adjust the flags to disable some eye candy.
Why do the browsers “stutter” during scrolling?
In my understanding: Unfortunately browsers need a very high degree of control over their screen outputs, and thus they render it themselves, instead of letting Windows do it – RDP sees browser output as image, which is retransmitted when scrolling. Playing with image compression options might alleviate this problem a bit.
Will accessing Linux hosts over RDP work?
Not out of the box – you will need to install an X to RDP conversion software.
In a very quick and rough test, a connection set up by the Scarygliders X11 RDP O Matic as a server backend did not work reliably enough (it was installed on a Pentium IV Linux server). It might do so with some tuning.
Or another backend / solution might do the trick. Looking forward to your input
- Flash (isn’t it always on some list?) – will deliver horrible audio performance, native players (Foobar2000) will be OK, though.
- Video playback – don’t even dream of playing YouTube videos over an RDP connection … the time is not ready yet, the software not written. Care to join a noble cause?
- WLAN performance will depend on WLAN throughput and latency. The orientation of your dongle – especially nano dongles – will be very important. It can be tuned to a decent performance state, though.
- I can’t get the new / style switches to work with FreeRDP, fallback to the legacy – switches for now.
- Sound output: only rdpsnd works, –plugin drdynvc –data tsmf:audio:alsa:plughw:0,0 — will not work – maybe this is a configuration issue, though and some other parameters need to be passed. Drdynvc is said to have better quality. The issue might be with servers with no sound card drivers installed. I did not find an easy solution to this, and I am looking forward to your suggestions.
- Connection to Linux RDP server compiled with X11 RDP O Matic is not stable for me.
References & further reading
- Tao of Mac blog – original instructions – which I expanded upon here in this post.
- FreeRDP compilation instructions
- FreeRDP command line switches
- RPi ThinClient Project – RDP client is X-based, but it also has a selection of other protocols for you to use. Might be handy for an admin.
- Thinstation – Linux based OS intended for remote access to a broad selection of protocols. No Linux knowledge needed; runs on x86 hardware.
- directfb options (for the /etc/directfbrc ) – some more tuning might be possible
- More about the EDID
- Enable sound for RDP in Windows virtual machine