Hi all :)
From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
test in 2.6.20.x because it doesn't compile, the infamous BDF negative
offset problem) garbles the display, leaving only a lot of thin lines,
just like sync was lost. The display can be repaired by switching to
another console, but this is annoying. This happens with a Voodoo 3
3000, using 800x600x8@100 mode.
Anyone has this problem? Can it be solved changing anything?
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
> Hi all :)
>
> From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> offset problem) garbles the display, leaving only a lot of thin lines,
> just like sync was lost. The display can be repaired by switching to
> another console, but this is annoying. This happens with a Voodoo 3
> 3000, using 800x600x8@100 mode.
>
> Anyone has this problem? Can it be solved changing anything?
>
> Raúl Núñez de Arenas Coronado
Try fbset -a -vyres 600 first and let us know of the result.
Tony
> Hi all :)
>
> From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> offset problem) garbles the display, leaving only a lot of thin lines,
> just like sync was lost. The display can be repaired by switching to
> another console, but this is annoying. This happens with a Voodoo 3
> 3000, using 800x600x8@100 mode.
>
> Anyone has this problem? Can it be solved changing anything?
Does not compile? Can you post the compile error. For my setup it does
compile.
Hi Antonino :)
* Antonino A. Daplas <[email protected]> dixit:
> On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
> > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> > test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> > offset problem) garbles the display, leaving only a lot of thin lines,
> > just like sync was lost. The display can be repaired by switching to
> > another console, but this is annoying. This happens with a Voodoo 3
> > 3000, using 800x600x8@100 mode.
>
> Try fbset -a -vyres 600 first and let us know of the result.
After doing this, I no longer can garble the display (before, just a
"ls -lR /" was enough to do it, in fact, any big output garbled the
display). The only problem with this solution is that the scroll speed
has decreased a bit. In fact, the scroll speed is affected by the vyres
parameter a lot! The highter the vyres, the faster the scroll, and I
cannot reproduce the problem anymore after changing it once!
I'm really confused :?
Thanks a lot for the fix :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
> Hi Antonino :)
>
> * Antonino A. Daplas <[email protected]> dixit:
> > On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
> > > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> > > test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> > > offset problem) garbles the display, leaving only a lot of thin lines,
> > > just like sync was lost. The display can be repaired by switching to
> > > another console, but this is annoying. This happens with a Voodoo 3
> > > 3000, using 800x600x8@100 mode.
> >
> > Try fbset -a -vyres 600 first and let us know of the result.
>
> After doing this, I no longer can garble the display (before, just a
> "ls -lR /" was enough to do it, in fact, any big output garbled the
> display). The only problem with this solution is that the scroll speed
> has decreased a bit. In fact, the scroll speed is affected by the vyres
> parameter a lot! The highter the vyres, the faster the scroll, and I
> cannot reproduce the problem anymore after changing it once!
Display panning is what makes scrolling fast which is the default scroll
method if vyres > yres. Unfortunately, tdfxfb occasionally have
problems with this method, the higher the vyres, the greater the
likelihood of screen corruption. That's why tdfxb limits the vyres to a
maximum of 4096. As to why the problem disappeared just by changing this
parameter, that I too don't know.
Tony
Hi James :)
* James Simmons <[email protected]> dixit:
> > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> > test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> > offset problem) garbles the display, leaving only a lot of thin lines,
> > just like sync was lost. The display can be repaired by switching to
> > another console, but this is annoying. This happens with a Voodoo 3
> > 3000, using 800x600x8@100 mode.
> >
> > Anyone has this problem? Can it be solved changing anything?
>
> Does not compile? Can you post the compile error. For my setup it does
> compile.
I think I didn't explain it well: the tdfxfb driver compiles, but
the *kernel* doesn't. At link time the linker warns about a negative
offset being used and building stops. The driver itself builds perfectly
as far as I can tell.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
Hi Antonino :)
* Antonino A. Daplas <[email protected]> dixit:
> On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
> > > Try fbset -a -vyres 600 first and let us know of the result.
> >
> > After doing this, I no longer can garble the display (before, just a
> > "ls -lR /" was enough to do it, in fact, any big output garbled the
> > display). The only problem with this solution is that the scroll
> > speed has decreased a bit. In fact, the scroll speed is affected by
> > the vyres parameter a lot! The highter the vyres, the faster the
> > scroll, and I cannot reproduce the problem anymore after changing it
> > once!
>
> Display panning is what makes scrolling fast which is the default
> scroll method if vyres > yres. Unfortunately, tdfxfb occasionally
> have problems with this method, the higher the vyres, the greater the
> likelihood of screen corruption.
Then I'll try with 4096 and will diminish the number until the
display is stable.
> That's why tdfxb limits the vyres to a maximum of 4096. As to why the
> problem disappeared just by changing this parameter, that I too don't
> know.
Probably setting it back to 4096 will make the problem reappear.
Right now I cannot test, but I'll make some experiments.
Thanks a lot!
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Mon, 2007-02-26 at 21:32 +0100, DervishD wrote:
> Hi Antonino :)
>
> * Antonino A. Daplas <[email protected]> dixit:
> > On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
> > That's why tdfxb limits the vyres to a maximum of 4096. As to why the
> > problem disappeared just by changing this parameter, that I too don't
> > know.
>
> Probably setting it back to 4096 will make the problem reappear.
> Right now I cannot test, but I'll make some experiments.
>
Can you try this patch? It might help with the screen corruption.
Tony
Hi Antonino :)
* Antonino A. Daplas <[email protected]> dixit:
> On Mon, 2007-02-26 at 21:32 +0100, DervishD wrote:
> > Probably setting it back to 4096 will make the problem reappear.
> > Right now I cannot test, but I'll make some experiments.
>
> Can you try this patch? It might help with the screen corruption.
I'm doing system maintenance now, and won't have spare time until
friday, probably, but as soon as possible I'll test the patch. Thanks a
lot for your invaluable help :)
If you want me to test more patches, feel free. I'll test them ASAP,
probably this weekend if I can afford the time.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!