特殊:Badtitle/NS100:MultiseatX

{{#ifexist: :MultiseatX/zh | | {{#ifexist: MultiseatX/zh | | {{#ifeq: {{#titleparts:MultiseatX|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:MultiseatX|1|-1|}} | zh | | }}

Multiseat X is a where one machine is attached to several sets of keyboards, mice, and monitors, which can operate independently of each other -- each under the control of a different user. Contrast this with multi-head X, in which a single keyboard and mouse is associated with two or more screens. In theory, there are several different ways to achieve multi-seat; in practice there are very few approaches which are both simple and stable.

Ubuntu 6.06 (Dapper Drake)

There are two different implementations of Multiseat X available in 6.06. There is a rudimentary multiseat version in xorg 7.0 itself, as well as the desktop-multiplier package by Userful in multiverse.

Xorg version

[ As of `xorg` version 7.0/6.9 (7.0 is provided in Ubuntu 6.06), there is rudimentary multiseat support built into X. It is not well documented or mature, but many people are reporting successful multiseat configurations. The instructions given here for multiseat configuration are based on [mini-howto by Chris Tyler, but contain further refinements over that approach.

{i}

The most major difference between my configuration here and that suggested by Chris Tyler is the addition of a "dummy" X session. According to XOrg design documents, the first X session is responsible for managing certain global parameters which subsequent X sessions utilise. I decided to create a "dummy" X session just to fill this role, so that all subsequent X sessions would be equals. This worked spectacularly well for me: I could not get multiseat to work reliably without it, but it seems very solid with the addition of the "dummy" session. Details of this approach are given as the configuration is explained below. -- The Famous Brett Watson >

/!\

Much of this section is written in the first person, which isn't the best of ideas in a Wiki. I've felt the need to do this, since this documentation describes one particular successful experiment, rather than being a general set of instructions from first principles. Others are welcome to edit this section, of course, although you may want to offset your comments in a text box like this to distinguish your experiences from mine. -- The Famous Brett Watson >

Requirements and Outcomes

You will require a separate keyboard, mouse, and graphics card for each seat. Graphics cards with dual outputs can not, in general, be used for separate seats using this method, although they can be used to create a seat with dual monitors.

{i}

This limitation with regards to dual-output cards may well be driver-dependent. In my attempts to make the outputs on an NVidia 6200 card behave independently, I have found that the second X server always deactivates the other output. My guess is that the `nvidia` driver is programmed in such a way that it presumes complete ownership of the device. There may be specific cards and drivers which can operate their outputs as separate X sessions. If anyone knows of such exceptions, please document them here. -- The Famous Brett Watson >

[ | {i} || There is also another limitation concerned about the graphics card vendor. This multiseat solution only works with nvidia and matrox cards. We like to call it as hardware dependence, because it only works with a restricted set of hw. On the other hand we call hardware independence for the [solution. -- TiagoVignatti >

The outcome will be several separate "X terminals" attached to a common host. Each terminal will start with a separate, independent `gdm` login screen. Only the keyboards, mice, and monitors are managed, however: nothing in this configuration causes other devices (such as removable media and audio) to be cleverly allocated to specific logged-in users. Note also that this multiseat configuration results in the loss of text-mode virtual terminals: it will not be possible for any user to switch to text mode using ALT-Fn keystrokes while multiseat X is in operation.

{i}	Another thing that I lost unexpectedly was video overlays. I'm not entirely sure why this happened: it may be a quirk of the `nvidia` driver. OpenGL graphics continued to work well. -- The Famous Brett Watson >

The configuration process will involve manual editing of the "xorg.conf" and "gdm.conf-custom" files. Misconfiguring these files can result in loss of the graphical user interface, or (in severe cases) a system which locks itself up. Some prior experience with this kind of configuration editing will be helpful. On the plus side, there's no need for any additional software: this is purely a matter of configuration.

Know Your Devices

In the `xorg` configuration, we will have to identify particular graphics devices and input devices. We start by finding them in our system, and making a note of their addresses. The graphic devices can be identified with the shell command "lspci | grep VGA". The following example shows the results of this when executed on my system.

famous@homer:~$ lspci | grep VGA
0000:00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express Bridge (rev a2)
0000:02:00.0 VGA compatible controller: nVidia Corporation GeForce 6200 TurboCache(TM) (rev a1)

This shows an NVidia 6100 graphics chipset on the motherboard, and an NVidia 6200 graphics card in the PCI-x16 slot. In the terminology of `xorg.conf`, these devices are addressed as "PCI``:0:5:0" and "PCI``:2:0:0" respectively (rather than "0000:00:05.0" and "0000:02:00.0" as seen in the output of `lspci`). Additionally, we need to locate and identify the input devices in the system. The available devices can be seen with the command "cat /proc/bus/input/devices". The following example shows the results of this when executed on my system.

famous@homer:~$ cat /proc/bus/input/devices
I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/class/input/input0
H: Handlers=kbd event0
B: EV=120013
B: KEY=402000000 3802078f840d001 f2ffffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=0a81 Product=0205 Version=0010
N: Name="CHESEN PS2 to USB Converter"
P: Phys=usb-0000:00:0b.1-1.2/input0
S: Sysfs=/class/input/input1
H: Handlers=kbd event1
B: EV=120003
B: KEY=1000000000007 ff800000000007ff febeffdfffefffff fffffffffffffffe
B: LED=7

I: Bus=0003 Vendor=0a81 Product=0205 Version=0010
N: Name="CHESEN PS2 to USB Converter"
P: Phys=usb-0000:00:0b.1-1.2/input1
S: Sysfs=/class/input/input2
H: Handlers=kbd mouse0 event2 ts0
B: EV=7
B: KEY=1f001f 20000 3878d801d101 1e000000000000 0
B: REL=103

I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/class/input/input3
H: Handlers=kbd event3
B: EV=40001
B: SND=6

I: Bus=0011 Vendor=0002 Product=0006 Version=0039
N: Name="ImExPS/2 Logitech Explorer Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input4
H: Handlers=mouse1 event4 ts1
B: EV=7
B: KEY=1f0000 0 0 0 0
B: REL=103

In this output, the first item is the main keyboard (connected to the motherboard keyboard port), the second item is a keyboard connected via a PS2-to-USB adapter, the third item is a mouse connected via the same PS2-to-USB adapter (note that its "Handlers" line includes "mouse0"), the fourth item is the PC speaker (I have no idea why this qualifies as an input device), and the last item is the main mouse (connected to the motherboard mouse port). The above information will be necessary when configuring certain aspects of "xorg.conf".

[ | {i} || If you want to configure a multiseat system for more than two seats it might be quite difficult to find out proper keyboard/mouse and display associations. With the help of some [scripts this can be done automatically. Just read the README file and follow the instructions. -- FabianSteiner >

Edit /etc/X11/xorg.conf

I assume here that X has already been configured successfully for single-seat operation, as happens in a typical from-scratch installation of Ubuntu. Restricted drivers, such as the `nvidia` driver, should be already installed and activated if they are being used. Note that editing the "xorg.conf" file will require root privileges. I strongly suggest that you make a backup copy of the file before editing it, as such edits frequently result in errors which render X unable to start. When a backup file is available, worst case failures can be salvaged by booting the computer in "recovery" mode and restoring the backup. With those preliminary notes out of the way, here are the modifications you need to make to "/etc/X11/xorg.conf". Below the "files" section, insert a new section as follows.

Section "ServerFlags"
        Option  "DontVTSwitch"
        Option  "HandleSpecialKeys" "Always"
EndSection

The "Dont``VT``Switch" option prevents the "ALT-Fn" keystrokes from changing virtual terminals. As discussed earlier, such switching is incompatible with multiseat operation, since all seats would be affected by it. The "Handle``Special``Keys" option is included to allow the "CTRL-ALT-Backspace" keystroke to reset the X session. It seems reasonable to allow this, since it does operate independently in each seat. Normally it isn't necessary to include this option, as certain other keyboard settings bring it into effect. It seems to be necessary given the keyboard settings used in multi-seat, however. A little further down the file there should be two "Input``Device" sections: one for "Generic Keyboard", one for "Configured Mouse". Below these we will need to add input device descriptions for the keyboards and mice in our multiseat layout. I added the following specifications.

Section "InputDevice"
	Identifier	"Keyboard.0"	# Intended to be the main keyboard port
	Driver		"evdev"
	Option		"Phys"		"isa0060/serio0/input0"
EndSection

Section "InputDevice"
	Identifier	"Mouse.0"	# Intended to be the PS/2 mouse port
	Driver		"evdev"
	Option		"Phys"		"isa0060/serio1/input0"
EndSection

Section "InputDevice"
	Identifier	"Keyboard.1"	# Intended to be the keyboard on the USB converter
	Driver		"evdev"
	Option		"Name"		"* PS2 to USB Converter"
	Option		"Phys"		"*/input0"
EndSection

Section "InputDevice"
	Identifier	"Mouse.1"	# Intended to be the mouse on the USB converter
	Driver		"evdev"
	Option		"Name"		"* PS2 to USB Converter"
	Option		"Phys"		"*/input1"
EndSection

Note that all these input device specifications use the "evdev" (event) driver. Such devices are specified by a form of pattern matching: you need to describe just enough about the device to uniquely distinguish it from other devices in the system. In the case of the built-in PS2 keyboard and mouse ports, the "Phys" (physical) description of the port is sufficiently distinct and constant, so that's relatively easy. In the case of the USB devices, the "Name" field provided a good way to identify the device as a whole, and the rightmost part of the "Phys" field was sufficient to distinguish between the keyboard and mouse components. Note the use of asterisks in those fields as wildcards for pattern matching. Refer to the `xorg.conf` manual page to see which additional options are available to identify input devices, and which of those options support pattern matching (also known as "globbing").

{i}

In my first attempt, I copied the "Xkb*" options from the "Generic Keyboard" into my keyboard configurations above, but found that this resulted in a mis-mapped keyboard, particularly for the cursor control keys. The best approach seems to be to leave out all options until they prove necessary or helpful. This has the nice side effect of making the config file easier to understand. -- The Famous Brett Watson >

[ | {i} || [[1][ you can find a solution to properly configure your xkb in a very similar configuration. -- [[UbuntuHelp:jap1968|jap1968] >

Next up we will need to configure the display devices, including a "dummy" display device which acts as a sort of supervisor to all the other displays. One display device will already be configured: you can re-use it if you want to, or create a copy of it under a different name. My additional device sections were as follows.

Section "Device"
	Identifier	"Dummy"
	Driver		"dummy"
	VideoRam	75
EndSection

Section "Device"
	Identifier	"GeForce 6100"	# On-board
	Driver		"nvidia"
	BusID		"PCI:0:5:0"
EndSection

Section "Device"
	Identifier	"GeForce 6200"	# PCI-x16 slot
	Driver		"nvidia"
	BusID		"PCI:2:0:0"
EndSection

You should copy the "Dummy" device specification exactly, but your actual physical devices will depend on your particular hardware setup. For the "Bus``ID" specification, refer to the output of "lspci" that you (should have) generated earlier. There may be other options you wish to add to these drivers, but don't add things unless they are actually necessary or helpful. Refer to the man page for your driver. (See `/usr/share/doc/nvidia-glx/README.txt.gz` in the case of the restricted `nvidia` driver.) If you have special requirements with regards to monitors, you may need to add additional monitor specifications after the "Generic Monitor" specification that is included by default. Personally, I have obtained excellent results just by using the "Generic Monitor" description anywhere a monitor description is required. Next, we need to add screen specifications for our multiseat setup. Below the pre-configured screen section called "Default Screen", I added the following screen specifications.

Section "Screen"
	Identifier	"Dummy Screen"
	Device		"Dummy"
	Monitor		"Generic Monitor"
	DefaultDepth	8
	SubSection "Display"
		Modes		"320x240"
	EndSubSection
EndSection

Section "Screen"
	Identifier	"Screen.0.0"
	Device		"GeForce 6100"
	Monitor		"Generic Monitor"
	DefaultDepth	24
	SubSection "Display"
		Modes		"1280x1024" "1024x768" "800x600" "640x480"
	EndSubSection
EndSection

Section "Screen"
	Identifier	"Screen.1.0"
	Device		"GeForce 6200"
	Monitor		"Generic Monitor"
	DefaultDepth	24
	SubSection "Display"
		Modes		"1280x1024" "1024x768" "800x600" "640x480"
	EndSubSection
EndSection

Copy the "Dummy Screen" specification exactly, but adjust the others according to your hardware requirements (and the names you used for your device specifications earlier). It should be possible to have a seat with two screens here, which is why I've named the screens with two trailing numbers: the first number identifies the seat; the second number identifies the screen at that seat.

{i}

The dummy screen specification is simply the smallest screen configuration I could think of. Nothing will ever be displayed on this screen, so the resolution is quite irrelevant, but I suspect the "dummy" driver allocates the memory required for it, which is why I made it small. I initially tried a depth of "1", but that doesn't work. The "dummy" driver isn't documented in Ubuntu, but it is available. -- The Famous Bret Watson >

Lastly, we need to add the all-important "layout" specifications. Below the pre-configured "Default Layout" specification, I added the following layouts.

Section "ServerLayout"
	Identifier	"MultiSeat"
	Screen		"Dummy Screen"
	InputDevice	"Generic Keyboard"
	InputDevice	"Configured Mouse"
EndSection

Section "ServerLayout"
	Identifier	"Seat.0"
	Screen		"Screen.0.0"
	InputDevice	"Keyboard.0" "CoreKeyboard"
	InputDevice	"Mouse.0" "CorePointer"
EndSection

Section "ServerLayout"
	Identifier	"Seat.1"
	Screen		"Screen.1.0"
	InputDevice	"Keyboard.1" "CoreKeyboard"
	InputDevice	"Mouse.1" "CorePointer"
EndSection

It should be possible to copy this exactly (for a two-seat system, at least) if you've also copied my naming conventions elsewhere so far.

(!)

I've seen comments elsewhere about a "void" input device, and I'd like to use such a device for the keyboard and mouse in the "Dummy Screen" layout, but it's not available in Ubuntu 6.06. In actual practice, there does not seem to be any problem with using the "Generic Keyboard" and "Configured Mouse", even though I have no idea what events (if any) these devices are generating in multiseat mode. -- The Famous Brett Watson >

Here ends the "xorg.conf" editing. Save your changes and quit the editor.

Edit /etc/gdm/gdm.conf-custom

Rather than edit "/etc/gdm/gdm.conf" directly, Ubuntu allows customisations to be placed in a separate file, "/etc/gdm/gdm.conf-custom". This will, of course, require root privileges to edit. Initially, this file will consist of a massive comment block explaining its purpose, followed by a number of section headers delimiting otherwise empty sections. In the section called "daemon", add "VT``Allocation=false", like so.

[daemon]
VTAllocation=false

Automatic VT allocation is very clever for a single-seat system, but it can only cause pain on a multiseat setup, so we disable it. As an aside, it also means that we'll be explicitly declaring a VT for our X sessions. In the section called "servers", add server specifications as follows.

[servers]
0=MultiSeat
1=Seat0
2=Seat1

These names refer to additional sections which we also add (at the end of the file) as follows.

[server-MultiSeat]
name=Base (dummy) server for multi-seat configuration
command=/usr/bin/X -audit 0 -layout MultiSeat vt09
flexible=false
handled=false

[server-Seat0]
name=Seat 0 server
command=/usr/bin/X -br -audit 0 -layout Seat.0 -sharevts -novtswitch vt09
flexible=false

[server-Seat1]
name=Seat 1 server
command=/usr/bin/X -br -audit 0 -layout Seat.1 -sharevts -novtswitch vt09
flexible=false

All of these use the "-audit 0" parameter only because that's what's used in the original `gdm.conf` file. I couldn't tell you what the exact impact of the parameter is: I'm just repeating it like a parrot. The "-br" flag is also used in `gdm.conf`, but I can tell you what it's for: it causes the X session to start with a black screen instead of that utterly ghastly black-and-white stipple pattern. The "-br" flag is your friend, but it's meaningless for the dummy server, since nobody will ever see what's displayed on that screen. I've chosen to run all these X sessions on vt09. This is somewhat arbitrary, but it works. All the sessions need to be on the same VT, but it doesn't really matter which one. It's even less important given that manual VT switching has been disabled. All the server specifications have "flexible=false", since this has (as I understand it) to do with whether additional X servers can be launched on demand. This is closely tied to automatic VT allocation, and so it gets disabled for the same reason that all other VT-switching stuff is disabled. The "handled=false" on the dummy server simply means not to bother running the `gdm` login program on that server. The server is simply started and hangs around doing nothing other than being the special "first X session" which holds the hardware probe information (or whatever else is special to the first X session). The "-sharevts" and "-novtswitch" flags aren't documented. So far as I can tell, the "-sharevts" flag warns the X server that it is about to start up a session on a VT that is already in use by another X server, and to behave accordingly. I suspect that the "-novtswitch" flag prevents the server from activating its VT at startup, and reverting to the old VT at shutdown. Ultimately these settings are supposed to work together in the following way. The servers are started up (by `gdm`) in the specified order, and shut down in the reverse order. Thus, the dummy server is always the first to start and last to stop. When the dummy server starts, it switches to its VT (vt09 here); when it ends, it switches back to the VT from which it came. The "SeatN" servers, on the other hand, assume that the shared VT is already current, thus the "-novtswitch" flag.

Concluding Remarks

Having made all those changes, the simplest thing to do is reboot into them. Do bear in mind that you will no longer have the luxury of switching to a spare VT to do a little work on the side. It's a bit unsettling to be making changes to things like `xorg.conf` and the `gdm` configuration from within an X session, but it can be done. If your configuration doesn't work, it may leave you with a hung system. Under these circumstances, it's nice to be able to at least attempt a remote login via ssh, if you have the luxury of additional computers and a local network. If not, you may be obliged to press the reset button and try again. To prevent the same lockup from happening again and again, press the "esc" key while `grub` is loading (at boot time) to get the boot menu. If you select a "recovery" option from the `grub` menu, you'll boot into a root shell instead of starting up all the services. This should at least give you the opportunity to restore your original configuration if all else fails. The multiseat system described here is far from elegant, and support for the concept in X (and Linux for that matter) is still in its infancy. Even so, this is the first real success I've had in setting up a multiseat system. Hopefully people will start to realise what a good idea this is -- especially with the proliferation of multi-core CPUs -- and the next LTS release of Ubuntu will have the benefit of really first-class multiseat support.

Userful's desktop-multiplier

[ Userful's desktop-multiplier is a commercial product that is far more stable but not open source. They do however give away [use license keys. It can be found in multiverse in dapper-updates. Until you register (free for personal use) it will also popup a nag screen every thirty minutes. To install:

1. Enable dapper-updates multiverse
2. Install the desktop-multiplier package
3. Restart your computer
4. Follow the instructions

[ Since the multiverse does not always include the most current version you can [directly from their website.

1. Follow the instructions

Ubuntu 5.10 (Breezy Badger) and Ubuntu 5.04 (Hoary Hedgehog)

There is a package written specifically for the HP 441 computers that is available in these versions of called multiseat.

Other implementations

[ * [Ruby docs - needs a kernel patch and outdated as of X.org 7.0/6.9 [ * [with dual head cards - Multiseat solution using Xephyr [ * [Multiplier by Userful - closed source, but free for limited personal use available in 6.06 and above, see the above instructions for installation [ * [in Gutsy using ATI Radeon Cards

---

[ [[category:CategoryCleanup]