Hi !

> I have successfully gotten GGI working with 2 matrox G200's in the same 
> machine(yea!), using the 2.2.14 kernel matrox fbdev code. 

Ah great !

> running programs  on either monitor works well.  (except quake-ggi on 
> /dev/fb1 for some reason seems to flicker, where as /dev/fb0 
> (another card of the identical model) does not).

Hmm - that's a bit strange. Are both cards preset to the same mode ?

> I can run tile with a "tile:0,0,640,480,(fbdev:/dev/fb0)" just 
> fine, and "tile:0,0,640,480,(fbdev:/dev/fb1)" just fine as well.
> But when i run "tile:0,0,640,480,(fbdev:/dev/fb0):640,0,640,480,(fbdev:/dev/fb1)" 
> across bolth monitors, things run perfectly fine, untill i quit, when the 
> keyboard screws up... 

Hmm - I see. Please send strace and/or  LIBGGI_DEBUG=255 logs.

I suspect input gets opened twice and thus the closing stuff doesn't work
right or something. If that is the case, you might have better luck by
disabling the input on the second fbdev using the -noinput=yes directive:

> I originally thought it totally locked, but i found by pounding on all the 
> keys, i can occasionally get some kind of semi-random responce.

That sounds like the keyboard left in RAW mode. If you have the Magic-SysRq
Key compiled in, you can reset it to normal by pressing Alt-SysRq-R (SysRq
is the Alt function of the Print key).

> Of interest, by doing "tile:0,0,640,480,(fbdev:/dev/fb1)", the flicker from 
> quake-ggi goes away.  go figure...

This is strange. Maybe a problem with the timing stuff. It is a bit hacked
in, because KGIcon drivers don't need it (they have monitor data).

> Any ideas how to stop the keyboard code from going into that strange mode?  
> (without staying in quake forever :)

See above. Hope that works. Enable SysRq for testing.

CU, Andy

= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]> =

Reply via email to