[MPlayer-dev-eng] SiS vidix - a few clarifications

[Thomas Winischhofer]

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