|
|
用 sis 显卡的兄弟可以看看的这篇文章，出自内核和 XFree86/X.org sis 驱动的作者。
http://www.winischhofer.at/linuxsispart1.shtml
SiS graphics chipsets and X.org/XFree86/Linux
Table of contents
* Chapter I. Introduction
1. Page summary
2. Why this page?
3. Supported SiS graphics chips and video bridges
4. A few words about the SiS 760/761
* Chapter II: Detailed Information
1. The Linux framebuffer driver for SiS graphics chips
2. The X.org/XFree86 driver for SiS graphics chips
3. The SiS Display Control Panel ("sisctrl")
4. Display mode and monitor configuration for the X.org/XFree86 driver
5. High resolution modes and TV output on the SiS6326
* Chapter III. Driver options and parameters for both drivers
* Chapter IV. Summary of changes since official releases of X.org/XFree86
* Chapter V. Troubleshooting and FAQ
* Chapter VI. Changelog
* Chapter VII. Download and installation instructions
* Chapter VIII. How to contact the author
I. Introduction
0. Summary
Want a X.org/XFree86 driver (hereinafter called "X driver") for your Silicon Integrated Systems (SiS) 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 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 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 driver as well as the Linux kernel's SiS 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?
Despite the cute Linux logos on their Linux drivers page, 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.
Although I never signed any NDA, I managed to get some information after a couple of months bugging them, but not only has this information been incomplete, it was even simply wrong sometimes.
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. What this means for the future of SiS graphics chips is yet to be seen.
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 graphics chips and video bridges
There are currently four groups of SiS graphics controllers:
* The old series (5597/5598, 6326/AGP/DVD, 530, 620),
* the 300 series (300/305, 540, 630/S/ST, 730/S),
* the 315 series (315/E/PRO, 550, 650, 651, M650, 740, 661FX, M661FX, M661MX, 741, 741GX, M741),
* the 330 series (330 "Xabre", 760, 760GX, M760, 761), and
* the 340 series (342).
(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, a memory controller, and a lot of other stuff. The 550 is somewhat special; this one is a complete one-chip computer, even including an x86 compatible CPU, but lacking a 3D engine. The 550 is one of SiS' very few Linux-supported products; strangely enough, its graphics part is obviously not covered by this support...
Note that there is no SiS6325. 0x6325 is the PCI ID of the graphics part of the SiS650, 651, M650 and 740. This number does not identify the device in a unique manner. So you don't have a "SiS6325" but a SiS650, 651 and so on. The same applies to 0x6330 - it's either a 661, 741 or 760 (which is sometimes called "661 series" hereinafter). Finally, "Real256", "Ultra256" and "Mirage" are marketing names for the 3D engines of the 661/741 and 760.
About the 300, 315, 330 and 340 series
The 300/315/330/340 series 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 (analogue) output.
See the following figure on how the graphics controller and the video bridge interact:
videobridge
Newer machines can drive 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, M650, 651, 661, 741, 760 and later chipsets, 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 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 VGA devices such as monitors, projectors (via 15 pin D-sub connector) or, on some machines, LCD/DVI-D devices;
* CRT2 means the chip's secondary output which, if a video bridge is present, can drive either
o LCD (or any device connected through DVI-D), or
o TV (S-Video, composite, YPbPr, HiVision) or
o secondary VGA (or any device connected through DVI-A)
1. SiS video bridges
There are several types of SiS video bridges available. Currently there are
LCD/DVI-D TV PAL/NTSC HDTV secondary VGA (DVI-A) simultanious LCD+TV output
301 TMDS up to 800x600 HiVision 1080i yes -
301B TMDS up to 1024x768 HiVision 1080i yes -
301B-DH - up to 1024x768 HiVision 1080i yes -
301C TMDS up to 1024x768 YPbPr yes yes
302B TMDS up to 1024x768 HiVision 1080i yes -
301LV LVDS up to 1024x768 YPbPr - yes
302LV LVDS (dual) up to 1024x768 YPbPr - yes
302ELV LVDS (dual) - - - -
a) Digital output: The 301, 301B, 301C and 302B can only control TMDS (" anel 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, the 301/B/C/LV and 302B bridges are single link devices. Panels up to 1600x1200 or a dotclock up to 162MHz can be driven with a single-link device. However, the 301 and 301B are limited to 108Mhz (maximum resolution/refresh rate: 1280x1024 at 60Hz). The 301C can drive panels up to 1600x1200 at 60Hz.
b) TV output: All SiS bridges, except the 302ELV, support S-Video and Composite (CVBS) for PAL/NTSC. The 301/301B/302B furthermore support HiVision 1080i output (a japanese 1080i standard, similar to YPbPr 1080i). The 301C/301LV/302LV support YPbPr 480i, 480p, 720p and 1080i instead, but not HiVision. "YPbPr" means separate 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, 301C and 302B. The different models of video bridges support different maximum dotclocks: The 301 is limited to 135Mhz (maximum resolution 1280x1024 at 60Hz), the 301B and 302B 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 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 (CRT1) and LCD/DVI-D (CRT2)
* VGA (CRT1) and TV (CRT2)
* VGA (CRT1) and VGA2/DVI-A (CRT2)
Additionally, some chipset/videobridge combinations also support simultanious output on
* LCD/DVI-D (CRT1) and TV (CRT2)
The chipsets that support this are 315PRO/650/M650/651/661/741/760/761 and later. 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, LCD/DVI-D output is managed through CRT1. Hence this we hereinafter call this "LCD-via-CRT1".
On all types of machines, due to hardware limitations, 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/761
The SiS76x are chipsets 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 76x 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 SiS76x - 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 76x - 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 SiS76x 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, 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 SiS76x 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 Linux framebuffer driver (sisfb)
The Linux kernel framebuffer driver - hereinafter called sisfb - only supports the 300, 315 and 330 series.
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 kernel older than 2.6.3 furthermore plays an important role in connection with DRI: Sisfb manages the memory heap used by DRI for 3D texture and other data. This memory management is required for using DRI and has not been implemented into the X driver for the following simple reason: DRI does not necessarily have to be used with X.org/XFree86 only; a quite large part of the DRM/DRI infrastructure is part of the kernel and thus memory management should be in the kernel as well. (For more information, see my DRI page.)
If you share Linus' attitude regarding framebuffer drivers, sisfb offers the possibilty to do the memory management for DRI but leaving the console as it is. Please see the options chapter for more information.
Kernels >= around 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 if sisfb is not compiled). 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:
append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"
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. Please note: If compiled into the kernel, the parameter format is video=sisfb:mode:none or video=sisfb:mode:1024x768x16 (or whatever mode you want to use, alternatively using any other format described above or the vesa keyword instead of mode). If compiled as a module, the parameter format reads mode=none or mode=1024x768x16 (or whatever mode you want to use). 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 128 cols 48 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 below.
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 and 330 series 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"? Well. 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 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" 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 and 740, 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 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 is supported on all chipsets. 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 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 and 300 series and
* 1920x1080 on the 315 and 330 series, but:
* 960x1080 on the M650, 651 (1536x1080 on 661FX, M661FX/MX, 741, 76x) if both CRT1 and CRT2 are active
The default values for brightness, contrast, hue and saturation (the latter two only on 315 and 330 series) can be set by driver options, see here.
The following information applies to the 300, 315 and 330 series only:
* The 315, 650, 740 and 330 (Xabre) support one video overlay (which can be display on CRT1 or CRT2), all others support two video overlays.
* The 76x 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:
o In mirror mode (ie CRT1 and CRT2 show the same image), the option XvOnCRT2 allows 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.
o In non-Xinerama dual head mode, again, the option XvOnCRT2 allows to choose CRT1 or CRT2. The other head will show a black/red pattern indicating that the overlay is currently reserved.
o 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.
o In MergedFB mode, the driver will automatically choose CRT1 or CRT2, depending on where the overlay is to be located.
o SiSCtrl can be used to switch the overlay from CRT1 to CRT2 and vice versa.
* For chipsets with two overlays:
o In mirror mode (ie CRT1 and CRT2 show the same image) the video will be shown on both CRT1 and CRT2.
o In non-Xinerama dual head mode, the driver supports one overlay per head; this allows simultanious playback of two videos, ie one per head.
o In Xinerama mode, no restrictions apply. The video will be shown on both heads.
o 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 driver supports some non-standard XV properties. Here's an overview (see the options chapter for more information):
o 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.
o XV_DISABLE_GRAPHICS disables the graphics output during Xv usage (which results in minimal memory bandwidth advantages).
o XV_DISABLE_GRAPHICS_LR works in a similar way, but disables graphics display only left and right of the overlay.
o 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).
o 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, 651, (M)661, (M)741, 330 and (M)76x(GX), not any older chipsets. 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, it's worst disadvantage is that it cannot scale the video. 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.
DRI:
* 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. (For Debian users: Install the xlibmesa3 package after installing XFree86 4.3; but beware: The xlibmesa3 package should have been compiled with the same compiler revision as the X server.)
* Once again: There is no DRI/OpenGL/3D support for the SiS 6326, 5597/5598, 530/620, 315, 550, 650, M650, 651, 740, 330, 661FX, M661FX/MX, 741, 760.
* For a little more information on DRI on the 300 series, see here.
256 color (8bpp) modes:
* On the 300, 315 and 330 series, 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 or 330 series based machine/card. It requires the gtk+ 2.0 (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 type Gamma TV Video Current config
Display mode issues
As regards the display modes and the CRT2 type, sisctrl has some limitations:
During server startup, the 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.
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).
Since May 1, 2004, SiSCtrl can 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.
Gamma correction
Since 2005/04/05, SiSCtrl has an enhanced gamma correction tab. In order to use this properly, please read up on how gamma correction works. 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.
Gamma brightness is more or less a hack. Always start with a gamma brightness of 1.0 for gamma calibration.
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 10.0.0.171 and connect to display 0.0 on the machine with the IP 10.0.0.170, run
sisctrl -display 10.0.0.170:0.0
In order to make this work, the remote machine's X server (10.0.0.170 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"
AllowNonLocalXVidTune
EndSection
Furthermore, the IP of the machine running SiSCtrl (10.0.0.171) must be added to the remote machine's (10.0.0.170) list of allowed hosts. For our example, run
xhost +10.0.0.171
on the machine 10.0.0.170 to allow SiSCtrl to connect from 10.0.0.171.
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 the CRT2 output is disabled through Option "ForceCRT2Type" "NONE") or
* for CRT1 in Dual Head or MergedFB mode.
Notes on modes for 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, 302B) video bridge specifics
On the TMDS video bridges (301, 301B, 301C, 302B), the X driver has the ability to drive LCD panels, plasma panels or digitally connected 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, 301C or 302B bridge (which means that it is 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 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, 301C and 302B video bridges. And be warned: Wrong modelines can damage your LCD/plasma panel.
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:
CRT1 LCD TV VGA2
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) OK OK OK ? OK OK OK ? ?
640x480 OK OK OK OK OK OK OK OK ? OK
720x480 OK
(60Hz only) NO NO NO NO NO OK OK OK OK
(60Hz only)
720x576 OK
(56Hz only) NO NO NO NO NO OK
(PAL only) OK
(PAL only) OK
(PAL only) OK
(56Hz only)
768x576 OK
(56Hz only) NO NO NO NO NO OK
(PAL only) OK
(PAL only) OK
(PAL only) OK
(56Hz only)
800x480 OK NO NO NO NO NO OK OK OK OK
848x480 OK NO NO NO NO NO NO NO NO OK
856x480 OK NO NO NO NO NO NO NO NO OK
800x600 OK OK OK OK OK OK OK OK ? OK
1024x600 OK
(60Hz only) OK NO NO NO NO NO NO NO OK
(60Hz only)
1024x576 OK NO NO NO NO NO NO OK
(PAL only) OK
(PAL only) OK
1024x768 OK OK OK OK OK NO NO OK ? OK
1152x768 OK
(60Hz only) ? NO NO NO NO NO NO NO OK
(30xB only)
1152x864 OK NO NO NO NO NO NO NO NO OK
(30xB only)
1280x720 OK NO NO NO NO NO NO NO NO OK
(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) NO NO NO NO NO NO NO NO OK
(30xB only)
1360x1024 OK
(60Hz only) OK
(see below) NO NO NO NO NO NO NO OK
1600x1200 OK NO NO NO NO NO NO NO NO NO
1920x1440 OK NO NO NO NO NO NO NO NO NO
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 and 330 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
(70Hz) ? OK ? OK OK OK
(70Hz)
320x240 OK
(60Hz) ? OK ? OK OK OK
(60Hz)
400x300 OK
(60Hz) ? OK ? OK OK OK
(60Hz)
512x384 OK
(60Hz) ? OK NO OK
(PAL/PAL-N only) OK
(PAL/PAL-N only) OK
(60Hz)
640x400 OK
(70Hz) OK OK ? OK OK OK
(70Hz)
640x480 OK OK OK OK OK OK OK
720x480 OK
(60Hz) NO OK(*) NO OK OK OK
(60Hz)
720x576 OK
(56Hz) NO OK(*) NO OK
(PAL/PAL-N only) OK
(PAL/PAL-N only) OK
(56Hz)
768x576 OK
(56Hz) NO OK(*) NO OK
(PAL/PAL-N only) OK
(PAL/PAL-N only) OK
(56Hz)
800x480 OK NO OK(*) NO OK
(HiVision only) OK 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 NO OK
960x600 OK NO OK(*) NO OK
(HiVision only) OK
(HiVision/1080i only) OK
1024x576 OK NO OK(*) NO OK
(HiVision only) OK
(HiVision/1080i/PAL only) OK
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) OK
(HiVision/1080i/720p
only) OK OK NO
1280x768 OK
(60Hz) ? OK NO NO NO OK OK NO
1280x800 OK
(60Hz) NO OK NO NO NO OK OK NO
1280x960 OK NO OK NO NO NO OK OK NO
1280x1024 OK OK OK NO OK
(HiVision only) OK
(HiVision/1080i only) OK OK NO
1360x768 OK
(60Hz) NO OK(*) NO NO NO OK OK NO
1400x1050 OK OK OK
(301C/302[E]LV) NO NO NO NO OK NO
1600x1200 OK ? OK
(301C/302[E]LV) NO NO NO NO OK NO
1680x1050 OK NO ?
(301C/302[E]LV) NO NO NO NO OK NO
1920x1080 OK
60Hz i NO NO NO NO NO NO
1920x1440 OK NO NO NO NO NO NO
2048x1536 OK NO NO NO NO NO NO
Remarks for 300/315/330 series:
(*): These modes are never scaled to the LCD panel's native resolution. On 301/B/C (TMDS), 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 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; 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 series. The 301/301B only support HiVision, the 301LV, 302LV and 301C only support YPbPr 1080i/720p/480p/480i.
* All modes for NTSC are supported in YPbPr 480i, 480p and 720p HDTV mode, too.
* 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 and eventually 720p if not mentioned).
For interlace-related issues, see the FAQ
5. High resolution modes and TV output on the SiS6326
Note: This section is about the old SiS6326, not the infamous "SiS 6325" which is the VGA core of the SiS650 as a matter of fact.
The SiS6326 supports TV output in seven modes only, which are extremely sensible to timing. If a SiS6326 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 ... "AL800x600" "AL720x540" ...
...
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. |
|
IP卡
狗仔卡
发表于 2005-5-7 01:59:14
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2005-5-8 09:47:45