[haiku-development] Re: S3 Video Driver
- From: Gerald Zajac <zajacg@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 26 May 2008 22:00:21 -0400
Hi Axel,
Axel Dörfler wrote:
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?
When I did check BeOS, It also didn't update the cursor function pointers.
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.
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).
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.
Best regards,
Gerald
Other related posts:
