Multiple Local XFree Users Under Linux
Linux HOWTOs
Thursday, March 15, 2001 12:39:54 PM
Multiple local XFree users under Linux
Version 0.9 by Miguel Freitas
January 16, 2001
Keywords (for bots)
I've wasted a lot of time trying to find this kind of document in google, hotbot and so on. Let me add some keywords to help people finding it: true dual-head, multi-user support, XFree86 4.0, multiple keyboard, multiple mouse, multiple video card, dual user, XFree86 instances, dual keyboard, USB keyboard under X.
Motivation
I have one girlfriend and one computer. In normal conditions, we both couldn't use the computer at the same time, in spite of the fact that it usually has a lot of processing power available. I also have a spare monitor and a second video card for playing 3D games (voodoo) so this idea came to me as something very obvious. New XFree86 4.0 support for dualhead suggests that most of the hard work is already done. And it has to be on Linux, because no closed source OS would allow me to make the changes that I need.
As several reports confirm, Linux is been successfully used in educational institutions and projects due to it's great benefits and low cost. Using the same computer for two (or more) simultaneous students, workers, etc. is something that can reduce even more these costs.
This is also a great option for companies to simplify the management and upgrades of the shared resources (motherboard, processor, hds).
For everybody who may be asking: don't it get too slow? No. The performance difference is barely perceptible as most of the time the computer is waiting some command from the user. And if you haven't figured it out by yourself let me tell something: we live in a time of computing power in excess or do you think most of the users needs a GigaHertz Pentium 3 machine just to do their word processing and surf the web?
Problems
There are some problems that need to be addressed in order to support multiple XFree instances (and users):
VT handling - The Linux kernel Virtual Terminal scheme is a great hack these days. It used to be good in the past as a way to have multiple screens, but now it's something that needs to be completely rewritten (several Linux developers have shown interest in developing a better scheme for 2.5.x series). The main issue is that VT code doesn't understand that we may have multiple input and output devices which therefore may be completely independent. There's no way to associate a given set of VTs for each hardware so Linux kernel would know which VTs can be used simultaneously. If we dispatch multiple instances of XFree86 they would be on different VTs and the Linux kernel will inform them of all VT switching stuff. A switched out (graphic) VT must not use the hardware as it would normally mess with the other active VT, but this is no more true as we have two independent video cards.
Keyboard support - Multiple mouses on X are already a reality as we may specify the "device" option for each one. Unfortunately, the keyboard driver is still deeply rooted at XFree86 core, it's not a separated module and access console I/O functions to read the scancodes. Each XFree86 instance would have their keyboard access halted by VT switching. Besides, Linux is still lacking support for multiple keyboards in a well defined way. Let's wait for 2.5.x tree to see what will be done...
My solution
My hack is surely not the best one, I know thousands of things that could be better implemented in XFree86 and Linux Kernel to support true dual-head (and dual-input) in a clean way. But it works for me. Don't blame me if you spend your money and time buying videocards, monitors, keyboards, mouses and it doesn't work. You've been warned.
Although I would love to see XFree86 supporting simultaneous layouts (without another instance) and a brand new keyboard driver, I don't have the necessary understanding of the project to implement it by myself. Anyway, my regards to the XFree86 developers for this great piece of software!
My idea is to have two instances of XFree86. The first will be using a normal XFree86 server, it will initialize the main video card and attach it to a VT. It will also use the standard system AT keyboard and something (PS/2, serial, USB emulated as PS/2, whatever you want) as a mouse.
The second instance of XFree will be my modified X server. It does not support VT switching at all because it's been used to control a hardware that is not normally used by any other VT. Read my lips, this is very important: The video card can't be the primary one, the mouse can't be the same used by gpm and the keyboard must be USB and must not generate scancodes to the normal Linux console!
As the keyboard doesn't look like a normal AT keyboard (no keys to standard console) the keyboard driver of my modified X server must take care of USB events translating them to normal scancodes.
Procedure (step by step)
1) You need to get XFree 4.0.x (RedHat 7.0 and a lot of recent distros comes with it) and configure it for two video cards and monitors. I suggest that you first try it with Xinerama extension following this HowTo: http://linuxdocs.org/HOWTOs/Xinerama-HOWTO.html
Then modify your XF86Config or XF86Config-4 to separate your screens in two layouts, instead of using them with Xinerama extension. Don't know what I am talking about? Then it's time to read XF86Config, do a ``man XF86Config''
With two layouts your XF86Config should look like this:
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "ServerLayout"
Identifier "Layout1"
Screen 0 "Screen1"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
# this is for supporting deadkeys
Option "XkbRules" "xfree86"
Option "XkbModel" "us"
Option "XkbLayout" "br"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/mouse"
Option "Protocol" "IMPS/2"
Option "Emulate3Buttons" "off"
Option "ZAxisMapping" "4 5"
EndSection
Section "Monitor"
Identifier "Plex17"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 31.5 - 79.0
VertRefresh 50-90
EndSection
Section "Monitor"
Identifier "Syncmaster3"
HorizSync 31.5 - 79.0
VertRefresh 50-70
EndSection
Section "Device"
Identifier "FireGL 1000 PRO"
Driver "glint"
BusID "pci:1:0:0"
BoardName "Unknown"
EndSection
Section "Device"
Identifier "Voodoo"
Driver "glide"
BusID "pci:0:12:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "FireGL 1000 PRO"
Monitor "Plex17"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1024x768"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen1"
Device "Voodoo"
Monitor "SyncMaster 3"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "800x600"
EndSubSection
EndSection
This should be trivial to do because it's almost the same as Xinerama configuration but with two layouts. Then switch your box to runlevel 3 (init 3) and try both layouts, one at a time:
# XFree86 -layout Layout0
# XFree86 -layout Layout1
Pay attention to BusID settings as described in howto. Note that a dualhead board (like Matrox G400) should NOT work through the next steps, as we will be using 2 instances talking to the same hardware. But I haven't tried myself (I'd be happy to try it if any reader wants to donate such video card...).
Not all video cards can be used with XFree86 dualhead support. Don't email me saying that you couldn't get your cards to work up to here or you will burn in hell! Read the Xinerama HowTo instead, thanks.
2) Plug your second mouse on the system and configure XF86Config to use it in the second layout. This mouse must not be used by any other program, like gpm. XF86Config will look like this (only the changed sections):
Section "ServerLayout"
Identifier "Layout1"
Screen 0 "Screen1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Device" "/dev/ttyS1"
Option "Protocol" "Microsoft"
EndSection
Again, test this layout to make sure it's working.
3) Get Linux Kernel 2.4.0 so we can play with USB support. Some 2.2.x kernels may work as they have backported USB support, but in doubt, stick with 2.4.0.
In the kernel configuration, enable USB support (CONFIG_USB) and keyboard (either CONFIG_USB_HID or CONFIG_USB_KBD if your don't need USB mouse support). You must enable "input core support" (CONFIG_INPUT) and MUST NOT enable "keyboard support" (CONFIG_INPUT_KEYBDEV) as we don't want the USB one to be the system keyboard. Also enable "event interface" (CONFIG_INPUT_EVDEV) as I will use it to receive scancodes.
Compile and install the kernel. Now plug your USB keyboard, once the kernel enters you should not see any pressed keys from it at the console. Now try reading the keyboard events (assuming the keyboard is the only USB device you have):
# cat /dev/input/event0
You should see some garbage on the screen as you type. That's all right, your keyboard is working. If you don't see anything or get "No such device", something is wrong with your USB system. Read Documentation/usb in your kernel sources for more information.
4) Get the sources of your XFree86 4.0.x if you haven't already done so. The sources are available from www.xfree86.org. There should be 3 or 4 big .tgz files, but you will only need the first one.
Expand the tree and apply my patch, which can be downloaded here (4.0.1) and here (4.0.2). Follow the instructions from the package to build the X server (make World). You should get a new XFree86 executable on directory xc/programs/Xserver. Copy it to your /usr/X11R6/bin with another name (like XFree86-2nd).
Or if you like the easy way, try one of my XFree86-2nd servers (compiled against glibc-2.1):
XFree86-4.0.1-2nd.gz
XFree86-4.0.2-2nd.gz
This server supports only USB keyboards and do not grab a VT. The only VT code it has is to switch to a given console through XFree86-2nd vtxx parameter.
Applying the patch is intended only for developers that can help me improving this scheme. It will also require you hundreds of MB of disk space. If my provided X servers doesn't work with your system there's little I can do about it. If you can, try to discover the problem and fix it.
5) Modify the second layout to use the USB keyboard. This will require you to use the protocol "usbev" I created and specify the /dev/input/eventx you like as the device. The XF86Config should now look like this (only the changed sections):
Section "ServerLayout"
Identifier "Layout1"
Screen 0 "Screen1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Keyboard1"
Driver "keyboard"
Option "Protocol" "usbev"
Option "Device" "/dev/input/event0"
EndSection
Now try this X server with the command:
# XFree86-2nd -layout Layout1
It should initialize your second video card, the second mouse and the usb keyboard without interfering with your console. You can even do this from a xterm window inside your running X server. Yes! It works! Now move on to the grand finale...
6) If you use gdm as display manager and to provide you a graphical login, you can edit the file /etc/X11/gdm/gdm.conf as follows:
[servers]
0=/usr/bin/X11/XFree86-2nd -delay -layout layout1 vt07
1=/usr/bin/X11/X vt07
Getting this one to work may be a major challenge. It took me a lot of trial and error until I got this stable configuration. I had to add a option "-delay" (my hack) to cause a 10 second delay at one of the servers so they would not initialize the hardware at the same time. I don't know why this is needed. Playing with the order they are initialized (by exchanging 0= and 1=) also does the trick.
Known Bugs
This thing mess up with my text console. I have to switch between the VTs a couple of times before the text looks good again. Fell free to give me a solution.
Also a main problem may be that the whole thing does not work with other hardware and you may be wasting your time reading all this. But the idea is here and I can guarantee that it worked for me. So it must be some little issue that I'm sure will be quickly resolved by another developer somewhere....
Updates
Price study
Brad Midgley pointed that support for Matrox G400 and similar dualhead cards should be possible using framebuffer interface. I still don't have the hardware to do any tests on this, but if you want to try please note that I may have removed something important for framebuffer from the init routines. Please check for any mistakes the patch might have. Any updates on this issue are greatly appreciated...
Contact
Miguel Freitas
Center for Telecommunications Studies of the
Catholic University of Rio de Janeiro (CETUC/PUC-Rio)
Brazil
No comments:
Post a Comment