[haiku-development] Re: S3 Video Driver
- From: Gerald Zajac <zajacg@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 27 May 2008 12:22:55 -0400
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:
