[haiku-development] Re: S3 Video Driver

Hi Gerald,

Gerald Zajac <zajacg@xxxxxxxxxxxxx> wrote:
> As for the X driver, I have not noticed any work around in that 
> driver 
> for this problem.  However, I should point out that by default the X 
> driver uses the video BIOS to set video modes, and the code that sets 
> the video mode by twiddling the registers does have some bugs which I 
> have fixed in the Haiku S3 driver.  One such bug was that the Savage 
> MX 
> chip would only work under BeOS, and under BeOS it would work only if 
> the default boot screen was used.  With any other boot screen, the 
> screen would be blank after the driver started up.  Clearing bit 3 in 
> Sequence register 30, cleared up that problem.  The method I used for 
> that solution was to dump the register values to the syslog when the 
> driver was starting up to get the values set for the boot screen, and 
> then dump the register values after the S3 driver set them.  Then 
> compare the two sets of register values to see which ones differ, and 
> then by "trial and error" determine which of those that differ are 
> actually causing the problem.
> 
> I might do some further investigation of this problem, but I,m not 
> going 
> to spend much time on it since I do not consider it an important 
> problem 
> because there are not many Virge VX chips these days and very, very 
> few 
> people use the 640x480 video mode.

That's true, but it would still be unfortunate if the cursor was gone 
all of a sudden :-)
I think the cleanest and easiest way to solve this is to update the 
cursor hooks after a mode change, and let the driver not export them on 
this chip with this resolution.

> > 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).
> I have turned off all acceleration, and I was still able to cause the 
> hang up.  The hang up seems to occur only when moving windows around 
> rather rapidly.  Under BeOS I have run the GL Teapot and Kaleidoscope 
> demos simultaneously for a couple hours with no problem, and we know 
> that these two programs draw constantly.  Am I correct in assuming 
> that  
> no bit-blit's are performed by either of these programs until you 
> start 
> moving the windows around.  If that is the case, putting some delays 
> in 
> the Savage_ScreenToScreenBlit() might be worth trying.

I doubt they use bit-blits, so it seems its worth a try.
BTW do you have an account at dev.haiku-os.org already? I would like to 
assign the S3 graphics driver component to you, so that you can track 
any errors that might get reported (like #2205).

Bye,
   Axel.

Other related posts: