[MPlayer-dev-eng] SiS vidix - a few clarifications
Thomas Winischhofer
twini at xfree86.org
Tue Oct 14 17:36:49 CEST 2003
I am the author of the SiS XFree86 driver as well as sisfb, the SiS
Linux kernel framebuffer driver.
Looking into Jake Page's vidix driver for SiS chipsets, which he had
written based on the XFree86 driver a while ago, I feel to clarify a few
things.
But before I start: The least I intend by these statements is to bash
Jake for his efforts. On the contrary: Compliments to Jake. Assuming
that he probably knew as good as nothing about SiS hardware when he
started, he came quite far. (Again, don't take me wrong, this is no
offence.)
What I actually want to do is show up a few issues which make the SiS
vidix driver, in its current implementation, a bad, bad hack and it is
very likely that it will crash on you (or cause a crash in other running
programs).
1) Running this vidix driver under X is a very, very bad idea. Not only
does the vidix driver corrupt X's framebuffer memory, it also messes
with registers which are entirely the X Server's domain as long as it is
running.
a) The memory corruption is due to the fact that the SiS vidix driver
currently does _no_ memory management at all, not even talking about a
sort of memory management compliant to XFree. It simple writes its video
data at a fixed location in video RAM. This can (and most probably will)
corrupt pixmap caches, render buffers, etc. Don't be surprised if
XFree's display is, say, "distorted" after using vidix under X.
To fix this problem, it needs to do memory allocation in a sane way,
such as eg. using the ioctls sisfb offers for the DRI memory heap. (That
is, after all, what these functions were designed for in the first
place.) For *BSD another, similar technique must be designed.
b) The register issue. Well, this is assumingly common to all xvidix
implementations. Hence, I think I don't need to comment much on this.
But please don't expect Xv to work correctly after having used xvidix...
c) Generally, I think running this vidix driver under X is somewhat
pointless, because it waits for the vertical retrace _at_every_frame_
(as opposed by Xv), wasting a lot of CPU time. Considering that XFree
does not even take 5% CPU time when playing the Matrix revolutions
trailer (1024x534) on my 1,5Ghz Celeron with M650 using Xv, I hardly
think one would gain any speed advantage using xvidix.
2) Video bridge detection and handling.
a) As regards XFree, see 1) b) above. Dangerous, and faulty as regards
the (re-)detection of connected devices. This can't and won't work
reliably if the X Server is running.
b) As regards the framebuffer environment: Upon Jake's request, I
implemented ioctls to poll the bridge status and configuration in sisfb.
I don't really know why he isn't using this. Sisfb has been updated in
the mainline kernel for these ioctrls before 2.4.21 was out IIRC, so the
argument "it requires a too new kernel" doesn't really count.
Anyway, trying to detect the CRT1 and CRT2 devices during a running
sisfb (or X Server) can't and won't work reliably, since it requires the
hardware to be in a certain state when doing this.
The bridge configuration (current VBFlags) can be obtained
-) from XFree via XV properties,
-) from sisfb via ioctl.
3) I admit that I haven't looked into the code too closely, but
regarding the distortions when playing the Matrix Revolutions 1024x534
trailer, I can say at least this:
The 650/740, 315 and 330 have one overlay, the M650 and 651 have two.
On chips with one overlay, the max source size is 1920x1080.
On chips with two overlays, the max source size is
-) 960x1080 if both CRT1 and CRT2 are used,
-) 1920x1080 if either CRT1 or CRT2 are used.
I tested this huge video on my M650 (with only CRT2 being active), and
it showed up correctly (using the XFree86 driver, and -vo xv).
4) Obvious bugs in the vidix driver
a) Chip detection. The SiS vidix driver wrongly reads CR5F in order find
out whether this is a M650 or 651. Well, it does this basically correct,
but this check MUST NOT be done on other chipsets than 650/M650/651.
Currently, this CR5F-check is done on nearly all 315 series chips, very
likely leading to wrong assumptions on the existance of two overlays. As
said, the 315, 330, 740 and 650 have one overlay, all others have two
(including M650 and 651).
b) Bridge sensing: What output device is ACTIVE at a time does not even
closely relate to the result of a scan of which devices are ATTACHED.
c) Display mode detection. Ugh. What should I say. Reading the CR
registers does not neccessarily give any hint on what video mode is
being used on CRT2 (just imagine CRT2 the only one to be active). And by
the way, the vidix driver reads some extendes SR registers without
unlocking them (which will lead to wrong values being read, if the
registers happen to be locked).
Well, before anybody asks: No, I don't have time to look into this any
closer. I am busy with the XFree86 and framebuffer drivers already.
People who want to improve this driver are advised to look at the
XFree86 source code (sis_video.c, among others) and the SiS kernel
framebuffer driver. Both available at
www.winischhofer.net/linuxsisvga.shtml along with a lot of documentation.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net/
twini AT xfree86 DOT org
More information about the MPlayer-dev-eng
mailing list