On Sat, Aug 05, 2000 at 01:03:51AM +1000, Andrew Apted wrote:
> [EMAIL PROTECTED] writes:
>
> > 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.
Not that i'm familiar enough with the code to do it, but does that mean
that it's possible to go through the XGGI code, and remove the line which
switches VC's. Then start it up, now in a way that dosn't cause that issue?
(i realize that this would be a short-term ugly hack, and that a real
"clean" framebuffer routine would be better, but i'm anxious :)
Corey
