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.