running true multihead...

[Steffen S. <s.s...@ph...>]

Hello all,

having moved the KGI project home to sourceforge now, I found some time
give KGI-0.9 a try running true multihead with XFree86 4.0.

I first prepared two XF86Config files for each head, which _independently_
worked somewhat. (Startup has become even slower, and it seems as if each
server is initializing all video cards found).

Next I prepared KGI-0.9 from the current repository state, and found there 
has been a bug introduced in the keyboard driver when making it behave as the
old driver in terms of hot-plugging keyboards. This messes up the scancodes on
the second keyboard, so it is unuseable. I will commit the fix soon.

Then I booted KGI-0.9 (with null display driver enabled) logged on and
created a node for tty17. A simple cat /dev/tty17 with some input on the
second keyboard did get me the input, so the keyboard and null display
driver seem to work ok on my machine.

Next I configured XDM to run two servers, each with it's own config, one on
tty7, and one on tty17. Firing up XDM as in inittab, it actually ran two X
servers. However, only the first display was working as expected.
Exiting one server, it somehow left _both_ cards mapped to the same address
region, so I assume they do some PCI I/O region remapping on server startup.
But why not mapping it back on exit? Anyway, as a result I had one or the
other card showing console output, both being messed up.

After reboot, I tried to run both servers manually, and I somehow got them
up and running, each having it's own mouse and keyboard. Both worked nicely
as long as you stayed inside the server, but when exiting, the console
was messed up again.

So, the disappointing bottom line is that XFree86-4.0 seems not to restore
video hardware state completely, or messes it up due to a bug. Therefore the
underlying console driver might get confused after the server exited.

However, even if that would have worked, there is another issue I came about
when configuring XDM:

xterm and some other programs expect /dev/console to be owned by the user
sitting on the console. So, even if we map /dev/console to tty's on a
per-work-place basis, how do we manage to map ownership and permissions?

Does anyone have any suggestions?

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...