So I was unable to get all the three monitors working on a single X instance. The 4260 size was too much for X to handle properly, so I decided that the best way to handle this is to get two seats working.
Using a multi-seat system seems like a totally nerd thing, but I would think that with modern multicore CPUs a multiseat system might replace well two or more boxes, if configured properly, in offices and school. But I’ll see to dig deeper into that when I have tried using it for a while.
It might be wroth writing down a few comments about the way I ended up with the video card I’m running now: my 3D Blaster Banshee had the display totally corrupt, I’m still not sure if it’s the video card being broken or an incompatibility between it and the ATi AGP card; the Matrox Mystique didn’t arrive to 1280×1024, I was able to get it at 1024×768 but it’s a bit… too tiny for me, there was not enough video ram (2MB); I ended up trying with an S3 ViRGE just because it looked packed with video ram, and seems like I was right, it supports 1280×1024 just fine… if it wasn’t for the refresh rate. I do hope the problem is with the “ugly pattern” we all know from Xorg, I’ll check better later to see if it works fine with dwm, if it doesn’t, I’ll try to see how it works at 256 colours….
It is strange to see how it’s difficult to find modern mainboards with more than one PCI-E x16 slot, and 16GB of RAM. I decided to get a quad-core for my next box with 16GB of RAM, with the current jobs I’m taking it should be possible for me to get it before June, but I’ll still have to deal with PCI video cards, for that reason (as for why 16GB of RAM… should make it less a pain to deal with repeated compilation of C++ code… and I want to use a few virtual machines); as far as I can see there’s no way to get, with Xorg, two seats working on the same videocard.
By the way, if you follow the Wiki, then you’ll probably see it does not work properly: evdev 1.1 does not respect Phys, evdev 1.2 does not open the devices at all, evdev from GIT works better, but you have to specify the event device to use (nasty, but works perfectly fine as you can symlink stuff around with udev).
Talking about udev, the default /dev/input/by-id symlink are completely useless in my system. The reason is quite easy: I have an Apple Aluminium keyboard (I can’t find anything better to write on!), a Logitech LX700 Cordless Desktop, and since yesterday an MX Revolution mouse; each of these peripherals creates two input device in the kernel (don’t ask me why): the first has one device for the basic keys, plus an extra one for extended keys (like fn); the second has a device for the standard keyboard, plus multimedia keys, and one for the mouse, plus all the extra keys as mouse’s buttons; the third has one device for the mouse, plus one for the extra buttons).
As /dev/input/by-id uses the name and the type of the devices, the Apple keyboard overwrites the symlink by itself, as it obviously has the same name, and has two keyboard devices. The Logitech peripherals instead work quite nicely if they are alone, but as both of them have as internal USB name “Logitech Receiver”, and both have one keyboard and one mouse, … I leave to you guess what happens.
See Greg? This is where usb.ids comes out useful 😉
Anyway, later on today I’ll blog more about the dual-seat system, right now I have some documentation to update and some work to do for my job 😉