The second critical item: configure the base X server not to use any input devices. By default the hardware X server will attach any keyboards and mice that it finds. To prevent it from doing that add the following line to the Server Layout:
Option "AutoAddDevices" "off"
Also for the default core input devices, both mouse and keyboard, set the device line to "/dev/null". Note this makes the X server somewhat inconvenient because it cannot be killed from a keyboard. I found that working on this setup remotely using SSH quite helpful.Since in this setup I am limited to a single real X server, my solution required the use of nested X servers. These servers are a client application to the real X server, and a server to clients that run on top of them. Two popular solutions are Xnest and Xephyr. Xephyr has a couple of advantages:
I spent a significant amount of time working with the Xephyr that is currently in the Meerkat repositories. It comes up. Applications can be run in them. But frustration set in because: The Xephyr in the Meerkat respositories DOES NOT HAVE EVDEV SUPPORT! It doesn't work. Period. After quite a bit of digging I found this bug report on the issue. The takeaway is The Xephyr version 2:1.7.6-2ubuntu7 in Lucid Lynx does have evdev support!. A simple repository add, update, and download later, and a working keyboard and mouse in Xephyr is going.
Xephyr has a second issue. The author and maintainer has refused to add a
geometry specifier for windows placement for Xephyr. So it is not
possible to position each Xephyr server in its proper place on the virtual
screen. Fortunately a simple workaround exists. Xephyr does has a -parent
option to overlay the Xephyr screen on top of an existing
window. The Two Desktops
Section of this Multiseat using One Card Tutorial describes the
process. xmessage is used as the carrier window. Multiple links are used so
that each xmessage can be identified and its window id extracted for the
parent option of Xephyr.
Configuring KDM
Since I run Kubuntu, KDM is my logon system. KDM will happily start and
support multiple X servers with some changes in the configuration file:
(/etc/kde4/kdm/kdmrc). My first efforts were focused on having KDM start
the Xephyr servers directly. If this route is taken the crucial item is
that: KDM will not run a shell script for the
ServerCmd. This led to lots of frustration. A tool that helped quite
a bit was this shell script
compiler that converts a script into a C program which can be exec'ed.
In my last go around, KDM refused to connect to my locally started X servers. I could not gather enough information from the log files to figure out why it was timing out. Finally I tried configuring KDM to drive the Xephyr servers as remote displays and Voila! they came up instanteanously. This requires that the base hardware X server and Xephyr nested servers be up and running before KDM is started. A small price to pay for working service.
I've done a lot of fiddling with the kdmrc. However, I believe that KDM service can be started on multiple Xephyr displays using a single change in the file. Change the StaticServers line so that is reads:
StaticServers=localhost:[display_for_seat1],localhost:[display_for_seat2],...
where display_for_seatX is the display number for the seat in question. In
my setup I arbitrarily used display numbers 5 and 6. Any values greater
than :0 should be fine. Because of the localhost specification, KDM will
not try to fire up a server for the screens.
Some quick notes:
The geometry spec needs both the windows size and position. The mousename
and kbname are the base name of the devices in the /dev/input/by-id
directory. Because of evdev, use the name of the device with the word event
in it. Typically mice will have two names, one with event
and one without..
Startup Scripts to get everything running
I started out with custom scripts for each seat. Changes in keyboards and
mice drove the realization that a generic config file based script would be
more effective. The result is the following script called doseat:
geometry:mousename:kbname
Challenges and leftovers
Here is the short list of what's left to be done:
Coda
I hope this document helps someone in their setup. There's a lot of info
floating around, but much of it is out of date, or incorrect. Feel free to
send any questions or suggestions for making this document better to byronjeff@mail.clayton.edu.