Friday, 03-Dec-2004 09:44:22 CET
Home Inhalt Hem

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

Table of contents

I. Introduction
0. Summary

Want a X.org/XFree86 driver (hereinafter called "X driver") for your Silicon Integrated Systems (SiS) or XGI Volari (some desktop and server models only) graphics card? Download it from the download section, install it as described in the installation instructions and simply place Driver "sis" in the Device section of /etc/X11/XF86Config or /etc/X11/XF86Config-4 or /etc/X11/xorg.conf. Simple example configuration files are in the download section.

The X driver is optionally accompanied by a display management tool called sisctrl that lets you tune the display without the need to restart the X server. This tool is available in the download section, too.

Additionally, a Linux kernel framebuffer driver for some SiS and XGI graphics cards is available here as well. This driver is meant for more advanced users as its installation requires some knowledge about kernel configuration and compilation.

Installing any driver downloaded from this website does not mean installing some sort of "third party" software. I am, in fact, the author and maintainer of both the official X.org and XFree86 SiS/XGI driver as well as the Linux kernel's SiS/XGI framebuffer driver.

I know, there is a lot of information on these pages. But you don't have to read them entirely if you don't want to; well, at least in the beginning. As regards the X driver, for basic operation, no special settings or options are needed. The only requirement is to tell the X server that you want to use the "sis" driver (as stated in the first paragraph of this summary). For novice users, I recommend playing with sisctrl as the next step. This will teach you the driver's features and it will show you what options are to be put in your XF86Config(-4)/xorg.conf in order to make permanent changes.

1. Why this page?

Pretty simple: SiS is unfortunately one of those companies that do not support Linux or X.org/XFree86. They don't (and will not) release any documentation on their products (with a few exceptions) and write drivers only for Microsoft's DOS-extensions (called "Windows" by many people; and yes, "Windows" is a trademark). Although they have released XFree86 drivers previously and have released a (binary) driver for the SiS650 in the past, these are and were heavily buggy and not developed any further from a certain point. In other words: Their XFree86 drivers are useless. If you have a notebook, you don't even need to consider trying them.

I bought a SiS-based laptop in 2000 without checking for Linux/XFree86 support. So I had to take things into my own hands.

In June, 2003, the SiS graphics department has been merged with Trident's graphics department, together forming a new company which goes by the name of XGI. The first and second generation XGI graphics chips Volari V3XT, V5, V8 and Z7 are, as regards parts relevant for my drivers, quite compatible to recent SiS chips which is why the drivers now handle both SiS and XGI chips. (The XGI Volari V3, without "XT" in the model number, is not compatible with any SiS chip; it's a Trident-based design. My drivers don't support this chip.)

Before starting, there are some technical details you should know about in order to be able to configure X.org/XFree86 or the Linux kernel properly. I am really sorry not being able to provide you with a "God system" which configures itself automagically. Instead, consider this information as a kind of installation guide that goes beyond Plug & Pray; it will help you solve problems more easily. But don't worry: At least the X driver is nearly fully capable of configuring itself.

2. Supported SiS/XGI graphics chips and video bridges

There are currently five groups of SiS graphics controllers:

  • The old series (SiS 5597/5598, 6326/AGP/DVD, 530, 620),
  • the 300 series (SiS 300/305, 540, 630/S/ST, 730/S),
  • the 315 series (SiS 315/E/PRO, 550, [M]650, 651, 740, [M]661[FMG]X, [M]741[GX]),
  • the 330 series (SiS 330 "Xabre", [M]760[GX], [M]761[GX]), and
  • the 340 series (XGI V3XT, V5, V8, Z7; SiS342 - yet to be released).

(Even older chipsets than the ones mentioned are not and will not be supported.)

Knowing what chipset your machine has is a Good Thing(tm) as they differ heavily in supported features.

The controllers within these groups are (more or less) compatible to each other. Chips with numbers > 3xx (except the 6326) are integrated chipsets which also contain a PCI/AGP/ISA bridge, sometimes a memory controller and a lot of other stuff. The SiS 550 is somewhat special; this one is a complete one-chip computer ("system on chip" = SOC), even including an x86 compatible CPU, but lacking a 3D engine.

Note that there is no SiS 6325. 0x6325 is the PCI ID of the graphics part of the SiS 650, 651, M650 and 740. This number does not identify the device in a unique manner. So you don't have a "SiS 6325" but a SiS 650, 651 and so on. The same applies to 0x6330 - it's either a 661, 741, 760 or 761 (which is sometimes called "661 series" hereinafter). Finally, "Real256", "Ultra256" and "Mirage" are marketing names for the 3D engines of the 661, 741, 760 and 761.

About the 300, 315, 330 and 340 series

All information on the 650, 661, 741, 760, 761 covers these and all model variations with letters in names (like "M650", "760GX" and so on), unless otherwise noted. Graphics-wise there is no difference, except to some extent between the 650 and M650.

The 300/315/330/340 series, except the XGI Volari Z7, have two CRT controllers for simultanious output on two different display devices. While the first CRT controller "CRT1" is mainly for traditional VGA output, the second CRT controller "CRT2" is, in most cases, wired to a so-called "video bridge" or a similar device for controlling LCD/Plasma/DVI-D (digital) output, TV output or secondary VGA/DVI-A (analog) output.

Once again: The XGI Volari V3, without "XT" in its name, is not supported by my drivers. It is no SiS-based, but a Trident-based design.

See the following figure on how the graphics controller and the video bridge interact:


Newer machines can drive (digitally connected) LCD/DVI-D devices via the graphics controller's CRT1 output (marked with green-purple arrows in the figure above). This is true for 650, 651, 661, 741, 760, 761 and later (including all versions with letters in the model number) as well as all XGI Volari chips, in combination with some video bridges. More information on this follows immediately below.

The VGA plug (15 pin D-sub) that is found on most (if not all) machines including laptops is for primary VGA output, thus driven by CRT1.

So, in the following,

  • CRT1 means the chip's primary output which can drive traditional analog VGA devices such as monitors, projectors via 15 pin D-sub connector or, on some machines, digitally connected LCD/DVI-D devices;
  • CRT2 means the chip's secondary output which, if a video bridge is present, can drive either
    • LCD (or any device digitally connected through DVI-D), or
    • TV (S-Video, composite, YPbPr, HiVision) or
    • secondary VGA (or any device connected through analog DVI-A or an eventual second 15-pin D-sub connector)
1. SiS video bridges

There are several types of SiS video bridges available, which are also used on XGI cards. Currently there are

  LCD/DVI-D TV PAL/NTSC HDTV secondary VGA (DVI-A) simultanious LCD+TV output
301 TMDS up to 800x600 HiVision 1080iyes -
301B TMDS up to 1024x768HiVision 1080iyes -
301B-DH- up to 1024x768HiVision 1080iyes -
301C TMDS up to 1024x768YPbPr yes yes
301LV LVDS up to 1024x768YPbPr - yes
302LV LVDS (dual)up to 1024x768YPbPr - yes
302ELV LVDS (dual) - - - -

a) Digital output: The 301, 301B and 301C can only control TMDS ("Panel Link" = DVI-D) devices such as LCD and plasma panels, projectors, etc.; the 301LV, 302LV and 302ELV can only control LVDS devices such as flat panels (which is why these bridges mostly come in notebooks). The 301B-DH is a cut-down version of the 301B as it lacks the capability of controlling any digital devices. Laptops containing a 301B-DH manage LCD output through a separate LVDS transmitter (such as the ECS Desknote 90x series). If your machine has a DVI connector, it has a 301/301B/301C.

The 302LV/ELV bridges are dual-link capable, while the 301/B/C/LV bridges are single link devices. Panels up to 1600x1200 or a dotclock up to 165MHz can be driven with a single-link device. However, the 301 and 301B are limited to 108Mhz which means a maximum resolution for digital panels of 1280x1024. The 301C can drive panels up to 1600x1200.

b) TV output: All SiS bridges, except the 302ELV, support S-Video and Composite (CVBS) for PAL/NTSC. The 301/301B furthermore support HiVision 1080i output (a japanese 1080i standard, similar to YPbPr 1080i). The 301C/301LV/302LV support YPbPr 480i, 480p, 576i, 576p, 720p and 1080i instead, but not HiVision. "YPbPr" means separate analog output/input of Y, Pb and Pr data, usually through three chinch connectors (colored green, blue and red on the devices I have seen so far). You cannot output YPbPr via the S-Video or composite (CVBS) plug. And if you're thinking about connecting your HDTV via DVI, you're reading the wrong paragraph right now. YPbPr means direct and analog YPbPr output, see above for digital output.

c) Secondary (analog) VGA output: Secondary VGA output (VGA2 = DVI-A) is only supported by the 301, 301B and 301C. The different models of video bridges support different maximum dotclocks: The 301 is limited to 135Mhz (maximum resolution 1280x1024 at 60Hz), the 301B to 162Mhz (max 1600x1200 at 60Hz). The 301B-DH is limited to a dotclock of 100Mhz (max 1024x768 at 85Hz). The 301C supports up to 202Mhz (max 1600x1200 at 75Hz).

2. Other devices for CRT2 output

If the machine does not contain a SiS video bridge, LCD output is done through a third party LVDS transmitter (eventually in combination with a Trumpion Zurac LVDS scaler) while TV output is accomplished by a separate TV encoder. The most commonly used TV encoders are the Chrontel 7005 in combination with a 300 series chip, and the Chrontel 7019 in combination with the 315/330/340 series.

For simplicity reasons, the term "video bridge" is hereinafter the synonym for "SiS video bridge or third party device".

3. Possible combinations of output devices

All machines with a 300/315/330/340 series chipset and a video bridge support simultanious output on

  • VGA (analog, via CRT1) and LCD/DVI-D (digital, via CRT2)
  • VGA (analog, via CRT1) and TV (analog, via CRT2)
  • VGA (analog, via CRT1) and VGA2/DVI-A (analog, via CRT2)

Additionally, some chipset/videobridge combinations also support simultanious output on

  • LCD/DVI-D (digital, via CRT1) and TV (analog, via CRT2)

The chipsets that support this are 315PRO/650/651/661/741/760/761 and later, as well as all XGI Volari Vx chips. The video bridges that support this are 301C, 301LV and 302LV. If the combination of chipset and video bridge supports simultanious LCD and TV output and this mode is enabled, LCD/DVI-D output is managed through CRT1. Hence this we hereinafter call this "LCD-via-CRT1".

On all types of machines, there can only be one CRT2 device active at the same time. Therefore, if your machine is not capable of driving the LCD/DVI-D device through CRT1, when you select TV output, the LCD panel is switched off.

3. A few words about the SiS 760 (all versions)

The SiS760 is a chipset for the AMD64 and AMD Sempron platform. These CPUs have a memory controller built-in, ie in systems based on these CPUs, there is no dedicated memory controller present.

As with all integrated SiS chipsets, the SiS 760 supports shared video memory, ie. memory that is shared between the system and the graphics (this technique is called "UMA"). However, the 76x also supports dedicated video RAM (so-called "local framebuffer memory" = "LFB") which connects directly to the graphics chip and is accessible for the CPU via the bus. Shared memory and local memory can be combined ("hybrid mode").

Shared memory is slower, because the graphics chip has to access it via the system memory bus, while it can access local framebuffer RAM directly. Most if not all modern graphics cards therefore use local video memory.

While shared memory was quite usable on all previous integrated chips (630/730, 65x, 661, 74x), there is a serious problem with it on the SiS760 - caused by the aforementioned fact that the CPU contains the system memory controller. This leads to severe memory bandwidth limitations if only shared system memory is used and no local framebuffer memory is present.

Therefore, the 760 - if used with shared memory only - is not really usable in dual head configurations; even in single-head operation, some features are limited. This especially affects video overlay support (Xv): Although the SiS760 supports two video overlays, these are in most cases not usable: Heavy flicker in the video and the graphics may occure as a result of exceeding the available memory bandwidth. The X driver takes some counter-measures on such systems (even advanced ones in the Premium Version), but it can't avoid the problems entirely. On systems with both shared and local video memory, the drivers will only use the local memory part. You may likewise disable the shared memory in the BIOS.

My advice: Don't buy a machine with a SiS760 unless this machine has dedicated local video memory. And please don't complain about "driver bugs" if you see "flashing lines" on the screen; these are the typical effects of a bandwidth problem and unavoidable - even the Windows driver can't do better. In such cases, reduce the resolution and/or refresh rate and/or color depth, or use one output (CRT1 or CRT2) only. Sorry, can't help it. There is no driver bug involved.

For poor Averatec 6240 users: My drivers at least allow 1280x800 on the LCD if the external monitor is enabled... the Windows driver kicks you back to 1024x768 in such a case.

II. Detailed information
1. The SiS/XGI Linux framebuffer driver (sisfb)

The Linux kernel framebuffer driver - hereinafter called sisfb - only supports the 300, 315, 340 series (including the XGI chips).

Why do I need a framebuffer driver?

Well: Despite Linus Torvalds' antipathy regarding framebuffer drivers, sisfb is eg. useful if you want a high-resolution text console.

On the 300 series, sisfb on Linux kernels older than 2.6.3 furthermore plays an important role in connection with DRI (hardware 3D acceleration): In such old kernels, sisfb manages the video memory used by DRI for 3D texture and other data. This memory management is required for using DRI. (For more information, see my DRI page.)

Linux kernels >= 2.6.3 do not need sisfb any longer for DRI memory management. The SiS DRM driver has been updated and features a memory manager of its own which will be used instead if sisfb is not activated in the kernel configuration. So unless you want a graphical console, you don't need sisfb.

Sidenote: Since this seems to be a commonly made mistake: sisfb and the kernel's VESA framebuffer driver cannot be active at the same time!

How are parameters passed to sisfb?

Well, it depends: If compiled statically into the kernel, use lilo's append statement to add the parameters to the kernel command line. Please see lilo's (or GRUB's) documentation for more information. If sisfb is a kernel module, parameters are given with the modprobe (or insmod) command.

Example for sisfb as part of the static kernel: Add the following line to your lilo.conf:


Example for sisfb as a module: Start sisfb by typing

     modprobe sisfb mode=1024x768x16 rate=75 mem=12288

A common mistake is that folks use a wrong parameter format when using the driver compiled into the kernel: If compiled statically into the kernel, the parameter format is video=sisfb:mode:1024x768x16. If compiled as a module, the parameter format reads mode=1024x768x16. Using a "=" for a ":" (and vice versa) is a huge difference! Additionally: If you give more than one argument to the in-kernel sisfb, the arguments are separated with ",". For example: video=sisfb:mode:1024x768x16,rate:75,mem:12288

Video mode selection

For a list of supported display modes, see below. Sisfb only supports the built-in modes listed there.

The desired (default) display mode can be specified using the keyword mode with a parameter in one of the follwing formats: XxYxDepth, XxY-Depth, XxY-Depth@Rate, XxY, or simply use the VESA mode number in hexadecimal or decimal. For example 1024x768x16, 1024x768-16@75, 1280x1024-16. If no depth is specified, it defaults to 8. If no rate is given, it defaults to 60Hz.

Additionally, sisfb understands the keyword vesa following a VESA mode number in decimal or hexadecimal. For example: vesa=791 or vesa=0x117.

If no mode is given, sisfb defaults to

  • Linux 2.4: "no mode" (mode=none) if compiled as a module; if sisfb is statically compiled into the kernel, it defaults to 800x600x8 unless CRT2 type is LCD, in which case the maximum LCD resolution is used.
  • Linux 2.6: 800x600x8 unless CRT2 type is LCD, in which case it defaults to the maximum LCD resolution.
Sisfb and 2.6 kernels

2.6 and later versions bring a lot of changes not only to the programming internals, but to the handling by the user as well. The most important changes are resulting from a complete separation between the framebuffer driver (sisfb in our case) and the console driver (called fbcon). The framebuffer driver now only handles the low-level hardware programming, while the console layer is taking care of the rest. The intention of this was to unify and simplify framebuffer drivers by moving all console code away from them.

However, whether or not the developers succeeded in their intention is yet to be decided.

A consequence of this approach is that, for a framebuffer console, two parts/modules are needed: sisfb and fbcon.

As for the handling by the user, one very important fact to know is that starting sisfb alone (if compiled as a module), does ... nothing. To be more precise: It has no visible effect. The display mode (which is still given like under 2.4, ie by mode=XxYxD or vesa=xxx) is not changed until you either bind the framebuffer to a console by using a tool named con2fb (if the console driver fbcon is compiled statically into the kernel) or by loading the fbcon driver (if compiled as a module). At this point it might be interesting for you to know that sisfb now no longer accepts mode=none - simply because it is no longer required. You decide for yourself if you want a graphical console by invoking con2fb or modprobing fbcon later. But note: If sisfb as well as the console driver are statically compiled into the kernel, the console driver will start automatically during boot. There is no way around this at the moment.

Sounds complicated?

  • sisfb and fbcon statically in kernel: The kernel will boot into graphics mode. If no mode is specified, 800x600x8 will be used by default (unless CRT2 type is LCD in which case it defaults to the LCD's native resolution).
  • sisfb is a module, fbcon is in the kernel: modprob[e]ing sisfb will not change the display mode until you bind the framebuffer to a console by con2fb.
  • sisfb and fbcon are modules: modprob[e]ing sisfb will not change the display mode until you modprobe fbcon. If no mode was given, 800x600x8 will be used by default (again, unless CRT2 type is LCD).
  • sisfb in kernel, fbcon is a module: During boot, nothing visible happens, display mode is changed upon modprobe fbcon.

Another important difference to the 2.4 series is that fbset (the tool to change the console resolution under 2.4) is not more or less deprecated. I say "more or less" because the console developers have not yet decided on where to go from there they are now, namely the - IMHO - totally inconvenient replacement stty. stty is currently intended to change the console resolution, but the desired display mode is not, as we are all used to, given by x resolution, y resolution, depth and refresh rate, but by rows and cols in the unit of text characters. For instance, if you are using the default console font (8x16), stty rows 48 cols 128 selects 1024x768.

If you execute fbset to change the display mode under 2.6, the console dimension (ie the amount of columns and rows) will not change - resulting in display corruption. Use fbset only to change the refresh rate and/or the depth.

As said, beginning with 2.6.3 or so, sisfb is no longer required for DRI memory management. The SiS DRM driver has a memory manager of its own if sisfb is not part of the kernel (be it statically, be it a module). Please read the documentation of the MaxXFBMem option here.

2. The X driver

Preface statement for newbies: To use the X driver described on this page, you need to change the Driver statement in your /etc/X11/XF86Config or /etc/X11/XF86Config-4 file (if the -4 variant exists, do it there) or /etc/X11/xorg.conf so that it reads Driver "sis".

Some of the X driver's features are:

Dual head and Xinerama mode

The SiS X driver is dual-head capable on the SiS 300, 315, 330 and 340 series as well as all XGI chips if a video bridge is present. (Or, of course, by using two VGA cards; in this case some of the resolution/color depth limitations described below do not apply.)

What is "dual head"? Usually, if you have both an external VGA as well as either LCD, TV or secondary VGA connected, the X driver will be in "mirror" mode, ie. it will show the same image on both output devices. "Dual head" means that the driver will set up two different screens, eventually with different resolutions and different color depths, on CRT1 and CRT2. You get two independent X server sessions in (non-Xinerama) dual head mode, and you cannot move windows from one screen to the other.

What is "Xinerama"? This is a special kind of dual head mode. In Xinerama mode, the screens seen on both output devices are "joined" and will virtually form one large screen. You can, for example, move a window from your VGA monitor over to the LCD or the other way round. In Xinerama mode, you only get one X server session.

There is a HOW-TO on Xinerama available; when reading this, please read "XF86Config" eventually as "XF86Config-4" or "xorg.conf" and disregard the requirement of two graphics cards; use the same BusID and Driver in both Device sections and add Screen 0 respectively Screen 1 instead.

In order to set up dual head and Xinerama mode, two Device sections, two Monitor and two Screen sections are required in XF86Config(-4)/xorg.conf, each one for each head. Please see the example XF86Config-4 in the download section below.

  • The color depths and the resolutions of the two screens can be different. In Xinerama mode, however, the color depth of the two screens must be identical (while the resolution can still be different).
  • Due to and depending on memory bandwidth limitations, resolutions/color depths/refresh rates may be limited.
  • DRI is not supported in Dual Head or Xinerama mode
  • 8bpp (256 color) modes are not supported in Dual Head or Xinerama mode
  • On the 300 series, 320x200, 320x240, 400x300, 512x384 and 640x400 are not supported on CRT2 in dual head or Xinerama mode.
  • Again: Please read the example XF86Config-4 file!
Merged Framebuffer mode

Since 2003/03/25, the X driver furthermore supports Merged Framebuffer mode (MergedFB mode). This feature has been inspired by the NVidia binary drivers (which call it "TwinView") and the XFree86 mga driver. The SiS X driver is option-wise fully compatible with the mga driver in this respect.

MergedFB mode is a special kind of Xinerama mode; it practically works like Xinerama, ie the two heads form a large screen which is transparent for applications. But this mode goes beyond Xinerama by even faking one screen to the X server itself. This provides the main advantage, namely that it is faster than Xinerama.

On the 300 series, another advantage over Xinerama is the possibilty to use DRI in MergedFB mode.

On the 315, 650, 740, 330, 340 and all XGI chips MergedFB mode is far superior as regards hardware video acceleration (Xv). See the following paragraph on Xv.

MergedFB mode is setup differently than dual head or Xinerama mode. Please consult the options chapter on more information.

Note: The sisctrl tool works much better with this mode than with Xinerama. I really highly recommend using MergedFB mode over Xinerama.

Xv (Hardware video acceleration)

1. Video overlay method

Hardware video acceleration ("Xv") is primarily done through a so-called "overlay" window provided by the graphics hardware. Basically, the application that wants to play a video, simply hands the video image data to the X server. This video image data is then displayed in the overlay window. This overlay can be displayed above (or below) other screen contents without any further action. This is fast, because it makes the overlay completely independent from the remaining screen contents and it also can contain image data encoded in video standard color space formats (YU12, YUV2, UYVY, ...) which doesn't need to be converted to RGB by software.

Xv via the overlay method is supported on all chipsets except the XGI Volari Z7 (which lacks hardware overlay support). However, due to hardware bugs, the old series might cause some trouble such as wrong colors or missing edges.

The driver natively supports the following color space ("fourcc") formats: YV12, I420, UYVY, YUY2, RV15, RV16. On the 315 series, additionally YVYU is supported. The 330/340 series also support NV12 and NV21.

The maximum video frame size (size of video source) is

  • 384x288 on the 5597/5598,
  • 720x576 on the 6326, 530/620,
  • 768x576 on the 300 series and
  • 1920x1080 on the 315, 330 and 340 series and all XGI chips, but:
    • 960x1080 on the M650, 651 if both CRT1 and CRT2 are active, and
    • 1536x1080 on the 661, 741, 760 (all versions) if both CRT1 and CRT2 are active.

The default values for brightness, contrast, hue and saturation (the latter two only on 315/330/340 series) can be set by driver options, see here.

The following information applies to the 300, 315, 330 and 340 series only:

  • The 315, 650 (not "M" version thereof!), 740, 330 (Xabre), 340 and all XGI chips support one video overlay (which can be displayed on CRT1 or CRT2), all others support two video overlays.
  • The 760 (all versions) basically supports two overlays; however, due to severe memory bandwidth limitations if the chip is used with shared video memory, in most cases only one overlay is usable. The X driver will, depending on the display mode, switch the 760 between supporting one or two overlays. If both CRT1 and CRT2 are enabled, there will be no overlay at all if the resolutions/refresh rates/color depths of the two screens exceed a certain limit. If the machine has local framebuffer memory ("LFB"), these limitations do not apply. If the machine has LFB and shared memory ("hybrid mode"), the X driver will only use the LFB memory.
  • For chipsets supporting one overlay:
    • In mirror mode (ie CRT1 and CRT2 show the same image), sisctrl and/or the option XvOnCRT2 allow to choose whether the overlay should be displayed on CRT1 or CRT2. The other display will only show the colorkey (which is blue by default) or a black-red pattern indicating that the overlay is not available.
    • In non-Xinerama dual head mode, again, sisctrl or the option XvOnCRT2 allow to choose CRT1 or CRT2. The other head will show a black/red pattern indicating that the overlay is currently reserved.
    • The same applies to Xinerama mode. The difference to non-Xinerama Dual Head mode is that no pattern but only the color key (usually blue) will be shown.
    • In MergedFB mode, the driver will automatically choose CRT1 or CRT2, depending on where the overlay is to be located.
    • SiSCtrl can be used to switch the overlay from CRT1 to CRT2 and vice versa.
  • For chipsets with two overlays:
    • In mirror mode (ie CRT1 and CRT2 show the same image) the video will be shown on both CRT1 and CRT2.
    • In non-Xinerama dual head mode, the driver supports one overlay per head; this allows simultanious playback of two videos, ie one per head.
    • In Xinerama mode, no restrictions apply. The video will be shown on both heads.
    • In Merged Framebuffer mode no restrictions apply. The video will be shown on both heads.
  • Due to memory bandwidth limitations, Xv does not work correctly if the display mode runs at dotclocks above a certain limit. If the dotclock is too high, the driver will disable the overlay and eventually show a black window with a red pattern indicating this. (The Premium Version of the X driver handles this differently on some of the 315 series chipsets; the video will be visible in any case.)
  • The driver supports some non-standard XV properties. Here's an overview (see the options chapter for more information):
    • XV_SWITCHCRT is used to switch the CRT number the overlay should be displayed on (similar to the XvOnCRT2 option; see above and here). This is, naturally, only supported on chips that support only one overlay.
    • XV_DISABLE_GRAPHICS disables the graphics output during Xv usage (which results in minimal memory bandwidth advantages).
    • XV_DISABLE_GRAPHICS_LR works in a similar way, but disables graphics display only left and right of the overlay.
    • XV_TVXPOSITION and XV_TVYPOSITION allow fine-tuning the screen position on your TV set and work in the same way as the TVXPosOffset and TVYPosOffset options (see here).
    • For information on the driver's chroma-keying features, see here.

2. Video blitter method

This second method is only supported on the SiS M650 (not the 650!), 651, 661, 741, 330, 76x, 340 and all XGI Vx chips, but not any older chipsets or the XGI Volari Z7. It works entirely different to the overlay method: The video blitter simply copies video data from the video application into the framebuffer (eg. a window), thereby converting the data from the video color space (some YUV format) to RGB. All this is done by the 2D acceleration engine.

The following color space formats are supported: YV12, I420, UYVY, YUY2, YVYU, NV12, NV21. The maximum video source size is 2046x2046.

The video blitter is only very little slower than the Xv method. However, there is a limitation as the Free Version of the X driver cannot scale the video (the Premium Version can, in fact). The video will always be shown in its original size; if the video is larger than the visible screen, it will be cropped. If it smaller, a black border will be drawn. Furthermore, there are no video properties such as contrast, brightness, etc.

So, what's this blitter good for? Well, first of all it has no limitations as regards the dotclock of the current display mode. It is always available. Secondly, it can always and regardsless of the display configuration play videos up to 2046x2046 in size.

Choosing whether you use the overlay or the blitter method is a bit tricky. Both methods are separate Xv adaptors. However, neither Xine nor MPlayer allow choosing the Xv adapter number (or I simply haven't found out how to do this). They both use adapter number 0 for the first video, adapter 1 if a second concurrent session is started, and so forth. To give you more control over what method to use I added the option XvDefaultXvAdaptor. It takes a string argument which is either "Overlay" or "Blitter". The "default" adaptor will be adaptor number 0 and hence being used by Xine/MPlayer.

The Premium Version of the X driver has an advanced Xv system for the M650, 651, 330, 661/741/760 and later chips, as well as the XGI chips which overcomes most of the limitations of the overlay and the blitter described above.

  • DRI ("Direct Rendering Infrastructure") is the basis for OpenGL and hardware 3D acceleration. Without DRI, X.org/XFree86 will use software rendering for OpenGL and 3D which is really slow.
  • The X driver this page is about has nothing to do with DRI. Instead, a separate driver is needed for this feature. This separate driver is developed by the DRI developers. I do not do any DRI related development, hence asking me questions about DRI is useless (and such questions won't be answered).
  • DRI is only supported on the 300 series (300/305, 630, 730). A DRI driver for the SiS 300 series is provided by XFree86 4.1, 4.2(.1), XFree86 4.4 and X.org 6.7.0 and later. XFree86 4.3 does not contain a SiS DRI driver; However, installing the drivers from 4.2(.1) works well.
  • Once again: There is no DRI/OpenGL/3D support for the SiS 6326, 5597/5598, 530/620, 315, 550, 650, 651, 740, 330, 661, 741, 760, 761 including all model variations with letters in the model number.
  • About XGI: Although there is a binary XGI DRI driver for the Volari Vx chips available from XGI, this DRI driver is not supported in connection with the X driver available here or in X.org/XFree86. Hence there is no DRI/OpenGL/3D support for the XGI Volari V3XT, V5, V8 chips yet, unless you dare to use XGI's "own" X driver which comes with the said binari DRI driver. (The Volari Z7 has no 3D engine, so thinking about DRI is moot.)
  • For a little more information on DRI on the 300 series, see here.
256 color (8bpp) modes:
  • On the 300, 315, 330 and 340 series as well as the XGI chips, due to hardware design limitations, modes with a colordepth of 8 are badly supported if using CRT1 and CRT2 at the same time. Both CRT1 and CRT2 have to use the exact same timing values and this causes a quite low refresh rate on CRT1. If CRT2 is disabled, CRT1 will work at normal refresh rates.
  • Due to hardware design limitations, modes with a colordepth of 8 are not supported in dual head, Xinerama or MergedFB mode.
3. The SiS Display Control Panel (sisctrl)

sisctrl is a tool for setting/changing some driver parameters during runtime on a 300, 315, 330 or 340 series or XGI Volari based machine/card or a SiS/Net2280 USB/VGA dongle. It requires the gtk+ 2.4 (or later) library. SiSCtrl will not work on the old series!

The program's GUI is divided in different sections, such as display mode selection, CRT1 setup, CRT2 setup, TV setup, etc.

Please note that sisctrl, for various reasons, cannot save its settings to the xorg.conf/XF86Config(-4) file. The Current-tab will show a skeleton configuration file with all required options to make the current configuration (as set with sisctrl) permanent. However, you will have to edit your configuration file yourself.

Some of sisctrl's features are not supported in dual head or Xinerama mode. Another good reason for using Merged framebuffer (MergedFB) mode instead!

Here are a few - older - screenshots. The actual look may vary depending on your hardware.

Display mode CRT2 setup Colors TV Video Current config
Display mode issues

As regards the display modes and the CRT2 type, there are some limitations in connection with the Free Version of the X driver:

During server startup, the X driver eliminates all modes which are not supported for the CRT2 type chosen (or detected) during startup. Hence, if you start the X server with CRT2 type "TV", there will not be many modes left in the list of display modes but those which are supported for TV. Therefore, even if you intend to switch to another CRT2 type using sisctrl, these display modes are the only ones available. This restriction does not apply to the Premium version of the X driver.

Sisctrl shows which modes are supported on which CRT2 device. There are small icons in the display mode page telling you if a mode is supported on LCD (DVI-D), TV (PAL, NTSC, PAL-M, PAL-N, YPbPr/HiVision modes) and secondary VGA (DVI-A).

SiSCtrl can also issue a complete redetection of all sorts of CRT2 devices, including LCD. This means that you can hotplug LCD panels and use them without a X server restart.

For SiSCtrl to support XGI cards, you need SiSCtrl from Jul 5, 2005, or later.

Color setup and gamma correction

Since 2005/04/05, SiSCtrl has an enhanced color and gamma correction tab. In order to use this properly, please read up on how gamma correction works as a complete explanation is beyond the scope of this document. In short: Output devices have a hardware-determined gamma (which is usually 2.2 for current CRT monitors). Essentially, gamma correction is to correct the hardware's gamma in order to show colors as they were meant to be. The test patterns help this by giving you a direct comparision between the "is" and the "should be" colors. In the test pattern menu, the "CRT1" and "CRT2" entries (if available) show the monitor gamma as reported by DDC or given by the chosen TV standard.

Note that gamma correction for LCD displays, especially laptop panels, is somewhat useless because the gamma of the panel varies with the viewing angle.

Always start with a brightness and contrast of 0.0 for gamma calibration, and eventually adjust brightness and contrast later.

Remote controlling other machines

SiSCtrl can be run on a different machine than the one to configure. It knows a -display command line switch which can be used to access a remote display. For example, if you want to run SiSCtrl on the machine with IP and connect to display 0.0 on the machine with the IP, run

   sisctrl -display

In order to make this work, the remote machine's X server ( in our example) must be enabled to listen to TCP and you need to set AllowNonLocalXVidTune in the "ServerFlags" section of the X configuration file. For example:

   Section "ServerFlags"

Furthermore, the IP of the machine running SiSCtrl ( must be added to the remote machine's ( list of allowed hosts. For our example, run

   xhost +

on the machine to allow SiSCtrl to connect from

Command line

sisctrl also knows some command line options. sisctrl -h will show a short help text. The command line interface can be used to create scripts to be activated by hotkeys. This way, a hotkey, for example, can be set up to switch from LCD to TV.

4. Display modes and monitor configuration for X.org/XFree86
Old series

On the old series, things are pretty straight forward. The driver uses the X.org/XFree86 default modes and eventually additional modes provided by user-added Modelines.

300, 315, 330, 340 series

On the 300, 315, 330 and 340 series, things are a bit more complicated.

If you are not interested in technical details, you can skip this paragraph and continue reading here.

The video bridge output (especially for TV) requires a special mode programming which can't be done be providing modelines. Since most of X.org/XFree86's default modes don't work with LCD and TV output, the driver deletes all default modes X.org/XFree86 provides and replaces the with its own modes.

Below you find tables for each the 300 and the 315/330/340 series which show the X driver's built-in modes for these chipsets. These modes are all available in depths 8, 16 and 24. Additional modes, given through user-added modelines, are generally only accepted

  • if only CRT1 is active (hence on machines without a video bridge or if CRT2 output is disabled) or
  • for CRT1 in Dual Head or MergedFB mode.

Notes on modes for (digitally connected) LCD panels:

  • Depending on the resolution of the LCD panel and the bridge type used, the drivers support different built-in modes. Modes for LCD panels only work up to the resolution the panel was made for. If you have, say, a 1024x768 panel, you won't be able to use any higher resolution than 1024x768. (However, this is not true for most plasma panels. These can often scale down, too.)
  • Additionally, some built-in modes (such as 1024x600 and 1152x768) only work on LCD panels with this very resolution. For instance, 1024x600 is only supported on 1024x600 panels. Finally, some built-in modes are not supported on some LCD panels; 512x384, for instance, is not supported on 1024x600 and 1152x768 panels.
TMDS (SiS 301, 301B, 301C) video bridge specifics

On the TMDS video bridges (301, 301B, 301C), the X driver has the ability to drive digitally connected devices such as LCD panels, plasma panels or HDTV sets (ie. everything connected via DVI-D) with non-standard resolutions. To make this as easy to configure as possible, the X driver will automatically add proper modelines to its built-in list according the device's very needs. However, this feature has a few requirements:

  • As said, this is only supported if the device is connected to a 301, 301B or 301C bridge (which means that it must be connected through DVI-D).
  • The device must be DDC2B, VESA FP or VESA P&D-D compliant (ie it must be able to deliver timing information via DDC).
  • The dotclock of the devices's native resolution/timing must be equal or below 108Mhz (301/30xB) or 162Mhz (301C) - which is actually the highest possible dotclock the respective video bridge supports.
  • The device's (or display mode's) horizontal resolution must be a multiple of 8.

If these requirements are met, the driver will provide built-in display modes according to the device's desired timing. No modeline is needed. This means: If your LCD panel, for example, has a native resolution of 1234x567, just place Modes "1234x567" into the Screen section's Display subsection of your XF86Config(-4)/xorg.conf. That's it. All the modes that the device supports can be seen in the X log.

Besides this automatic configuration, the X driver will also accept modelines for LCD/DVI-D and secondary VGA. Remember that this is only supported on the 301, 301B and 301C video bridges. And be warned: Wrong modelines can damage your LCD/plasma panel.

Note: On some XGI Volari V3XT cards (revision A01, as printed on the board) the DDC ports for CRT1 and CRT2 are both physically/electrically connected to each other. This means that if both a VGA monitor and a LCD panel are connected at the same time, they will both send data over the DDC line causing a signal mixup. Hence, a detection of the LCD panel is impossible. Since the problem is of physical nature, there is nothing the driver can do about it. One highly impractical solution would be to cut the DDC pins from the VGA port, but I would not recommend this. However, as XGI told me, these cards didn't hit the shelfs. The A02 revision is ok.

Summary: Enough techno-babble!

You don't have to worry about any of this. The driver will take care of all this automatically. Just place all modes you wish to use in the list of modes in the Screen-section of your XF86Config(-4)/xorg-conf; If a mode is not supported for a specific output device, it won't be used.

Monitor configuration is done mostly automatically. The automatic detection can be overruled by setting VertRefresh and HorizSync in the Monitor section(s) of the configuration file. Automatic detection relies on the device to support "Display Data Channel" (DDC). For TV and LCD, the driver will assume sane values, and by default even overrule the user given values. General rule: Leave these two options (HorizSync, VertRefresh) entirely out. The only situation I can imagine where these two are needed is if you connect a CRT monitor that lacks DDC support. Please see also here.

Important note on the SiS730: The 730 is different to the 630 in one serious issue: It has sometimes problems with a colordepth of 24bit 1024x768 (or higher) if both CRT1 and CRT2 are active. You will notice this phenomenon if your LCD panel shows flashing lines or simply flickers. In this case, try adjusting the refresh rate on CRT1 by either reducing or increasing the VertRefresh and/or HorizSync range limits in the Monitor section of your XF86Config-4/xorg.conf. Another work-around is switching to 16bpp.

Available built-in modes on the 300 series:

LVDS 301 30xB 30xLV Chrontel 301 30xB 30xLV 30x/B only
320x200 OK
(70Hz only)
OK ? ? ? NO ? ? ? ?
320x240 OK
(60Hz only)
OK ? ? ? NO ? ? ? ?
400x300 OK
(60Hz only)
OK ? ? ? NO ? ? ? ?
512x384 OK
(60Hz only)
OK ? ? ? NO ? ? ? ?
640x400 OK
(70Hz only)
640x480 OK OK OK OK OK OK OK OK ? OK
720x480 OK
(60Hz only)
(60Hz only)
720x576 OK
(56Hz only)
(56Hz only)
768x576 OK
(56Hz only)
(56Hz only)
800x600 OK OK OK OK OK OK OK OK ? OK
1024x600 OK
(60Hz only)
(60Hz only)
1024x576 OK NO NO NO NO NO NO OK
(PAL only)
(PAL only)
1024x768 OK OK OK OK OK NO NO OK ? OK
1152x768 OK
(60Hz only)
(30xB only)
(30xB only)
(30xB only)
1280x768 OK
(60Hz only)
? ? ? ? NO NO NO NO OK
(30xB only)
1280x960 OK NO OK ? ? NO NO NO NO OK
(30xB only)
1280x1024 OK ? ? ? ? NO NO NO NO OK
(30xB only)
1360x768 OK
(60Hz only)
(30xB only)
1360x1024 OK
(60Hz only)
(see below)

Note on 320x200, 320x240, 400x300, 512x384 and 640x400: These modes are no real CRT2 modes (as they require a very special handling) and they are therefore not usable for CRT2 in dual head or merged framebuffer mode. They can, however, be used for CRT1 in all cases. 512x384 and 400x300 are not supported for LCD if the machine uses a Trumpion Zurac LVDS scaler.

Note on 1360x1024: This mode is for LVDS only and only supported on Barco iQ R-series projectors.

Available built-in modes on the 315, 330 and 340 series:

CRT1 LCD TV (S-Video/CVBS/YPbPr/HiVision) VGA2
LVDS SiS 30x/B/C/[E]LV Chrontel 301 SiS 30xB/C/LV 301 30xB/C 301B-DH
320x200 OK
320x240 OK
400x300 OK
512x384 OK
(PAL/PAL-N only)
(PAL/PAL-N only)
640x400 OK
640x480 OK OK OK OK OK OK OK
720x480 OK
720x576 OK
768x576 OK
800x480 OK NO OK(*) NO OK
800x600 OK OK OK OK OK OK OK
848x480 OK NO OK(*) NO NO NO OK
856x480 OK NO OK(*) NO NO NO OK
960x540 OK NO OK(*) NO NO OK
(HiVision/1080i only)
960x600 OK NO OK(*) NO OK
(HiVision only)
(HiVision/1080i only)
1024x576 OK NO OK(*) NO OK
(HiVision only)
1024x768 OK OK OK OK NO OK OK
1152x864 OK NO OK(*) NO NO NO OK OK NO
1280x720 OK NO OK NO OK
(HiVision only)
1280x768 OK
1280x800 OK
1280x854 OK
1280x1024 OK OK OK NO OK
(HiVision only)
(HiVision/1080i only)
1360x768 OK
1400x1050 OK OK OK
1600x1200 OK ? OK
1680x1050 OK NO ?
1920x1080 OK
60Hz i
1920x1440 OK NO NO NO NO NO NO
2048x1536 OK NO NO NO NO NO NO

Remarks for 300/315/330/340 series:

(*): These modes are never scaled to the LCD panel's native resolution. On machines with a 301/B/C (TMDS) bridge, these modes therefore are either passed 1:1 to the device or shown with a black bar around (depending on the CenterLCD option; see here). On machines with a 30xLV, there are always a black bars.

Modes marked with - are not supported due to hardware limitations. Modes marked ? should work but have not been tested.

It may happen that some of the modes listed above will be deleted from the mode list (ie not accepted) on your machine. This is due to memory bandwith limitations.

Note on PAL/NTSC TV modes on SiS bridges: 512x384, 720x576 and 768x576 are only supported in PAL/PAL-N mode.

Notes on YPbPr and HiVision HDTV modes on SiS bridges:

  • Both YPbPr and HiVision require the machine to have a proper YPbPr connector (such as the Asus Digimatrix or the XGI cards); if you intend to connect your HDTV via DVI, the "LCD" tab in the tables above applies instead.
  • YPbPr and HiVision are only supported on the 315/330/340 series and the XGI cards. The 301/301B only support HiVision, the 301LV, 302LV and 301C only support YPbPr 1080i/720p/480p/480i/576i/576p (576i and 576p as of 2005/09/06).
  • All modes for NTSC are supported in YPbPr 480i, 480p and 720p HDTV mode, too. All modes for PAL are supported for 576i and 576p as well.
  • Modes marked with "HiVision" and/or "1080i" and/or "720p" are supported in HiVision or YPbPr 1080i/720p HDTV mode only (and hence not PAL/NTSC or YPbPr 480i, 480p, 576i, 576p and eventually 720p if not mentioned).

For interlace-related issues, see the FAQ

5. High resolution modes and TV output on the SiS 6326

Note: This section is about the old SiS 6326, not the infamous "SiS 6325" which is the VGA core of the SiS650/740 as a matter of fact.

The SiS 6326 supports TV output in seven modes only, which are extremely sensible to timing. If a SiS 6326 and a TV are detected, the X driver adds the supported PAL or NTSC modes to the default modelist. The PAL modes are added if the detected or chosen TV standard is PAL, and NTSC vice versa. These are:

  • for PAL: PAL800x600, PAL800x600U, PAL720x540 and PAL640x480
  • for NTSC: NTSC640x480, NTSC640x480U and NTSC640x400

The modes with "U" at the end of the name are "underscan" modes; these are assumingly supposed to fit better on the TV, but due to the scaling mechanism used, the output might look a bit scrambled (like missing horizontal lines, etc).

Just place these modes in the Screen section of your XF86Config(-4)/xorg.conf, for example as follows:

  Section "Screen"
    SubSection "Display"
      Modes ... "PAL800x600" "PAL720x540" ...

The SiS6326 seems to have some restrictions in clock calculation at high dot clocks. 1280x1024 and 1600x1200 don't work correctly with the standard modes. I implemented two built-in modes for 1280x1024 and 1600x1200, which are named SIS1280x1024-75 (1280x1024, 75Hz, works at 8, 15 and 16bpp) and SIS1600x1200-60 (1600x1200, 60Hz, 8bpp) which solve these problems. Use these modes in the same way like the TV modes, ie. add them to the list in the Display subsections.

^ Top ^ Next >>>