Remote X Windowing

1. Opening X windows on host computer

The basic approach to launch an X application running on target device on the host PC screen involves using Xnest. There are two major things to consider: network setup, and access policy.

Check your network setup and ensure that you have /etc/hosts set up correctly on both host and target, and that you can ping each machine using its name from the other end. You may still have to resort to using IP address in your DISPLAY variable to make things work.

To run Xnest:

$ Xnest :1 -ac -geometry 240x320 &

To launch an X program within Scratchbox make sure you're running the latest rootstrap version or otherwise confirm that all required libraries are installed. Also test CPU transparency with a command line program first.

[sbox-ARM: ~] > export DISPLAY=development-host:1.0 [sbox-ARM: ~] > ./helloworld-gtk ### INFO ### cpuTransparency! See /tmp/cputransp_user.log for details!

Try using IP address instead of hostname if you get the following error message:

_X11TransSocketINETConnect: Can't get address for development-host

Helloworld-gtk should now show up on the host screen. There is a some more information available on Xnest options at Wiki.

2. Opening X windows on remote computer

Opening windows in a remote computer (i.e. not the host) basically involves setting up the DISPLAY variable and access policies correctly. Basic packet routing must be set up correctly as well.

This was tested on the following setup:

You don't need to set up Xnest at all. Just set up DISPLAY variable and run the program:

[sbox-ARM: ~] > export DISPLAY=remote-host:0.0 [sbox-ARM: ~] > ./helloworld-gtk

If this does not work substitute remote IP address for hostname.

Tunneling X11 connections is also possible. This was tested using SSH Secure Shell 3.2.5 (build 280, evaluation). Tunneling works for local X applications running on the host. However this did not work with CPU transparency. Apparently the "routing" of X11 connections from target through host and all the way to the remote computer requires some configuration magic, which was not pursued further. In conclusion, distributed development work is easiest done on a LAN or secure WAN network, to avoid running into firewall and other security issues. This is also recommended by the Scratchbox developers.

3. Usability

Remote X windowing is only usable for certain purposes. On a USB-based network connection between host and target the speed is not very quick and response times tend to be on the low side. However, remote X windowing can be used to test the actual binary and check that all functionality is behaving as expected.

Besides speed, there is another issue with the fonts. Even if Xnest screen size is limited (pixel-wise) to the dimensions of the target screen, the typical desktop X font configuration is very different to that of e.g. Familiar. This makes user interface elements such as menus and dialogs appear very different on the desktop screen compared to the native target screen. Changing Xft font settings for the Xnest helps (DPI setting is required because some X software scales the font sizes according to display DPI setting):

$ echo "Xft.dpi: 75" > font.settings $ DISPLAY=development-host:1.0 xrdb -load font.settings