[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.
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
