[haiku-development] Re: S3 Video Driver

Hi Gerald,

Gerald Zajac <zajacg@xxxxxxxxxxxxx> wrote:
> > Haiku will get a hardware cursor, too, one day. Maybe it could 
> > disable 
> > the hardware cursor for this resolution? Or are you already doing 
> > that?
> > If that's not possible with BeOS (I'm not sure right now), we can 
> > easily change that for Haiku, though.
> I looked into disabling the hardware cursor for that resolution, but 
> Zeta does not obtain the pointers to the cursor functions when 
> switching 
> video modes;  thus, I decided to leave it as is.  I did not check 
> BeOS, 
> but I assume it does the same thing.  Of course there might also be a 
> bit in a register somewhere that will enable the hardware cursor at 
> that 
> resolution, but it might be like finding a needle in a haystack.

I checked in Haiku, and it also doesn't update the cursor function 
pointers on a mode change.
But I can easily change that in case you want to make the driver react 
on that. Does the X driver not work around this problem at all?

> > Poor performance is acceptable, locking up doesn't sound too good, 
> > though. Do you have any idea what could be causing this? Do other 
> > platforms like Linux suffer from similar problems?
> Judging from what I have read, there were very few video cards that 
> used 
> the Savage 3D chip because of the problems associated with it.  It 
> was 
> succeeded  by the Savage 4 which is a much better chip.  I have also 
> been able to hang the chip using Erdi Chen's old BeSavage driver.  My 
> code is adapted from the X.org Savage driver, and is quite different 
> from his code.  Thus, I think it is a problem in the hardware.  By 
> stressing the Savage 3D, I mean taking a BeShisen window full of 
> bitmaps 
> or the Kaleidoscope demo program from BeOS R4.5, and rapidly moving 
> the 
> window around the screen for a while.  If the possibility the Savage 
> 3D 
> hanging is a concern, I suggest that we do not support it either by 
> removing or commenting out the two lines for these chips in the 
> S3_ChipTable in driver.cpp.

Would turning off acceleration for these chips already do the trick? Or 
only deactivate problematic parts of the acceleration? Eventually, a 
small periodic delay might also help (that would only be used on that 
hardware).

Bye,
   Axel.

Other related posts: