> > >If I use X on an accelerated, normal Matrox screen, my monitor complains
> > >on exit:
> > >
> > >fH 49.4 KHz, fV 39.8 Hz
> > >
> > >(and it doesn't sync at 40 Hz vertical refresh :-( ).
> > >
> > >This is _half_ of the normal 80 Hz. Using fbset -a "1600x1200-80"
> > >before X, of after X, doesn't do anything. Does anybody know what to
> > >hack out in X to get it to _not_ reset my G400 to some unusable
> > >state? 3.3.6 was didn't do this. I can use the framebuffer-screen
> > >just fine, but I miss the DGA extension.
> >
> >Try adding this to your XF86Config file:
> >
> >Section "Device"
> >...
> >Option UseFBDev
> >...
> >EndSection
> >
>A very neat trick. X can now be ended correctly. Unfortunately, any
>scrolling on any VT afterwards gives me a corrupted screen - parts of
>the screen from other VT's are inserted below, or over the cursor
>position, and at 'half-line' intervals. In typing this email, I've seen
>it 5 times already.
>I'm willing to test anything - but the corruption is alway gone after I
>switch VT's. So getting a screendump is not easy.
I never have seen this problem before. Petr do you know what it could be?
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
James Simmons wrote:
> >A very neat trick. X can now be ended correctly. Unfortunately, any
> >scrolling on any VT afterwards gives me a corrupted screen - parts of
> >the screen from other VT's are inserted below, or over the cursor
> >position, and at 'half-line' intervals. In typing this email, I've seen
> >it 5 times already.
> >I'm willing to test anything - but the corruption is alway gone after I
> >switch VT's. So getting a screendump is not easy.
>
> I never have seen this problem before. Petr do you know what it could be?
If you are still running X with enabled DRI, then it is known problem.
When
DRI is enabled in X, mga driver randomly reprograms some Matrox
acceleration
registers (color depth, screen width, byte ordering) - so you must use
same depth and resolution in both X and on console if you are using DRI.
I believe that it is problem which thunder7 sees. I never got reported
that
matroxfb just decided itself in the middle of screen to do something
else,
it was always tracked to X running on (invisible) background, but still
playing with accelerator.
Petr
P.S.: You can try 'fbset -accel false', but fixing X is better.
Unfortunately,
nobody cares...