|
Disclaimer: The information and software available on this site is provided AS IS and I
herewith disclaim all warranties with regard to this information and software, including all implied warranties of
merchantability and fitness. In no event shall I be liable for any special, indirect or consequential damages or any
damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other
tortious action, arising out of or in connection with the use of this information and/or the use or performance of
this software.
Since I do not see any valid reason to protect genuine ways of thinking, I don't care about software patents.
In case any software available on this site infringes any of these so called software patents, this infringement is
entirely unintentional and a pure coincident.
[Driver options] * [FAQ] * [Changelog] * [Download]
SiS/XGI graphics chipsets and X.org/XFree86/Linux
| V. Troubleshooting and FAQ |
In this section I have compiled some questions (including their answers) which use to come up from people out there using the driver.
Before starting troubleshooting, find out what hardware your machine has. That is, the chipset type (such as for example SiS 630) and what video bridge/TV encoder (Chrontel TV encoder or SiS video bridge type). You find this information in the X log (usually /var/log/XFree86.0.log or /var/log/Xorg.0.log).
| Q: XFree86 4.1: The X driver fails to work due to some int10 related unresolved symbols |
A: In fact, it's not the SiS driver that has unresolved symbols but the VBE module which the SiS driver loads. Add
load "vbe"
load "int10"
to the Module section of your XF86Config(-4).
|
| |
| Q: The SiS X driver complains about unresolved "glx..." symbols. |
A: Update your X driver to a version newer than 06/17/2004.
[Solution for older versions: Either add
Load "glx"
to the Modules section of your XF86Config(-4)/xorg.conf, or disable DRI with
Option "DRI" "off"
in the Device section. Explanation: A while back, the driver was changed to load the DRI module automatically (which was
previously done with Load "dri" in the Modules section of your config
file). Now, even if that Load "DRI" statement is missing, the driver will load the DRI module unless this is
disabled with the Option "DRI" "off" (in the Device section). The DRI module,
however, is not really smart. It does not load the "glx" module automatically. So, if you have no
Load "glx" in the Modules section, the DRI module (which is loaded by the SiS
driver) will fail with unresolved "glx" symbols.] |
| |
| Q: XFree86 4.4 and X.org 6.7.0 keep crashing on my 64bit system. I use sisfb, if that matters. |
| A: Yes, this matters. The problem is the communication between sisfb and the X driver. The version of sisfb in
2.6.6 vanilla is not yet entirely 64bit safe. Neither is the version in 2.4.26 although X doesn't crash there.
Everything is entirely 64-bit safe as of 2.6.7 resp. 2.4.27. |
| |
| Q: Do the drivers support my brand-new "SiS Real256" or "Mirage" graphics chipset? |
| A: There is no "Real256E" graphics chipset. "Real256E" is a code name for the 3D engine of the SiS661/741. The 760
3D engine is called "Ultra256" or "Mirage 2". Hence, the driver supports these chipsets as regards all 2D and video features. As
I stated a couple of times, there is no hardware accelerated 3D support for these chipsets. |
| |
| Q: There must be a bug in the driver: On my 760/761, I see flashing lines all over the display, and playing a video
makes this even worse. What's the deal? |
| A: That's no bug - well, at least no software bug. It's a hardware problem affecting all AMD64/Sempron SiS chipsets. Please see here. |
| |
| Q: XFree86 4.4: I have problems with my 1024x600 LCD display. Some display modes don't work. |
| A: Please use an updated SiS driver from this site. This bug was found one day after XFree86 4.4 was released. (X.org 6.7 contains an improved version of the driver) |
| |
| Q: Why do I only get black and white on my TV? |
A: There a two possible reasons for this. First, check the PAL/NTSC setting. On integrated chipsets (such as for example SiS630, 65x, etc), there is a setting for this in the BIOS setup utility. If this is set to NTSC, a picture might be displayed on PAL sets, but
colors are missing. Instead of using the BIOS setting, you can also overrule the choice by using the option
TVStandard (see here).
If the TV standard is correct and you still only see black and white, you need to use the color calibration options. For SiS video
bridges, color calibration can be done by SiSCtrl or the options SISTVColorCalibCoarse and
SISTVColorCalibFine (see here). For the SiS 6326, try adjustment
with the option SIS6326FSCAdjust (see here). |
| |
| Q: I have a machine with a Chrontel TV encoder. Why does my TV show a black bar around the screen? |
A: Please see my comments on the tvoverscan option. |
| |
| Q: I have a machine with a Chrontel 7005 TV encoder. I see clear lines in a color gradient on my TV. Seems the chip does not run at 24bpp but a lower color depth. |
| A: It does in fact. The Chrontel 7005 can, if in combination with a SiS630/730, only handle 15bpp. The driver tries
to minimize this disadvantage by enabling a hardware dither-mode, but it is noticable anyway. Switch to 16bpp to
work-around. |
| |
| Q: I have a machine with a SiS video bridge and use TV output. Xv (video) shows some distortions at 1024x768. |
| A: Known hardware issue. Disable CRT1 or switch to a lower resolution on TV. No other workaround possible. SiS once
recommended that I disable 1024x768 for TV if CRT1 is active because, as they say, this mode stresses the video bridge
very much. Since it works otherwise, I didn't follow this suggestion. |
| |
| Q: Why does output of interlaced video via TV show a "comb-like" "interlace"-effect? If the source material
is interlaced and the TV output is interlaced, shouldn't this match? |
| A: CRT2 does not support interlace. Therefore, the driver can't feed interlaced output into the video bridge (which
handles TV output, be it a SiS video bridge, be it a Chrontel TV encoder). The video bridge can only convert a
progressive scan (=non-interlaced) input into TV-suitable interlaced output. The driver can neither change this nor
control which of the frames sent to the bridge is the even/odd field. Long story short: If you want to output interlaced
material on your TV without using a software de-interlacer, you need to add a proper Modeline for interlaced PAL/NTSC
timing (easily found on the internet) and use an external VGA-to-TV converter connected to CRT1. Otherwise you have to use
a software de-interlacer. |
| |
| Q: Can I connect a HDTV to a SiS machine and output HDTV 480i, 480p, 720p, 1080i? |
A: It depends on how you connect the HDTV. Generally, there are three possibilities: Via VGA (CRT1, analog, D-Sub 15 connector), via DVI-D
(digital; via CRT2 or, if LCD-via-CRT1 is supported by the hardware, via CRT1) or via YPbPr (analog; via CRT2).
1) Analog, via VGA (and eventually some sort of adapter), you will need a suitable modeline. The
amount of supported resolutions is not limited by the driver but your HDTV. A few standard HDTV modes are built-in and
require no Modeline: 1920x1080i (60Hz interlaced), 1280x720 (60Hz progressive scan), 1024x576 (60Hz progressive scan), 960x540 (60Hz
progressive scan) and 800x480 (60Hz progressive scan). However, for 1280x720, 1024x576 and 800x480 to work correctly, the HDTV set must supply correct DDC data in order for the driver to be able to recognize the device as a widescreen device. You can see this in the X log; if the log says something about "using fake widescreen modes", the device delivered wrong DDC data. You can use the option ForceCRT1VGAAspect to overrule this (see here).
2) DVI-D (digital) should support all sorts of progressive scan (non-interlaced) HDTV modes up to 1280x1024 (301B) respectively 1600x1200 (301C). As DVI-D is unable to output
interlaced fields, 480i/525i, 576i/625i and 1080i are not supported. If your HDTV supports DDC and reports proper modes via DDC, there is no
need for modelines; just add the modes you want to use to the list of modes in the "Display" sections (see here). In
case the HDTV does not support DDC properly, you need suitable modelines. The built-in 960x540 mode might work, too.
3) The third variant, YPbPr, is only supported on the SiS 30xLV and 301C video bridges, and if your machine has a YPbPr
connector (which is either three chinch connectors or some sort of "combo"-connector such as in case of the Asus Digimatrix). At present
time (September 2005), the Asus Digimatrix and the XGI cards (V3XT, V5, V8) are the only devices I know of supporting YPbPr by featuring a 301C and proper connectors/adapter cables. Note: This means that most current machines are not capable of YPbPr output (such as the Asus Pundit, MSI Hermes series, Shuttle etc.) You are stuck with either VGA or DVI-D for driving your HDTV on such machines (which is not much of a loss because the DVI-D output looks much better anyway.) |
| |
| Q: High resolution modes such as 1024x768 and 1280x720/1280x1024 look quite bad in 720p/750p and 1080i mode. How come? |
| A: The video bridges' TV encoder is only capable of delivering 800 real pixels of video data. This despite the fact that 720p/750p and 1080i are supposed to be used with higher resolutions than 800 pixels per line. Higher resolutions than 800 will be scaled down. Not only is this a big disadvantage to start with, the downscaler also is a really bad one. Well, it's cheap hardware. At least 1024x576 doesn't look too bad. I mostly use 960x540 in 1080i mode and I can live very well with it. |
| |
| Q: Is TV output on the SiS 6326 supported? |
| A: Yes. Please see here. |
| |
| Q: Xv is terribly slow and takes 30% CPU time or more. What's wrong? |
A: As of 06/05/2003, there is a confirmed bug in the SuSE 8.2 XFree 4.3 packages and probably in XFree 4.3
packages of some other distributions as well. This is no SiS driver bug and there is no real workaround available.
However, on some systems, especially Athlon based ones, it helps setting the option XvUseMemcpy to
false. Later versions of XFree86 will hopefully fix this problem rendering this option
unneccessary. (Technical explanation: There is a problem with memory access in these versions of XFree86, rendering
memcpy-operations to video RAM extremely slow. SiS hardware is not the only one affected, there were numerous complaints
from users of other hardware, too. This bug is also known as the "O_SYNC bug". If you want to know more, search the
archive of the xdevel mailing list for a thread named "Athlon related mystery".) |
| |
| Q: Xv video playback, and especially DVD playback, is terribly slow and I have read the above answer. Any further hints? |
A: Yes, two in fact. First, check that MTRR is enabled in your kernel. This is important as it severely speeds up memory-to-memory data transfers. Check your X log for lines like "Failed to set up write-combining range" followed by hex numbers. If you find such lines, your kernel lacks MTRR support. Solution: Reconfigure and reinstall your kernel. Furthermore, for DVD playback, it is essential to have DMA enabled for the data transfer from the DVD drive to memory. To find out, open a console as root, and type hdparm /dev/hdc where /dev/hdc is the device file for your DVD drive. This might vary. However, if hdparm says "using_dma = 0", DMA is not enabled. In this case, try hdparm -d /dev/hdc. If this fails, check your kernel configuration. Under the IDE/ATA options, there is one to enable DMA transfers. Make sure this option is set. |
| |
| Q: On my SiS M650/651 machine, video output is distorted when I play large videos such as for example the Matrix Reloaded or
Matrix Revolutions ultra trailers. |
| A: The Matrix trailers are 1000x540 resp. 1024x534 in size. If you use both CRT1 and CRT2 (be it in clone mode,
dual head mode or merged framebuffer mode), the maximum Xv image size is 960x1080, hence smaller than the video source
material. Unfortunately, Xine and Mplayer don't care about eventual limits of the image size. Disable either CRT1 or CRT2 and the video will
play correctly. The same basically applies to the 661/741/760, although the limit is 1536 instead of 960 on these. |
| |
| Q: Xine always uses the old settings for contrast, brightness, hue and saturation. |
| A: This is a Xine FAQ... Anyway: Xine saves these settings in ~/.xine/config. However, it is not really smart. In order
to "reset" the settings, just delete that file. Xine will write a new one with the defaults after it has been
restarted. |
| |
| 4. Hardware accelerated 3D (DRI/OpenGL) |
| Q: Tuxracer is terribly slow on my SiS 315/550/650/651/330/661/741/760/761/340/XGI Vx |
| A: DRI and hardware accelerated OpenGL/3D is not supported on these chipsets. I don't know how many times I must say
this. And besides, I don't do any DRI related development. |
| |
| Q: I installed XFree 4.3 and I don't have 3D support anymore on my 300 series chipset. What's wrong? |
| A: Due to the inclusion of Mesa version 4 in XFree 4.3, the SiS DRI driver was disabled because
nobody converted it to Mesa 4. You can still use Mesa version 3 which came with XFree 4.2. Debian
users may just install the xlibmesa3 packages from 4.2 (which are available in the download section
on this page.) Users of other distributions should backup all existing libGL.so*, libGLU.so* files
as well as all files in /usr/X11R6/lib/modules/dri/ before installing XFree 4.3. After that simply
copy them back to their old locations. But beware: The DRI driver files *must* have been compiled
with the same version of gcc as the X server. Update: An updated DRI driver is in XFree86 4.3.99.14,
meaning that there is no such workaround required if you are using this version or later. |
| |
| Q: I have problems with DRI. |
| A: Please stop asking me questions about DRI. All information I have is available at my
DRI page. And no, I do not develope anything DRI related. Please contact the
DRI project for problems with DRI/OpenGL/hardware accelerated 3D. I have a sis DRI driver in my download section
which has been reported to work fine. Try that if you like. Otherwise I can't help you. |
| |
| Q: sisfb does not compile on my vendor kernel |
| A: Sisfb is designed for stock vanilla kernels from www.kernel.org. Some distributors like Red Hat have
changed their kernels which might result in compilation problems. In case of Red Hat's 2.4.20 and later, compilation fails
in sis_main.c at a io_remap_page_range() call. Add "vma" as the first parameter to the function call. |
| |
| Q: I see two issues with sisfb: At start, it paints a white rectangle on the screen, and when switching from
X to a console, the screen is black (cursor visible though) until I switch to another console and back. |
| A: This occures with 2.6 kernel(s) <= 2.6.10. Update your kernel. |
|
|
|
