My friend recently asked me a question: "How the BLEEP do you get the BLEEPING remote X BLEEP to work with ubuntu as the server and a pi as the client?"
His use case scenario is very specific. He's running ubuntu 13.10. He's using a raspberry pi with raspbian as the distro. He wants his raspberry pi to be a thin client, or a terminal, for his server / workstation. After a few more questions back and forth I was told he wanted to use lightdm which is the default pre-installed display manager in both ubuntu and raspbian so you can easily do it in either direction.
So, let's go through how to do it. First on the server side which would be his ubuntu desktop machine you need to go to /etc/lightdm/lightdm.conf.d/. The configuration file has been split into multiple ones, so let's create a new one called 60-raspberry.conf. Add what you feel is necessary, mine looks like this.
enabled = true
start-default-seat = false
xserver-allow-tcp = true
allow-guest = false
That's it. That's all the configuration you need to do on a ubuntu system, server side. Next issue the command "service lightdm restart". You can verify that the X server is accepting network connections with "netstat -tcp -l".
Next let's move to the rapsberry, where zero configuration needs to be made. I decided to record the raspberry video in advance since I had to do HDMI recording of it. That's also why the resolution of it is lower, apologies for that.
As I said, it'll work fine out of the box since the XDMCP protocol is core to Xorg. All you need to do is log in with your username and start the Xorg server so it connects to the server. The following command will accomplish that "sudo Xorg -terminate -query 192.168.1.13 :0"
-terminate means it'll kill existing instances of X, -query that it'll query an ip that acts as a terminal server and :0 is which vt you want the server on. That's it. It's really that simple.
There's a number of things to keep in mind with this approach.
1. Your password is sent in cleartext if not tunneled over for instance SSH. This is not a good security practice, but my mate didn't seem to care and this is what he asked for. I'd recommend an encrypted tunnel.
2. Certain window managers, such as compiz and gnome shell, are accelerated and do a full refresh every single time a pixel is changed. This is totally fine for local use but it results in terrible performance when relayed over a network. I use XFCE as my desktop environment and XFWM4 as my window manager in this example, which works fine.
3. You'll be able to see a slight sluggishness in my video. Running a desktop over the network will automatically be slower than locally, but it's made worse by the fact that I use a usb wifi dongle on my raspberry. If you stick to regular ethernet it will be noticeably smoother.
4. XDMCP does not support sending relaying audio. If you play something you'll either hear no sound or hear the sound from the server, depending on your setup. There's multiple ways to fix this, a network aware sound server would be the simplest. But he didn't care about it so I didn't go into it.
Raspberry pi - http://www.raspberrypi.org/
Raspbian - http://www.raspbian.org/
Ubuntu - http://www.ubuntu.com/
Xorg - http://www.x.org/wiki/
None reported. Yet.