> > that's interesting. That seems to be contrary to what i'm getting.
> > I now have a setup with 2 XGGI sessions running. XGGI :0.0 is
> > running with a USB keyboard, and USB mouse on a matrox fbdev /dev/fb1.
> > XGGI :1.0 is running with a ps2 keyboard, a ps2 mouse, on a matrox fbdev
> > /dev/fb0.
>
> Last time I looked, the Linux code still had assumptions in it about
> there being a single "active console". The place to look is the
> change_console() stuff in drivers/char/vt.c. LibGGI uses the awful
> VT_PROCESS thing in order to properly handle console switches, and I
> think what happens to you is that you switch VC's (e.g. when launching
> the second XGGI) and that causes the first XGGI server to block on the
> VT_PROCESS signal (since the Linux kernel assumes a single active
> console at one time, i.e. no code to notice that the only the console
> on screen #1 has changed and thus screen #0 XGGI didn't need to be
> sent the VT_PROCESS signal (which makes it pause) after all).
>
> I.e. I think this problem is a limitation of the current multihead
> framebuffer code in Linux.
I was looking through the XGGI code, and found the "-noxfreeemu" option,
which stops it from setting the console. It seems to have little effect,
except for that it causes XGGI to run on the active VT (/dev/tty3), and
it gives the screen a blue tint (really!). ( if you want to try this,
and are using startx rememer to pass the line as "startx -- -noxfreeemu")
If the problem is in the multihead framebuffer code, then would moving to
KGI modules, rather then FBdev help my situation?
Corey
