[haiku-development] Re: S3 Video Driver

Hi Axel,

Axel Dörfler wrote:

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.
That sounds good to me. Will not exporting any one of the cursor functions cause the software cursor to be used? The reason why I ask is that not exporting the ShowCursor() function would involve the simplest change in the S3 driver; whereas, the other two cursor functions would require more changes to not export them.
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).
I do have a Haiku account. Although bug report #2205 constantly refers to the S3 driver, the bug report was filed over two weeks before the source code for the S3 driver was submitted to the project; thus, it pertains to the s3savage driver. I sent totish a copy of the S3 driver for testing before submitting the S3 driver code to this project, and he told me that the S3 driver fixed the reboot problem. 

Best regards,
Gerald

Other related posts: