Jul 232013


We have released dfreerdp (FreeRDP for the DirectFB backend) as a package for the Raspberry Pi. Please go to our new blog post to get it!


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):

wget https://github.com/FreeRDP/FreeRDP/archive/1.0.2.tar.gz

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:


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/

sudo make install

#for sound support
cd ../../channels/drdynvc
sudo make install
cd ../rdpsnd
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:

# for other stuff


This will

  • 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

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:

# for the moment, we need DirectFB's own cursor sprite




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 Smile 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 Smile


Known problems

  • 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

Jul 232013


Auf dem Raspberry Pi befindet sich “von Werk aus” kein grafischer Netzwerk-Manager. Es ist also die Kommandozeile gefragt, was manchmal unbequem, lästig oder mit Fehlern verbunden sein kann.

Wir stellen in diesem Artikel daher kurz vor, wie man unter Raspbian mit Wicd einen grafischen Netzwerk-Manager aktiviert.


Öffnen Sie LXTerminal und installieren Sie die benötigten Pakete:

sudo aptitude update
sudo aptitude install wicd wicd-gtk wicd-curses


Nach Neustart von X erscheint in Ihrer Notification Area rechts unten ein neues Icon. Durch Klick auf dieses Icon können Sie sowohl LAN, als auch WLAN Netzwerke mit einer Vielzahl von Möglichkeiten verwalten.


Durch Rechtsklick auf das Icon, und Auswahl von “Connection Info” kann man seine aktuelle IP Adresse herausfinden:


Alternativ kann Wicd auch aus dem Menü gestartet werden:


Wicd zeigt die verfügbaren Funknetzwerke an:


Durck Klick auf “Connect” kann man sich zu einem Netzwerk verbinden. Falls es eine Passwort-Eingabe erfordert, weist Wicd den Nutzer darauf hin, und öffnet den “Properties” Dialog.

Für die meisten Netzwerke wird es hier nur erforderlich sein, den Preshared Key einzugeben. Wählen Sie aus dem Menü “WPA 1/2 (Passphrase)”, und geben Sie Ihren Preshared key ein.


Nach Klick auf OK drücken Sie erneut “Connect” um sich mit dem Funknetzwerk zu verbinden. Der Erfolg wird in der Statuszeile unten angezeigt:


WLAN Konfiguration unter der Konsole

Mit Wicd kann man die Funknetzwerkeinstellungen auch unter der Konsole – ohne X Session – verwalten. Geben Sie dazu einfach ein:

sudo wicd-curses


wicd-curses wird mit der Tastatur bedient. Das Menü unten zeigt die möglichen Eingaben an.

Mit Pfeiltaste nach rechts wird der aktuell ausgewählte Eintrag bearbeitet. Hier kann man die IP Einstellungen, die DNS Einstellungen und den Preshared Key eingeben. Außerdem kann festgelegt werden, dass eine Verbindung zu diesem Netzwerk automatisch hergestellt werden soll. Mit F10 bestätigt man die Einstellungen. Anschließend kann man Q drücken, um wicd-curses zu verlassen.

Weiterführende Informationen & Quellen

May 292013


I managed to get Weston running without compiling it from code first. Unfortunately, only the terminal was usable, X applications (midori, chromium, scratch) did not work. I spend the rest of the evening investigating, and would like to share some hints with you – information about Weston & Wayland is not easy to find.

If you want a working solution, come back in a couple of weeks – we will most probably have one for you. If you love to tinker, read on. This article will be a great starting base for exploration.


Installing Weston and Wayland

The following instructions are to be executed as root:

# echo deb http://raspberrypi.collabora.com wheezy rpi >> /etc/apt/sources.list
# apt-get update
# apt-get install weston

Accept the installation without known key. (You have to expressly enter “Y” for this).

Edit your /boot/config.txt and add the following lines at the end of the file: (hint: “sudo nano /boot/config.txt “)

#Settings for Weston to work


Edit your /etc/weston/weston.ini






The important lines are the two last ones – the launchers will unfortunately not work in my setup, as X does not work … The modules have to be loaded in EXACTLY this order – first xwayland, then desktop-shell. You also cannot omit desktop-shell – else weston will show a black screen only.

I am not sure, whether I am overriding (sensible?) defaults, as there is very little documentation on the topic as of yet.

Create a weston-starter script which will set up some variables: “ sudo nano /pi/home/weston-starter “ with the following contents:

#! /bin/bash

#export WLD="$HOME/local"
export WLD=""

export PATH="$WLD/bin:$PATH"
export LD_LIBRARY_PATH="$WLD/lib:/opt/vc/lib"
export PKG_CONFIG_PATH="$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/"
export ACLOCAL="aclocal -I $WLD/share/aclocal"
export XDG_RUNTIME_DIR="/tmp/wayland"
export XDG_CONFIG_HOME="$WLD/etc"
export XORGCONFIG="$WLD/etc/xorg-conf"

mkdir -p "$WLD/share/aclocal"
mkdir -p "$WLD/share/pkgconfig"
mkdir -p "$XDG_RUNTIME_DIR"
chmod 0700 "$XDG_RUNTIME_DIR"

#cp bcm_host.pc egl.pc glesv2.pc $WLD/share/pkgconfig/

#git clone git://anongit.freedesktop.org/wayland/wayland

weston --log=/tmp/weston.log

Again – these should very probably be adjusted, and MAY be the cause of the problem with the X-Server. I have adjusted them from a script a user used to compile weston.

The last line actually starts weston, and logs it’s output to /tmp/weston.log (normally this gets sent to the terminal, which is hidden by weston itself). Very handy to monitor from an SSH shell on a second computer.

Make it executable (chmod +x weston-starter).


OK. If everything goes well, you can start weston now.

pi@raspberrypi ~ $ ./weston-starter

(Be sure to start it as user pi – if you start it as root first, the temporary directory created in /tmp will not be accessible by pi. You can of course also chmod this directory to be world readable and writable /tmp/wayland )

Playing around with weston

You will be able to start multiple terminal instances, resize them and drag them around, and interact with the system via the terminals.

The second icon does not work for me. The third icon which I added to the configuration (to start Midori) neither.

Here are some nifty facts:

  • hit the Windows key to get into “expose mode”
  • hit Windows key + Tab to switch between open Windows
  • hold down Windows key and scroll the mouse to zoom into any area (this is pretty cool and pretty smooth)
  • Ctrl + Alt + Backspace terminates weston
  • Wayland has it’s own screenshot utility – it can’t be invoked from the command line, instead you have to press a shortcut (unfortunately I do not know which one). It may also be, that I disabled this screenshot utility by explicitly listing the modules to be loaded in the weston.ini


Showing off the zooming feature of Weston / Wayland. This is a pretty cool, dynamic feature, to which the still picture can do no justice.

The little there is to see REALLY impressed me. It is so fluid, so fast – I was not used to this from the Raspberry Pi and GUI applications before.


You will NOT be able to start any X application with my instructions. I suspect, that the X-Server which is installed from the default repositories does not support wayland!

Fatal server error:
X Unrecognized option: -wayland

If you have a look at file /usr/lib/weston/xwayland.so with the text editor somewhere in the file you will see the x server being called with this –wayland option. Trying to invoke it from the command line with it will yield the error message above, but I also managed to get it out of a starting wayland server somehow.

This can be also seen in the following logexcerpt ( /tmp/weston.log which we set up in our start script )

[23:38:20.556] xserver listening on display :0
[23:38:20.557] Loading module ‘/usr/lib/weston/desktop-shell.so’
[23:38:20.560] Compositor capabilities:
               arbitrary surface rotation: no
               screen capture uses y-flip: no
[23:38:20.560] libwayland: using socket /tmp/wayland/wayland-0
[23:38:20.562] launching ‘/usr/lib/weston/weston-desktop-shell’
[23:38:24.558] forked X server, pid 4635
[23:38:24.596] libwayland: disconnect from client 0x19ad188
[23:38:24.597] xserver crashing too fast: 256

All the fun stuff (Midori, LibreOffice, Chromium, …) is unfortunately not testable …

If you try to start Midori, it will yield the following error message:

Midori - Cannot open display:


Mock-FAQ, as no one asked (yet).


There seems to be no such program on the Raspberry Pi, yet. weston-launch passes parameters to weston with the following syntax: weston-launch — –modules=xwayland.so,desktop-shell.so

Note the double double dashes. weston itself takes only single double dashes in front of modules.

man weston

A good idea if you’re stuck with any Linux command is to look at it’s manpage. Weston is no exception, it ships with one which is quite handy.


To be done

We need to have LibreOffice running on Raspbian hardfloat under Weston & Wayland. This probably means compiling weston & wayland, and getting a special x server compatible with them. And this in turn means setting up a crosscompiling rig.

A quote from the manpage:

XWayland requires a special X.org server to be installed. This X server will connect to a Wayland server as a Wayland client, and X clients will connect to the X server. XWayland provides backwards compatibility to X applications in a Wayland stack.


Optimization WordPress Plugins & Solutions by W3 EDGE