Home » Posts tagged 'X Window System'

Tag Archives: X Window System

A Better Mobile Display for the Raspberry Pi

2013-04-10 20.37.23

iSSH Terminal Session

As I described in an earlier post, I run my Raspberry Pi (RPi) as a headless system, using Cygwin/X‘s xterm for command line interaction with the RPi, with my PC being my X server to support any X Window applications.  I can move files between the PC and the RPi via my pseudo-Dropbox.  I really recommend this configuration and its working perfectly for me.

This configuration gives me a great deal of utility but no mobility …. I’m still tied to my desktop PC.  Maybe I should consider replacing the desktop PC with a laptop but I don’t want to spend the money.  I have seen some small,  inexpensive keyboards and displays that could be connected directly to the RPi, and you could cobble together a mobile unit, or the more elegant Kindle version, but this still doesn’t give me the mobility look & feel I would like.

iPad to the rescue (assuming you have one ….)!   I found a great app call iSSH by Zingersoft.  Its claims that it is a “comprehensive VT100, VT102, VT220, ANSI, xterm, and xterm-color terminal emulator over SSH and telnet, integrated with a tunneled X server, RDP and VNC client. ”   I installed it, configured it quickly, and got  a terminal connection to the RPi without reading the documentation …. Impressive since successfully configuring ssh, Xserver, etc. can be challenging sometimes.  (Note: The easy of this was largely due to setting up RPi environment properly in the first place. See the earlier post).  To top it off, iSSH has a slick look & feel.

Configuring iSSH

iSSH X Server Session

iSSH X Server Session

Zingersoft’s documentation on configuring iSSH is easy to follow and requires just a few steps.  I had no problem getting an terminal session working to the RPi but I did have problems with graphics programs (i.e. X Window client programs).  It appears that iSSH’s terminal isn’t really xterm but a terminal emulation (secured via ssh).  The iSSH terminal doesn’t use the X server.  In fact, while in the terminal session,  to see the X server display (i.e. to see graphics applications rendered via the RPi X client) you must hit the button at the top right of the iPad display.

Frankly, the fact that the X application didn’t work the first time wasn’t a big surprise to me.  I have been struggling with getting my X Window configuration set up to work reliably for some time.  What I was observing was that X would work fine for sometime but at some point I would get the error message “couldn’t connect to display”.

This error is very common and nearly every X user has seen some version of this before.  I assume that the right way to solve this was to gain a deeper understanding of X Windows and discover its root cause .  I did gain a deeper understanding of X Windows, but a solution to my problem never jumped out from the “official” materials I read.  I found the solution when I happened upon the blog “X11 Display Forwarding Fails After Some Time“.

The root cause of my error message is the time out of the X Forwarding.  I have been using the -X option when using ssh.  This is the more secure option for X Forwarding, but comes at a price, as shown below.

    • Using ssh -X, X forwarding is enabled in “Untrusted” mode, making use of various X security extensions, including a time-limited Xauth cookie.
    • Use ssh -Y to enable “Trusted” mode for X, which will enable complete access to your X server. There is no timeout for this option.

So my Display problem isn’t really an error, per say, but ssh timing out on me.  To fix this, I added the entry ForwardX11Timeout 596h into my ~/.ssh/config file on my PC.  With this problem solved, I continued my journey into X.

My Journey to a Better Understanding of X

Using X Windows for the first time can be somewhat of a shock to someone familiar with other graphical environments, such as Microsoft Windows or Mac OS.  X was designed from the beginning to be network-centric, and uses a “client-server” model. In the X model, the “X server” runs on the computer that has the keyboard, monitor, and mouse attached. The server’s responsibility includes tasks such as managing the display, handling input from the keyboard and mouse, and other input or output devices (i.e., a “tablet” can be used as an input device, and a video projector can be an output device, etc.). Each X application (such as xterm) is a “client”. A client sends messages to the server requesting things like “Please draw a window at these coordinates”, and the server sends back messages such as “The user just clicked on the OK button”. These standardized set of messages make up the X Protocol.

The X server and the X clients commonly run on the same computer. However, it is perfectly possible to run the X server on a less powerful computer (e.g. in my case a PC or iPad), and run X applications (the clients) on a powerful machine that serves multiple X servers (or it can be a simple RPi, as in my case). In this scenario the communication between the X client and server takes place over the network (WiFi for my iPad), via the X Protocol. There is nothing in the protocol that forces the client and server machines to be running the same operating system, or even to be running on the same type of computer.

The Display

It is important to remember that the X server is the is the software program which manages the monitor, keyboard, and pointing device. In the X window system, these three devices are collectively referred to as the “display”.  Therefore, the X server serves displaying capabilities, via the display, to other programs, called X clients, that connect to  the X server.  All these connections are established via the X protocol.

The relationship between the X server and the display are tight, in that the X server is engineered to support a specific display (or set of displays).  As a user of X, you don’t have any control over this relationship, only the software developer who created the server can modify this relationship (generally speaking).  On the other hand, as a user you have free hand in configuring the X protocol connection between the X server and the X clients.

How do you establish a X Protocol connection between any given server and a client?  This is done via the environment variable “DISPLAY”.  A Linux environment variable DISPLAY tells all its X clients what display they should use for their windows. Its value is set by default in ordinary circumstances, when you start an X server and run jobs locally. Alternatively, you can specify the display yourself.  One reason to do this is when you want log into another system, and run a X client there, and but have the window displayed at your local terminal.  That is, the DISPLAY environment variable must point to your local terminal.

So the environment variable “DISPLAY” stores the address for X clients to connect to. These addresses are in the form: hostname:displaynumber.screennumber where

    • hostname is the name of the computer where the X server runs. An omitted hostname means the localhost.
    • displaynumber is a sequence number (usually 0). It can be varied if there are multiple displays connected to one computer.
    • screennumber is the screen number. A display can actually have multiple screens. Usually there’s only one screen though where 0 is the default.

Setting the DISPLAY variable depends of your shell, but for the Bourne, Bash or Korn shell, you could do the following to connect with the systems local display:

export DISPLAY=localhost:0.0

The remote server knows where it have to redirect the X network traffic via the definition of the DISPLAY environment variable which generally points to an X Display server located on your local computer.

X Security

So you see, as the user, you have full control over where you wish to display the X client window.   So what prevents you from doing something malicious,  like popping up window on someone else  terminal or read their key strokes?  After all, all you really need is their host name.  X servers have three ways of authenticating connections to it: the host list mechanism (xhost) and the magic cookie mechanism (xauth). Then there is ssh, that can forward X connections, providing a protected connection between client and server over a network using a secure tunnelling protocol.

The xhost Command

The xhost program is used to add and delete host (computer) names or user names to the list of machines and users that are allowed to make connections to the X server. This provides a rudimentary form of privacy control and security.  A typical use is as follows: Let’s call the computer you are sitting at the “local host” and the computer you want to connect to the “remote host”. You first use xhost to specify which computer you want to give permission to connect to the X server of the local host. Then you connect to the remote host using telnet. Next you set the DISPLAY variable on the remote host. You want to set this DISPLAY variable to the local host. Now when you start up a program on the remote host, its GUI will show up on the local host (not on the remote host).

For example, assume the IP address of the local host is and the IP address of the remote host is

On the local host, type the following at the command line:

xhost +

Log on to the remote host


On the remote host (through the telnet connection), instruct the remote host to display windows on the local host by typing:

export DISPLAY=

Now when you type xterm on the remote host, you should see an xterm window on the local host.  You should remove the remote host from your access control list as follows.

xhost -

Some additional xhost commands:

xhost    List all the hosts that have access to the X server
xhost + hostname    Adds hostname to X server access control list.
xhost - hostname    Removes hostname from X server access control list.
xhost +     Turns off access control (all remote hosts will have access to X server … generally a bad thing to do)
xhost -    Turns access control back on (all remote hosts blocked access to X server)

Xhost is a very insecure mechanism. It does not distinguish between different users on the remote host. Also, hostnames (addresses actually) can be spoofed. This is bad if you’re on an untrusted network.

The xauth Command

Xauth allows access to anyone who knows the right secret. Such a secret is called an authorization record, or a magic cookie. This authorization scheme is formally called MIT-MAGIC-COOKIE-1.  The cookies for different displays are stored together in the file .Xauthority in the user’s home directory (you can specify a different cookie file with the XAUTHORITY environment variable).  The xauth application is a utility for accessing the .Xauthority file.

On starting a session, the X server reads a cookie from the.Xauthority file. After that, the server only allows connections from clients that know the same cookie (Note: When the cookie in .Xauthority changes, the server will not pick up the change.).  If you want to use xauth, you must start the X server with the -auth authfile argument.   You can generate a magic cookie for the .Xauthority file using the utility mcookie (typical usage: xauth add :0 . `mcookie`).

Now that you have started your X session on the server and have your cookie in .Xauthority, you will have to transfer the cookie to the client host. There are a few ways to do this.  The most basic way is to transfer the cookie manually by listing the magic cookie for your display with xauth list and injecting it into the remote hosts .Xauthority via the xauth utility.

Xauth has a clear security advantage over xhost. You can limit access to specific users on specific computers and it does not suffer from spoofed addresses as xhost does.

X Over SSH

Even with the xhost and xauth methods, the  the X protocol is transmitted over the network with no encryption.  If you’re  worried someone might snoop on your connections (and you should worry), use ssh.  SSH, or the Secure Shell, allows secure (encrypted and authenticated) connections between any two devices running SSH. These connections may include terminal sessions, file transfers, TCP port forwarding, or X Window System forwarding.  SSH supports a wide variety of encryption algorithms. It supports various MAC algorithms, and it can use public-key cryptography for authentication or the traditional username/password.

SSH can do something called “X Forwarding” makes the communication secure by “tunneling” the X protocol over the SSH secure link.  Forwarding is a type of interaction with another network application, through a inter-mediator, in this case SSH. SSH intercepts a service request from some other program on one side of an SSH connection, sends it across the encrypted connection, and delivers it to the intended recipient on the other side. This process is mostly transparent to both sides of the connection: each believes it is talking directly to its partner and has no knowledge that forwarding is taking place.  This is called tunneling since X protocol is encapsulated within the a SSH protocol.

When setting up an SSH tunnel for X11, the Xauth key will automatically be copied to the remote system(in a munged form to reduce the risk of forgery) and the DISPLAY variable will be set.

To turn on X forwarding over ssh, use the command line switch -X or write the following in your local ssh configuration file:

Host remote.host.name
ForwardX11 yes

The current version of SSH supports the X11 SECURITY extension, which provides two classes of clients: trusted clients, which can do anything with the display, and untrusted clients, which cannot inject synthetic events (mouse movement, keypresses) or read data from other windows (e.g., take screenshots). It should be possible to run almost all clients as untrusted, leaving the trusted category for screencapture and screencast programs, macro recorders, and other specialized utilities.

If you use ssh -X remotemachine the remote machine is treated as an untrusted client and ssh -Y remotemachine the remote machine is treated as trusted client.  ‘-X’ is supposedly the safe alternative to ‘-Y’.  However, as a Cygwin/X maintainer says “this is widely considered to be not useful, because the Security extension uses an arbitrary and limited access control policy, which results in a lot of applications not working correctly and what is really a false sense of security”.

You can configuring SSH via the following files:

    • per-user configuration is in ~/.ssh/config
    • system-wide client configuration is in /etc/ssh/ssh_config
    • system-wide daemon configuration is in /etc/ssh/sshd_config

The ssh server (sshd) at the remote end automatically sets DISPLAY to point to its end of the X forwarding tunnel. The remote tunnel end gets its own cookie; the remote ssh server generates it for you and puts it in~/.Xauthority there. So, X authorization with ssh is fully automatic.

X over SSH solves some of the problems inherent to classic X networking. For example, SSH can tunnel X traffic through firewalls and NAT, and the X configuration for the session is taken care of automatically. It will also handle compression for low-bandwidth links.  Also, if you’re using X11 forwarding, you may want to consider setting ForwardX11Trusted no to guard against malicious clients.

The Window Manager

The X design philosophy is much like the Linux/UNIX design philosophy, “tools, not policy”.  This philosophy extends to X not dictating what windows should look like on screen, how to move them around with the mouse, what keystrokes should be used to move between windows, what the title bars on each window should look like, etc.  Instead, X delegates this responsibility to an application called a “Window Manager”.

There are many window managers available for X and each  provides a different look and feel.  Some of them support  highly configurable virtual desktops like, KDE and GNOME, some of them are lightweight desktop like LXDE which comes with the RPi, or you can operate bare bones (like I am on my PC while using the RPi) and let MS Windows be your Window Manager via Cygwin/X.  The iPad’s iSSH can run without a Window Manager.  In effect, X server uses the display as it sees fit and your unable to control where things loaded. iSSH does have a Window Manage your can use as an option called dwm.  Its a tiling window manager, which is a reasonable way to go given that your pointing device is your finger on the iPad.

X Display Manager

The X Display Manager (XDM) is an optional part of the X Window System that is used for login session management.  XDM provides a graphical interface for choosing which display server to connect to, and entering authorization information such as a login & password.  Like the Linux getty utility, it performs system logins to the display being connected to and then runs a session manager on behalf of the user (usually an X window manager).  XDM then waits for this program to exit, signaling that the user is done and should be logged out of the display. At this point, XDM can display the login and display chooser screens for the next user to login.

In the small world of my RPi’s, a PC, and an iPad, I have no need for an XDM and don’t use one.

Enough of the X Journey … Now in Conclusion

So what does the iSSH give me? I can now sit on the couch, watch TV, and simultaneously login into the RPi with full X Windows support.  Some would call this Nirvana but I call it just VERY NICE.  The iPad/iSSH combination isn’t the perfect user experience but Zingersoft did a good job.

By the way …. the above iPad screen shot of the X Server display with a globe was rendered using the following code:

#!/usr/bin/env python

    Source: http://www.scipy.org/Cookbook/Matplotlib/Maps

from mpl_toolkits.basemap import Basemap
import matplotlib.pyplot as plt
import numpy as np

Use_NASA_blue_marble_image = False

# set up orthographic map projection with
# perspective of satellite looking down at 50N, 100W.
# use low resolution coastlines.
# don't plot features that are smaller than 1000 square km.
map = Basemap(projection='ortho', lat_0=50, lon_0=-100, resolution='l', area_thresh=1000.)

# draw coastlines, country boundaries, fill continents.
if Use_NASA_blue_marble_image:

# draw the edge of the map projection region (the projection limb)

# draw lat/lon grid lines every 30 degrees.
map.drawmeridians(np.arange(0, 360, 30))
map.drawparallels(np.arange(-90, 90, 30))

# lat/lon coordinates of five cities.
lats = [40.02, 32.73, 38.55, 48.25, 17.29]
lons = [-105.16, -117.16, -77.00, -114.21, -88.10]
cities = ['Boulder, CO', 'San Diego, CA', 'Washington, DC', 'Whitefish, MT', 'Belize City, Belize']

# compute the native map projection coordinates for cities.
x, y = map(lons, lats)

# plot filled circles at the locations of the cities.
map.plot(x, y, 'bo')

# plot the names of those five cities.
for name, xpt, ypt in zip(cities, x, y):
        plt.text(xpt + 50000, ypt + 50000, name)

# make up some data on a regular lat/lon grid.
nlats = 73
nlons = 145
delta = 2. * np.pi / (nlons - 1)
lats = (0.5 * np.pi - delta * np.indices((nlats, nlons))[0, :, :])
lons = (delta * np.indices((nlats, nlons))[1, :, :])
wave = 0.75 * (np.sin(2. * lats) ** 8 * np.cos(4. * lons))
mean = 0.5 * np.cos(2. * lats) * ((np.sin(2. * lats)) ** 2 + 2.)

# compute native map projection coordinates of lat/lon grid.
x, y = map(lons * 180. / np.pi, lats * 180. / np.pi)

# contour data over the map.
CS = map.contour(x, y, wave + mean, 15, linewidths=1.5)


Conky for the Raspberry Pi

Conky  is a Linux system monitor tool using X Windows.  Conky is highly configurable and is able to monitor many system variables including the status of the CPU, memory, swap space, disk storage, temperatures, processes, network interfaces, battery power, system messages, e-mail in-boxes  Linux updates, runs many popular music players, and much more. Unlike system monitors that use high-level widget tool-kits to render their information, Conky is drawn directly in an X window, allowing it to consume relatively fewer system resources.

To install the standard Conky package, use the following:

sudo apt-get install conky-std

Two sites you will want to read, beyond the Conky manual page are the lists of Config Settings and Variables. You use the Config Settings to describe general features of how you want your Conky to appear, and the variables to define what actually gets displayed.

The color names that are used within Conky are the X11 colors located in /usr/share/X11/rgb.txt.  There isn’t a standard set of colors to be found on any X Window system, so you’ll need to inspect this file to get some idea of what color names you can use.  This X color name list, which appears to be larger than what is in the RPi’s rgb.txt file, could help you visualized the colors.

Conky uses a configuration file location in $HOME/.conkyrc.  Conky can be configured in an amazing number of way but I’m using the following configuration on the RPi:

# --------------------------------------------------------------------------------------------- #
# .conkyrc - derived from various examples across the 'net
# Some of the sites that proved most usful include:
#   http://mylinuxramblings.wordpress.com/2010/03/23/how-to-configure-the-conky-system-monitor/`
#   http://crunchbanglinux.org/wiki/conky
#   http://lusule.wordpress.com/2008/08/07/how-to-4/
# --------------------------------------------------------------------------------------------- #

# -------------------- Conky's Run Time Parameters -------------------- #

update_interval 2.0                     # Conky update interval in seconds
total_run_times 0                       # Number of updates before quitting.  Set to zero to run forever.
no_buffers yes                          # Subtract file system buffers from used memory?
cpu_avg_samples 2                       # Number of cpu samples to average. Set to 1 to disable averaging
net_avg_samples 2                       # Number of net samples to average. Set to 1 to disable averaging

# -------------------- Conky's General Look & Feel -------------------- #

# --- defualt values --- #
default_color grey                      # Default color and border color
default_bar_size 0 6            # Specify a default width and height for bars.
default_gauge_size 25 25        # Specify a default width and height for gauges.
default_graph_size 0 25         # Specify a default width and height for graphs.
default_outline_color green     # Default border and text outline color
default_shade_color yellow      # Default border and text shading color

# --- predefined colors - http://www.kgym.jp/freesoft/xrgb.html --- #
color0 FFFFFF                           # white
color1 FFA500                           # orange
color2 B22222                           # firebrick
color3 696969                           # dim gray
color4 D3D3D3                           # light gray
color5 2F4F4F                           # dark slate gray
color6 FFEC8B                           # light golden rod
color7 54FF9F                           # sea green
color8 FF8C69                           # salmon
color9 FFE7BA                           # wheat

# --- window layout & options --- #
own_window yes                          # Conky creates its own window instead of using desktop
own_window_type normal          # If own_window is yes, use type normal, desktop, or override
own_window_transparent yes      # Use pseudo transparency with own_window?
own_window_colour blue          # If own_window_transparent is no, set the background colour
double_buffer yes                       # Use double buffering (reduces flicker)
use_spacer right                        # Adds spaces to stop object from moving
maximum_width 600                       # Maximum width of window in pixels
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager

# --- window placment --- #
alignment top_right

# --- borders, margins, and outlines --- #
draw_graph_borders yes          # Do you want to draw borders around graphs
border_inner_margin 9           # Window's inner border margin (in pixels)
border_outer_margin 5           # Window's outer border margin (in pixels)
gap_x 10                                        # Gap between borders of screen and text (on x-axis)
gap_y 40                                        # Gap between borders of screen and text (on y-axis)
border_width 10                         # Window's border width (in pixels)

# --- Text --- #
draw_outline no                         # Do you want ot draw outlines
draw_shades no                          # Do you want to draw shades
draw_borders no                         # Do you want to draw borders around text
uppercase no                            # set to yes if you want all text to be in uppercase
use_xft yes                                     # use the X FreeType interface library (anti-aliased font)
xftfont Monospace:size=8:weight=bold    # Xft font to be used

# -------------------- Conky's Displayed System Monitoring Parameters -------------------- #
# Title / Banner message
${alignc 40}${font Arial Black:size=22}${time %H:%M:%S}${font}
${alignc}${time %A} ${time %B} ${time %d}, ${time %Y}

# General system information
${color1}SYSTEM INFORMATION ${hr 2}$color
${color0}System: $color$nodename ${alignr}${color0}Uptime: $color$uptime
${color0}Kernel: $color$kernel${alignr}${color0}Arch: $color$machine
${color0}Frequency: $color$freq MHz
${color0}Serial No.: $color${execi 99999 grep Serial /proc/cpuinfo | awk '{ print $3 }'}
${color0}MAC Address: $color${execi 99999 cat /sys/class/net/eth0/address }

# CPU information
${color1}CPU ${hr 2}$color
${color0}Avg. Load: $color $loadavg
${color0}CPU Temperature: $color${acpitemp}°C
${color0}CPU Usage:$color $cpu% ${color7}${cpubar}
${cpugraph 0000ff 00ff00}$color

# Top running processes
${color1}TOP 5 PROCESSES ${hr 2}$color
${color0}Processes:$color $processes  ${color0}Running:$color $running_processes
${stippled_hr 2}
${color0}CPU Usage$color
${color3} NAME              PID    CPU %   MEM$color
${color2} ${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1}$color
 ${top name 2} ${top pid 2} ${top cpu 2} ${top mem 2}
 ${top name 3} ${top pid 3} ${top cpu 3} ${top mem 3}
 ${top name 4} ${top pid 4} ${top cpu 4} ${top mem 4}
 ${top name 5} ${top pid 5} ${top cpu 5} ${top mem 5}
${stippled_hr 2}
${color0}Mem Usage$color
${color3} NAME              PID    CPU %   MEM$color
${color2} ${top_mem name 1} ${top_mem pid 1} ${top_mem cpu 1} ${top_mem mem 1}$color
 ${top_mem name 2} ${top_mem pid 2} ${top_mem cpu 2} ${top_mem mem 2}
 ${top_mem name 3} ${top_mem pid 3} ${top_mem cpu 3} ${top_mem mem 3}
 ${top_mem name 4} ${top_mem pid 4} ${top_mem cpu 4} ${top_mem mem 4}
 ${top_mem name 5} ${top_mem pid 5} ${top_mem cpu 5} ${top_mem mem 5}

# Memory and swap space untilization
${color1}MEMORY & SWAP ${hr 2}$color
${color0}RAM Usage: ${color}$mem / $memmax
$memperc% ${color6}${membar}$color
${stippled_hr 2}
${color0}Swap Usage: ${color}$swap / $swapmax
$swapperc% ${color6}${swapbar}$color

# File System utilization
${color1}FILE SYSTEM ${hr 2}$color
${color0}SD Card:$color ${fs_used /} / ${fs_size /}
${fs_used_perc /}% ${color8}${fs_bar /}$color
${stippled_hr 2}
${color0}Reads: $color$diskio_read/s${alignr}${color0}Writes: $color$diskio_write/s
${color8}${diskiograph_read 20,100 33FF00 FF3333 scale -t}$color${alignr}${color8}${diskiograph_write 20,100 33FF00 FF3333 scale -t}$color

# Ethernet utilization
${color1}NETWORKING ${hr 2}$color
${color0}Wired (${addr eth0})
${color0}Down:$color ${downspeed eth0}/s ${alignr}${color0}Up:$color ${upspeed eth0}/s
${color0}Total:$color ${totaldown eth0} ${alignr}${color0}Total: $color${totalup eth0}
${color0}${downspeedgraph eth0 25,120 000000 00ff00} ${alignr}${upspeedgraph eth0 25,120 000000 ff0000}$color
${stippled_hr 2}
${color0}Wireless (${addr wlan0})
${color0}Down:$color ${downspeed wlan0}/s ${alignr}${color0}Up:$color ${upspeed wlan0}/s
${color0}Total:$color ${totaldown wlan0} ${alignr}${color0}Total: $color${totalup wlan0}
${color0}${downspeedgraph wlan0 25,120 000000 00ff00} ${alignr}${upspeedgraph wlan0 25,120 000000 ff0000}$color

# Print the tail of the Linux message log
${color1}LOG FILES ${hr 2}$color
${color0}Linux Message Log$color
${color4}${font Arial:size=6}${execi 30 tail -n3 /var/log/messages | fold -w50}$color$font

Debugging Conky

An easy way to force Conky to reload your ~/.conkyrc configuration file is to us the command killall -SIGUSR1 conky. This saves you the trouble of having to kill and then restart.  I also discovered that  while conky is running and your concurrently editing the .conkyrc file in vi, saving the file appears to cause conky to restart and read the new .conkyrc … nice.

Establishing an X Window System environment for my PC and Raspberry Pi

As stated in an earlier post, I plan to run my Raspberry Pi (RPi) as an attached device to my homes LAN and use my MS Windows PC to access the RPi.  The RPi will use my PC for display output and key board / mouse as input.  With the X Window System on the RPi, I can transmit an entire RPi desktop if I wish (using LXDE and it would look and feel much like VNC).  I find this cumbersome since now your dealing with two desktop environments: MS Windows desktop and  X Window System based desktop all one display.

There is an alternative way. One of the cool things about the X architecture is that it can use MS Windows as your window manager (at least with the tools like Cygwin/X, Xming, and MI/X) but the application within the window frame can be the RPi based X Window System application.  Now you have a single desktop (MS Windows) but your running RPi application within a MS Windows window.  And with this configuration, you can run both Linux programs within a standard terminal window and graphic  X Window System applications in another window.

For me this is clearly the way to go.  It will allow me to hop on my PC, and with a double-click on a desktop icon, get me to a password prompt on the RPi.  Enter the password, and I can immediately run both command line and X graphics application on the RPi, along side MS Windows applications, all concurrently on a single desktop.

How I did this, along with some background information, is provide below.

X Window System

The X Window System (commonly referred to as X Windows or just X or X11) is a software system and network protocol that provides a basis for graphical user interfaces (GUIs) and rich input device capability for networked computers.

X uses a client/server model, but appears backwards when you first learn of X.  In X, it’s the server that runs on the local machine (the PC), providing its services to the display based on requests from client programs that may be running remotely (the RPi). Within a X Window System, a client can also run locally. The server also manages the input devices (your keyboard and mouse), and it manages the display of colors and fonts on the screen, all based on requests from a client.

One of the most significant features of X is that it was specifically designed to work across a network. The client and the server communicate via the X Protocol, a network protocol that can run locally or across a network. Regardless of whether a client program is local or remote, it communicates with the server through the X Protocol.

X Window System Components

A X Window System consist of several components which work together.  They are:

    • X Server – manages the display, based on requests from the window manager.
    • Window Manager – is an application that is itself an X client, with responsibility for managing the appearance and placement of the windows on the screen.   The window manager takes care of the appearance and placement of the windows; it doesn’t determine what goes on inside.
    • Windows – are the X clients, typically providing user functionality.  Windows are fully in control of the application but their placement, geometry  etc. are controlled by the window manager.
    • Display Manager – runs as a program that allows the starting of a session on an X server from the same local or remote computer A display manager presents the user with a login screen which prompts for a username and password. A session starts when the user successfully enters a valid combination of username and password.
        • When the display manager runs on the user’s computer, it starts the X server before presenting the user the login screen, optionally repeating when the user logs out.
        • When the display manager runs on a remote computer, it acts like a telnet server, requesting username and password and starting a remote session.
    •  Desktop Environment – go further than a window manager in providing an integrated graphical environment where all applications and windows have a common look and feel. The desktop environments also include session management, for saving and restoring your work sessions.

In the spirit of user-friendliness and security, the desktop and display manager hides much of the X Window System and its’ subtleties.  If you want to really explore X (and light its load on the RPi), it’s helpful to run with just a window manager for a while (even if you plan to go back to the desktop).  That is what I plan to do.

Cygwin’s X Server and Window Manager

Before you can run a X client, you need to start the X server.  You can run the X server in two ways: it will automatically start if your Linux is configured with a X Display Manager (XDM), and if not, at the Linux command line you can start X manually.  It is the latter that I want to do on my PC / RPi combination (and the way my RPi distribution Occidentalis is pre-configured).   Also, in my configuration, I’ll be using the Cygwin  X server on the PC, and no server will be running on the RPi, only X clients.

Now there are some important capabilities within the Cygwin X server.  Cygwin/X can work with its window managers  in several different ways.

    • Internal window manager – The internal window manager creates a MS Windows window for each top-level X window.  This window manage is “internal” to the Cygwin X server.
    • External local window managers –  These local window managers must be installed on Cygwin and runs on the PC (e.g. twm, mwm, fvwm2, openbox, aewm++, WindowMaker).
    • Remote window managers – This would be a situation where the window manager is on the RPi and would connect via a remote sessions using XDMCP (X Display Manager Control Protocol).

I plan to keep things simple and use the Cygwin internal window manage.

XWin is the X Server for the X Window System on the Cygwin environment running on Microsoft Windows. It can operate in three different modes:

    • Single Window – This is the default mode. Each X screen appears as a single MS Windows window and all X windows are contained within this window. (In X terminology, the MS Windows window contains the root window for the screen.)
    • Multi-Window – In this mode XWin uses its own integrated window manager in order to handle the top-level X windows, in such a way that they appear as normal MS Windows windows.
    • Rootless In this mode the X server works in a window containing the whole screen but this root window (traditionally covered with an X hatch pattern) is hidden from view, so only top-level X windows are seen.

To get a better idea on what the different modes can provide you from a user experience perspective, check out some Cygwin/X screen shots.   Again, my objectives are to keep things simple and clean, so I will be using the multi-window mode.

Configuring Cygwin/X

To operate Cygwin/X in multi-window mode you use the command startxwin (You use startx for window mode.  startxwin is a specialized version of startx with a few differences appropriate to running in multi-window mode, rather than windowed mode).  The startxwin program has a resource file called .startxwinrc.  You can create a ~/.startxwinrc script to start client programs, such as mintty or xterm. An example .startxwinrc file  is:

mintty --position 100,100 --size 80,50
mintty --position 150,150 --size 80,50
mintty --position 600,500 --size 80,25 --exec ssh -X pi@raspberrypi.local

This will open up two xterm windows for your in the left hand corner of the screen and a thrid xterm window in the center of the screen.  This third screen is automatically logging in to the RPi as user pi and will wait four you to enter the password.

Also make sure that you export your DISPLAY for the X server on your PC.  You can do this by placing the following in your .bashrc file:

# environment variables required by X Window System
export DISPLAY=:0.0

Configuring RPi

Not much needs to be done to the RPi to prepare for the X applications.  You may wish to launch some X Window System application upon logging in.  You can do this by adding the X applications to your .bash_profile.  For example, add the following line to launch the LXDE file manager:

# execute X Window System programs
pcmanfm &

Starting and Stopping the Cygwin X Server

The environments are now set.  Time to start the X Server. The easiest way for starting Cygwin/X is using the “XWin Server” shortcut under “Cygwin-X” on the Start Menu or on the MS Windows desktop. You could also type startxwin on the Cygwin command line.

As to stopping the X Server, for the window mode I’m working in (multi-window), stopping Cygwin/X can be done by  Selecting the “Exit…” option from the notification area icon menu.

How Does It Look

So given the configuration discussed above, your get a nice clean display with MS Windows, Cygwin, RPi command line, and RPi X Window application running in a single windows management environment.  Picture provided below:

You thought the Raspberry Pi was a simple little hardware hackers computer …. but its running like a big dog now!


Much of what is provided here was lifted from the following sources:

%d bloggers like this: