|
One solution, described here by Miguel Freitas and with some variant there by Frode Trydal, uses a simple trick : disabling the USB keyboard recognition in the kernel and adding raw-usb decoding to the Xserver in order to handle the events coming from the USB keyboard without listening to the regular kernel-recognised keyboard.
I couldn't apply the first method because I could not get the latest kernel to compile the way described by Miguel Freitas, and my hardware would not work decently with kernel older than 2.4.19. I also discarded the second method, because I understood it would work only on top of framebuffer XServers and my NVidia 4200 is known to have troubles with framebuffers.
This method, described here by Vojtech Pavlik, is a patch applied to the kernel that allows the kernel to handle one keyboard with a first set of Virtual Terminals (say VT1 to VT7), and subsequent detected keyboards have the next VTs (VT8-14, then VT15-21 etc...)
You must then patch a little bit the Xserver you intend to use so that it can handle the new behaviour of the VTs. You also have to configure several X servers, one instance for each graphical cards, each configuration will also detail mice/screens matching.
There are several tricks that you must be warned of about the new VT handling :
There is no way to choose which keyboard will match which Virtual Terminal, simply the first keyboard detected by the kernel matches the first set of VTs, and so on... (ex: on my configuration, the ps2 keyboard got the first set)
About USB keyboard, as far as I understand, a single USB keyboard might be internally represented by several keyboards, for example one for the main usual keys, another one for some "multimedia keys" etc... As there are yet no way for the kernel to guess which subsequent detected keyboards are to be matched together, each "part" is assigned a set of VTs.
As a result, with my configuration, the second set of vt (vt8-15) is probably assigned to some of the dumb "multimedia" fancy keys of my USB keyboard and cannot decently be used. The third set of vt is assigned the regular part of the USB keyboard and is fully usable.
This leads us to the next trick :
You must assign enough subsequent sets of vt so that in case of "internally splitted" keyboard you can find a set matching a useable part of the related keyboard.
In short, and for example : on my configuration I have two keyboards, one is ps2 and the other is usb ; I had to ask for 3 sets of VTs in order to have :
here, I detail one after the other all the operations I had to perform on my box.
The AGP slot is of course occupied on my machine, so I have to find a XFree4 supported PCI card. Be careful : for example some old trident worked well with XFree3 and are buggy with XFree4 ! I was offered an "ATI Technologies Inc 3D Rage Pro 215GP" that works fair enough with XFree4 though it's not 3D accelerated yet.
.../... append="dumbcon=3"
cd /dev mkdir old mv mouse js? old mkdir input cd input mknod js0 c 13 0 mknod js1 c 13 1 mknod js2 c 13 2 mknod js3 c 13 3 mknod mouse0 c 13 32 mknod mouse1 c 13 33 mknod mouse2 c 13 34 mknod mouse3 c 13 35 mknod mice c 13 63 mknod event0 c 13 64 mknod event1 c 13 65 mknod event2 c 13 66 mknod event3 c 13 67 cd .. ln -s input/js0 js0 ln -s input/js1 js1 ln -s input/mice mouse
Note (2005-06-01) : |
People who use Sarge may almost completly skip this step (though it might still be usefull for using both an ATI and a nVidia card on the same machine... |
Note (2004-07-14) : |
|
ProjectRoot /usr/local/X11R6_1the previous point is rather important because ATI and NVidia don't share the same 3D rendering libraries...
.../... [server-Standard] name=Standard server command=/usr/bin/X11/X -deferglyphs 16 flexible=true [server-locX] name=server /usr/local/X11R6 command=/etc/X11/LocX1 -deferglyphs 16 flexible=true [server-locX2] name=server /usr/local/X11R6_2 command=/etc/X11/LocX2 -deferglyphs 16 flexible=true [servers] 0=locX2 vt7 1=locX vt14
content of /etc/X11/LocX1 : #!/usr/bin/tcsh set BASE=/usr/local/X11R6_1 setenv LD_LIBRARY_PATH "${BASE}"/lib exec "${BASE}"/bin/X -xf86config /etc/X11/XF86Config-4-ATI $*
content of /etc/X11/LocX2 : #!/usr/bin/tcsh set BASE=/usr/local/X11R6_2 setenv LD_LIBRARY_PATH "${BASE}"/lib exec "${BASE}"/bin/X -xf86config /etc/X11/XF86Config-4-NVidia $*
Apart from creating to X11R6 trees as described above, my installation doesn't differ that much from Vojtech Pavlik description. But I encountered several minor drawbacks :
my logitech mouse that was working perfectly, including the wheel, as a ps2 mouse lost it's wheel capability after the operation. I simply had to use it as a USB mouse to get the wheel back, go figure ?
On both keyboards (french layout), one key was lost in the process I had to use xmodmap to give it back its associated symbols with this trick - there is probably something better to do :
content of .Xmodmap file in user's home (for handling missing '<'/'>'keys)
keycode 94=60 62
The machine now boots like in a dream up to the two running Xservers with their corresponding loging pages.
The sessions of both cards work fully, even at logging out and back in several times.
As a result the machine is fully usable by two people simultaneously. Linux stability permits us to work several days without any single reboot, even playing a lot with multimedia, ieee1394, dvgrabbing, openGL and so on...
A decent linux-box's life involves regular kernel upgrades ; at least from time to time in consideration with security issues, and also because of much more numerous enhanced hardware support. Peoples have been actively updating kernel patches up to date in regard with linux 2.4.x and 2.6.x trees until now (2005 December 29th), and those days my machine is now running with kernel 2.4.33-pre2 and this patch.
Only one main change occured : now the kernel outputs each additionnal virtual console with its number, that is convenient for setting the proper -vt xx option for each running instance of Xserver. THe numbering scheme also changed, but no guessing is needed anymore since the appropriate vc numbers are displayed and available via dmesg.
At last, I also got rid of the 3D rage and added a PCI GeForce4 MX440 64Mb, it's now working great with only one X11 patched-tree for both cards since they share the same driver.
My future plans, on the hardware side, are to add another nvidia PCI, probably a 9525 128Mb
On software side, in a seek for low latency, I tried 2.6.x kernels, and could not get a stable dual head yet. On the other side, the low-latency patch for 2.4.x combined with backstreet-ruby is giving good results, I'll probably put a merged patch on this page some day.
rss-feed for dual-heading |