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
III. Driver options
For the X driver, the following driver options are to be placed in the Device section of your configuration file (such as /etc/X11/XF86Config or /etc/X11/XF86Config-4; if both these files exist, the X server will use the -4 variant). If you run dual-head mode, place all options in the Device section for CRT2 (yes, CRT2) which is the "master head". Only very few options are accepted in the Device section for CRT1 (slave), such as all Xv and gamma correction related options. So basically, unless otherwise noted below, place the options in the Device section for CRT2.
For sisfb, the parameters are to be given with a kernel parameter (using lilo's append statement) or by the command line.
Please note that this document only covers non-obvious options; you can get more information on the remaining options by invoking man sis.
Options marked with a * are changable during runtime using sisctrl (300/315/330 series only).
In case of the X driver, for boolean options, true, on and yes have same meaning; the opposite is false, off and no. Which one of these words you use is entirely up to you. My examples use the (IMHO) most intuitive one. In case of sisfb, boolean options must be given a numerical argument. 1 means on/true/yes, while 0 means off/false/no.
X driver:
1. General options
Rotate rotate screen clockwise or counter-clockwise
Reflect Reflect screen in x, y, or both x and y direction
DRI enable/disable DRI
MaxXFBMem limit the video RAM XFree should use, and leave the rest to DRI
AGPSize Alias GARTSize; select size of AGP memory to use for DRI
ForceCRT1* enable/disable CRT1 output
ForceCRT1Type* select CRT1 output device type
ForceCRT2Type* select CRT2 output device type
ForceCRT1VGAAspect
ForceCRT2VGAAspect select analog output device aspect ratio
ForceCRT2ReDetection force driver to ignore BIOS info and redetect CRT2 type
NoCRT2Detection disable auto-detection of CRT2 type
OverruleRanges enable/disable overruling bogus monitor frequency ranges
CRT1Gamma*
CRT2Gamma* enable/disable/set gamma correction
GammaBrightness* define default gamma brightness (requires SiSCtrl to take effect)
CRT2GammaBrightness* define gamma brightness for CRT2
NoHostBus enable/disable hostbus
RestoreBySetMode restore the display mode by setting it instead of restoring the registers
MergedFB
MergedFBAuto
MetaModes
CRT2HSync
CRT2VRefresh
CRT2Position
MergedDPI
NoMergedXinerama
MergedXineramaCRT2IsScreen0
MergedNonRectangular
MergedMouseRestriction set up Merged Framebuffer mode
EnableSiSCtrl enable/disable SiSCtrl interface
BenchmarkMemcpy Enable/disable benchmarking various memory transfer methods
UseSSE Enable/disable SSE instruction usage on i386/AMD64.
2. LCD related options
ScaleLCD* enable/disable scaling of LCD output
CenterLCD* center unscaled LCD output
PanelDelayCompensation [panel timing related]
PanelDelayCompensation1 [panel timing related]
SpecialTiming [panel timing related]
LVDSHL [panel timing related]
EMI [panel timing related]
ForcePanelRGB [panel type related]
3. TV related options
TVStandard* select TV output standard
TVXPosOffset*
TVYPosOffset* tune position of screen on TV
CHTVOverscan* enable/disable overscan (Chrontel)
CHTVSuperOverscan* enable/disable super overscan (Chrontel)
CHTVLumaBandwidthCVBS
CHTVLumaBandwidthSVIDEO
CHTVLumaFlickerFilter* fine-tune luma filter (Chrontel)
CHTVChromaBandwidth
CHTVChromaFlickerFilter* fine-tune chroma filter (Chrontel)
CHTVContrast* adjust contrast (Chrontel)
CHTVTextEnhance* adjust text-enhancement facility (Chrontel)
CHTVCVBSColor* enable/disable color output (Chrontel)
SISTVEdgeEnhance* adjust edge-enhance facility (SiS 301 video bridge)
SISTVAntiFlicker* adjust anti-flicker facility (SiS video bridge)
SISTVSaturation* adjust color saturation (SiS video bridge)
SISTVCFilter*
SISTVYFilter* adjust luma and chroma filter (SiS video bridge)
SISTVXScale*
SISTVYScale* scale TV output (SiS video bridge)
SISTVColorCalibCoarse*
SISTVColorCalibFine* adjust color subcarrier frequency (SiS video bridge)
SenseYPbPr enable/disable detection of YPbPr HDTV
YPbPrAspectRatio select aspect ratio for YPbPr (HDTV) output
TVBlueWorkAround Work-around the problem of "blue" TV output
SIS6326TVAntiFlicker adjust anti-flicker facility (SiS 6326)
SIS6326TVEnableYFilter enable/disable chroma filter (SiS 6326)
SIS6326TVYFilterStrong adjust chroma filter (SiS 6326)
SIS6326TVForcePlug select TV plug type (SiS 6326)
SIS6326FSCAdjust adjust color subcarrier frequency (SiS 6326)
4. Video (Xv) related options
XvOnCRT2* select CRT number for video overlay
XvDefaultContrast*
XvDefaultBrightness*
XvDefaultHue*
XvDefaultSaturation*
XvDefaultDisableGfx
XvDefaultDisableGfxLR various video settings
XvGamma* gamma correction for Xv
NoYV12 disable Xv support for YV12 video material
XvUseChromaKey enable video chroma keying
XvInsideChromaKey select chroma key function
XvDisableColorKey enable/disable video colorkey generation
XvYUVChromaKey select chroma key format
XvChromaMin
XvChromaMax select chroma key
XvDefaultAdaptor select overlay or blitter as default adaptor
5. Hardware cursor related options
UseColorHWCursor enable/disable color hardware cursor support
ColorHWCursorBlending enable/disable color hardware cursor emulation
ColorHWCursorBlendThreshold adjust color hardware cursor emulation
sisfb:
mem
mode, mode=none
vesa
rate
forcecrt1
forcecrt2type
userom
useoem
scalelcd
pdc
pdc1
specialtiming
noaccel
noypan
nomax
* * *
Name:
X driver: Rotate
sisfb: n/a
top
Parameter: string ("CW" or "CCW")
Chipsets: All
Description: This option allows rotating the screen clockwise (CW) or counter-clockwise (CCW).
Note that rotating the screen disables all 2D and video acceleration. SiSCtrl will not work if the screen is rotated.
Screen reflection and rotation are mutually exclusive.
Synopsis/Example:
X driver: Option "Rotate" "CW"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: Reflect
sisfb: n/a
top
Parameter: string ("X", "Y" or "XY")
Chipsets: All
Description: This option allows "mirroring" the screen in X direction (X), in Y direction (Y) or in both X and Y direction (XY).
Note that screen reflection disables all 2D and video acceleration. SiSCtrl will not work if the screen is reflected.
Screen reflection and rotation are mutually exclusive.
Synopsis/Example:
X driver: Option "Reflect" "X"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: DRI
sisfb: n/a
top
Parameter: boolean
Chipsets: 300 series (makes no sense on others)
Description: This option allows enabling (on) or disabling (off) DRI. Since DRI is only supported on the 300 series for now, this option does not make sense on other chipsets.
The X driver now loads the dri module automatically if needed. Therefore, please remove the Load "dri" statement from the Modules section of your XF86Config or XF86Config(-4) file in order to avoid error messages in the log.
By default, DRI is enabled on 300 series, and disabled on all others. If DRI is enabled, you must have a Load "glx" statement in the Modules section of your XF86Config(-4)/Xorg.conf file.
Synopsis/Example:
X driver: Option "DRI" "on"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: MaxXFBmem
sisfb: mem
top
Parameter: integer
Chipsets: 300 series (makes no sense on others)
Description: As I already mentioned, sisfb handles the video memory management for DRI on Linux. The X driver, on the other hand, uses video memory for off-screen buffers, Xv and some other features. As a matter of fact, sisfb and the X driver do not share a common video memory management. This option/parameter is meant to avoid a conflict between sisfb and the X driver as these two, not knowing of each other, would overwrite each others video memory. This would lead into corrupt texture data and destroyed windows on your desktop.
Please note that video memory is not the same as AGP memory, as mentioned below. The option MaxXFBMem only controls video memory, not AGP memory.
To control how much video memory you want to reserve for X.org/XFree86 on the one, and DRI on the other hand, as a first step, sisfb's parameter mem is to be used. It takes an integer which specifies the amount of video memory to reserve for X.org/XFree86 in kilobyte.
Sisfb, if not given the mem parameter, will use the following defaults:
* If more than 16MB video memory is available, the heap will start at 12MB (12288KB);
* if 16MB or less, but more than 8MB video memory is available, the heap will start at 8MB (8192KB);
* if 8MB or less of video memory is available, the heap will start at 4MB (4096KB).
For example: If you pass mem=8192 to sisfb, the video memory will be shared as follows: (The red area is the video memory reserved for X.org/XFree86, the green area is reserved for DRI)
maxxfbmem
Usually, sisfb is started before X.org/XFree86. The SiS X driver, during its startup, checks if sisfb is running and queries it for how much video memory X.org/XFree86 is allowed to use. However, there are two situations where does not work: If you are running a Linux 2.4 series kernel and
1. start sisfb with no mode (mode:none) or
2. have compiled sisfb as a module and did not load it before starting X.org/XFree86,
the X driver cannot communicate with sisfb. Therefore, in these two cases the X driver's option MaxXFBMem needs to be set to the same value as you have passed to sisfb. If you passed, for example, mem=8192 to sisfb, you tell the X driver by setting the Option "MaxXFBMem" "8192". (For the second of the mentioned cases, sisfb will - quietly - be loaded during X server start, and since it is being loaded without any parameters, it installs a memory heap of default size.)
If you intend to use DRI and Xv or higher resolutions than 1024x768, I recommend a setting of 12288 for both mem (sisfb) and MaxXFBmem (X driver). If you are using MergedFB mode, I recommend at least 16384.
If you don't intend to use DRI (or if DRI is not supported for your chipset) and don't load sisfb, the MaxXFBmem option can (and should) be left out. Limiting the video memory for X.org/XFree86 is not necessary in this case.
Note for users of Linux 2.6: Beginning from Linux 2.6.3 or so, the SiS DRM driver does no longer depend on sisfb for memory management. The SiS DRM driver has a video memory manager of its own. Hence, if you run a Linux 2.6.3 (or later) kernel and do not compile sisfb (be it statically in the kernel, or as a module), you must set this option in order to give DRI some video memory. Without this option, the X driver will use all video memory and leave nothing to DRI.
Note for users of *BSD: Since *BSD has no framebuffer drivers, the same as for Linux 2.6 applies.
Synopsis/Example:
X driver: Option "MaxXFBMem" "12288"
sisfb (module): modprobe sisfb mem=12288
sisfb (kernel): video=sisfb:mem:12288
* * *
Name:
X driver: AGPSize
sisfb: n/a
top
Parameter: integer
Chipsets: 300 series (makes no sense on others)
Description: DRI can use video memory and AGP memory for texture data. While the option MaxXFBMem controls video memory, this option allows selecting the size of the AGP memory. AGP memory is - untechnically spoken - an area of system memory that is accessible by both the CPU as well as the graphics engines. The X driver does not use this AGP memory area at all, it is only used for DRI.
If your DRI/OpenGL application quits with an "out of memory" error, try first increasing the amount of video memory (which is possible through the BIOS setup on integrated chipsets only), and secondly increasing the AGP memory size by this option (eg. 16, 32, 64).
The value is to be given in MB, within the range of 8 to 512. If the value given is larger than the AGP aperture (which is selectable in the BIOS setup, if at all), the default of 8MB will be used.
The memory size given with this option does not in any way relate to the amount of video memory your box has. Hence, if you have 32MB of video memory, this option can still be set to 64 (if the aperture is big enough).
Since DRI is currently only supported on the 300 series, this option does not make sense on other chipsets. On PCI versions of the SiS300/305, this option has no effect.
Note: This option will not cure all occurances of "out of memory" errors. The SiS DRI driver is still unable to swap textures into system RAM!
Synopsis/Example:
X driver: Option "AGPSize" "32"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: ForceCRT1
sisfb: forcecrt1
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: This option can be used to force the driver to switch CRT1 on ("on") or off ("off"). If this option is omitted, the drivers will automatically detect if a monitor is connected (which since 2003/09/04 no longer must be the case at boot time) and decide on using it. However, automatic detection will only work if the monitor supports DDC1 or DDC2. Note: Due to hardware mis-design, automatic detection via DDC does not work on many 300 series machines with a Chrontel 7005. On such machines, CRT1 must be connected at boot time to be detected correctly.
As regards X, running MergedFB or Dual Head mode will force the driver to use CRT1 automatically. Hence, this option is (no longer) required for these cases either (since 2003/09/04). Furthermore, CRT1 can be enabled and disabled using the sisctrl utility.
The parameter for the sisfb driver reads 0 (meaning OFF) or 1 (meaning ON).
Synopsis/Example:
X driver: Option "ForceCRT1" "on"
sisfb (module): modprobe sisfb forcecrt1=1
sisfb (kernel): video=sisfb:forcecrt1:1
* * *
Name:
X driver: ForceCRT1Type
sisfb: n/a
top
Parameter: string
Chipsets: 315PRO, 650, M650, 651, 661, 741, 760 and later with 301C/301LV/302LV video bridge (mostly laptops)
Description: This option selects whether CRT1 should output to the VGA plug or LCD/DVI-D.
This enables you to use the CRT1 output for driving the LCD panel, leaving CRT2 free for TV output. Hereinafter, this way of handling the LCD panel is called "LCD-via-CRT1".
As all good things come with limitations, there are the ones for this concept:
* As said, LCD-via-CRT1 is only supported on 315PRO, 650, M650, 651, 661, 741, 760 and later, and a SIS 301C, 301LV or 302LV video bridge.
* The 315PRO and 650 (but not later chips) have a problem with color dithering if the LCD is driven through CRT1. If your LCD panel, like most panels used in laptops, is of RGB18 type, ie. it only accepts 18bit color information, and you run the XServer in 24bpp mode, you will see that color gradients are not as smooth as with normal LCD operation via CRT2. This is obviously a hardware limitation; I assume the 650 lacks a dithering engine for CRT1. Later chips do not have this limitation, although color gradients might look slightly different in LCD-via-CRT1 mode on these, too.
To enable LCD-via-CRT1, set Option "ForceCRT1Type" "LCD". To disable this mode, set Option "ForceCRT1Type" "VGA" (which is the default).
Consequently, the CRT2 type must not be "LCD" if LCD-via-CRT1 is enabled.
Remember: In this mode, LCD is driven by CRT1! This might require reversing in the screen order in dual head and MergedFB mode, etc.
Since 2005/03/02 the driver also accepts Option "ForceCRT1Type" "NONE" which is the same as setting Option "ForceCRT1" "off".
Synopsis/Example:
X driver: Option "ForceCRT1Type" "LCD"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: ForceCRT2Type
sisfb: forcecrt2type
top
Parameter: string
Chipsets: 300, 315, 330 series
Description: By this option/parameter you can select the CRT2 output device for the X driver and sisfb. Valid parameters are
* LCD (alias DVI-D for the X driver) for digitally connected LCD or plasma panels (such as the ones in laptops, or connected via DVI-D),
* TV,
* VGA (alias "DVI-A" for the X driver) for analog devices such as VGA monitors, LCD panels connected via the 15pin VGA plug or devices connected via DVI-A, or
* NONE
On systems with a SiS video bridge (301, 301B, 301LV, etc), the drivers accept further arguments for this option. These are meant for forcing a type of TV plug, and are one of the following:
* SVIDEO,
* COMPOSITE
* SVIDEO+COMPOSITE or
* SCART.
SVIDEO+COMPOSITE enables TV output on both connectors, if present. However, both TV connectors will always show the same image. There is no sort of "dual head mode" for this. sisfb supports this since 2004/05/21.
On the SiS 550, this option also accepts DSTN and FSTN for DSTN/FSTN LCD panels. FSTN only supports 320x240 panels. DSTN is entirely untested.
On systems with a SiS 301, 301B or 302B video bridge also the following is supported:
* HIVISION (HiVision 1080i HDTV),
On systems with a SiS315/330 series chipset, a 30xLV or 301C bridge and a proper YPbPr connector, also the following are supported:
* YPBPR480I (480 lines interlaced, YPbPr TV)
* YPBPR480P (480 lines progressive scan, YPbPr HDTV)
* YPBPR720P (720 lines progressive scan, YPbPr HDTV)
* YPBPR1080I (1080 lines interlaced, YPbPr HDTV)
Notes:
* If this option is omitted, the driver will choose the CRT2 device (if more than one is detected) in the following order: TV, LCD=DVI-D, VGA2=DVI-A. (Exception: 300 series chipset with Chrontel 700x TV encoder; see below)
* If you connect both S-Video and CVBS, the driver might wrongly detect a HDTV. That is a hardware limitation.
* "HDTV" means direct (analog) YPbPr output; if you're thinking about connecting your HDTV via DVI, this is a different story.
* Under X, the CRT2 type can be changed during server-run-time using the sisctrl utility.
* "VGA" does not mean the (primary) external VGA connector found on your laptop. Setting CRT2 to VGA means a secondary external VGA, which hardly exists on a laptop. In the only case your machine has two physical VGA connectors (even if one of them is a DVI-I connector), you may use VGA to enable the secondary VGA. See also figure above.
* "NONE" can be used to switch off CRT2 output and use an external VGA only.
* "TV"
o The SiS301 and the Chrontel 7005 support resolutions up to 800x600. The 30xB/C/LV and the Chrontel 7019 support resolutions up to 1024x768.
o Due to hardware restrictions, the LCD panel will be disabled when using TV-out. The video bridge can only control one output device at the same time. However, if your machine supports LCD-via-CRT1 (see here), simultanious LCD and TV output is possible.
o On my machine, the Chrontel 7005 behaves quite strangly; it seems that it requires a few minutes for warm-up (?). In the first minutes, the image on the TV flickers and loses color now and then. After a short while, everything is ok.
o The Chrontel 7005 has one more issue. Due to a hardware bug, it sometimes reports a TV connection although no TV is actually connected. Since TV, normally, has the highest priority among the CRT2 devices (if ForceCRT2Type is missing in the configuration file), this is inconvenient on laptops as the LCD panel will go blank. Therefore, on such machines, the default order is LCD - TV - VGA2.
* FSTN, DSTN: This is for the SiS550 only. FSTN is for 320x240 STN panels. DSTN is entirely untested. FSTN and DSTN panels cannot be auto-detected. If using FSTN or DSTN as the CRT2 type in sisfb, the forcecrt2type option must be the first in the list of options, before the mode and other stuff.
Synopsis/Example:
X driver: Option "ForceCRT2Type" "TV"
sisfb (module): modprobe sisfb forcecrt2type=TV
sisfb (kernel): video=sisfb:forcecrt2type:TV
* * *
Name:
X driver: ForceCRT1VGAAspect
ForceCRT2VGAAspect
sisfb: n/a
top
Parameter: string ("normal" or "wide")
Chipsets: 315, 330, 340 series
Description: These options only affect analog output devices connected via the D-sub 15 VGA connector, such as VGA monitors, projectors, etc. They have no effect on TV or LCD/DVI output.
The ForceCRT1VGAAspect option is for CRT1, the ForceCRT2VGAAspect option is for CRT2.
If a device delivers proper DDC data, the driver is in most cases able to determine the aspect ratio of the output device automatically. If this fails, the assumed aspect ratio can be overruled by these options.
The aspect ratio of a device determines how the driver sets up its built-in default display modes for 800x480, 1024x576, 1280x720, 1280x768 and 1280x800. No other default display modes are affected by these options. Modelines added by the user are also unaffected.
If the aspect ratio is "wide", these modes are real widescreen modes (which will look vertically "stretched" on 4:3 devices). They all are available at 60Hz only.
If the device is "normal" (ie 4:3 or 5:4), these modes are faked, ie they will show with a black bar above and below.
Both options take a string parameter which is either normal or wide. The default setting is derived from DDC data. If no DDC data is delivered, the driver defaults to "normal".
Synopsis/Example:
X driver: Option "ForceCRT1VGAAspect" "wide"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: ForceCRT2ReDetection
sisfb: n/a
top
Parameter: boolean
Chipsets: 315, 330 series with a SiS 301/301B/301C/302B video bridge
Description: Some machines or cards come with a DVI connector for digital or analog CRT2 devices. In order to use these, they need to be detected. Normally, the BIOS takes care of this during a reset.
However, the BIOS is not very good at this, especially when it comes to LCD or plasma panels with unusual resolutions. Setting this option will therefore force the X driver to re-detect the LCD or plasma panel (or the secondard VGA monitor) by using DDC2B (Display Data Channel).
This option is recommended (and basically even required) for most plasma panels. Therefore, by default, CRT2 re-detection via DDC2B is enabled.
Synopsis/Example:
X driver: Option "ForceCRT2ReDetection" "on"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: NoCRT2Detection
sisfb: n/a
top
Parameter: boolean
Chipsets: 315, 330 series with a SiS 301/301B/301C/302B video bridge
Description: This option is ignored if the option ForceCRT2ReDetection is set. Please read the info on the ForceCRT2ReDetection option first.
If the BIOS has not detected an LCD panel or a secondary VGA connection, the driver will by default try to detect connected devices via DDC2B. This behavior is regardless of the ForceCRT2ReDetection setting.
However, DDC2B (Display Data Channel) detection is not 100% secure. There might be device types/models which deliver incorrect or insufficient data via DDC and, due to this, get wrongly detected as LCD panels instead of CRT monitors (or vice versa). To disable the detection by using DDC2B, set this option to on. You will then need to connect the device before booting (and pray that the BIOS is more intelligent than the driver - wish you the best of luck... would be the first time...).
By default, CRT2 detection via DDC is enabled. (But only done, if the BIOS has not detected a LCD panel or secondary VGA.)
Synopsis/Example:
X driver: Option "NoCRT2Detection" "on"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: OverruleFrequencyRanges
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series with video bridge
Description: This option enables or disables overruling bogus monitor frequency ranges.
As you might know, usually, monitor configuration is done using the HorizSync and VertRefresh keywords in the Monitor section. However, since the driver knows how to handle LCD and TV output, these frequency ranges aren't really necessary and very often lead to misconfiguration. Since 2004/06/30, the driver therefore overrules the given ranges by sane and proper data - unless a CRT device (=analog monitor) is in use.
Long story short: You only need to set HorizSync and VertRefresh if you have an analog CRT monitor connected (CRT1 or CRT2) and this monitor does not support DDC2B.
By default, this option is "on", meaning that the driver will overrule bogus or too tight frequeny ranges by suitable data if only LCD (or any other device connected via DVI-D) or TV (S-Video, composite, HiVision or YPbPr) are in use. If this option is set to "off", the driver will properly honour the given ranges even if they are wrong.
Synopsis/Example:
X driver: Option "OverruleFrequencyRanges" "off"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CRT1Gamma and CRT2Gamma
sisfb: n/a
top
Parameter: boolean (latter also one or three floating point numbers)
Chipsets: All (latter only on 300, 315, 330 series with a SiS video bridge (except SIS30B-DH if using LCD))
Description: The SiS driver supports gamma correction for CRT1 on all chipsets. For CRT2, this is only supported on SiS video bridges (thus not LVDS and not Chrontel). The 301B-DH (which is found in the ECS A90x laptops) does not support this for LCD output. These options enable (on) or disable (off) the gamma correction facility. By default, gamma correction is on for both CRT1 and CRT2.
On the 300, 315 and 330 series, the sisctrl utility allows enabling/disabling gamma correction as well as its set-up during server-run-time.
The option CRT2Gamma also accepts one or three floating point numbers between 0.1 and 10.0. This allows to setup a different gamma for CRT1 and CRT2. The gamma correction values for CRT1 are read from the Monitor section, while the gamma values for CRT2 can be given using this option. If one floating point number is supplied, this number will be used for red, green and blue. Lastly, if three floating point numbers are given, these will be read in the order red-green-blue.
Note: If you are running dual-head mode, the CRT1Gamma option should be placed in the Device section for CRT1. The CRT2Gamma option must be in the Device section for CRT2. If the option CRT2Gamma is provided with (a) floating point number(s), these will overrule the values from the Monitor section for CRT2.
Synopsis/Example:
X driver: Option "CRT2Gamma" "off" or
Option "CRT2Gamma" "1.2 1.0 1.0"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: GammaBrightness alias StoredGammaBrightness
sisfb: n/a
top
Parameter: one or three floating point numbers
Chipsets: 300, 315, 330 series
Description: X.org/XFree86's gamma correction is quite simple, usually. You select (one or) three gamma correction values between 0.1 and 10.0 in the Monitor section from which X.org/XFree86 will compute a default gamma ramp. X.org/XFree86's configuration file does not support things like setting gamma brightness.
What sisctrl does when you change the gamma brightness is recalculating the gamma ramp. This is the curve as seen in sisctrl.
This option provides a work-around for the missing feature of defining a gamma brightness in the X.org/XFree86 server configuration. They pre-define the gamma brightness values, which can later be set with sisctrl. Without sisctrl, these options do nothing; at least nothing visible.
Due to a design flaw in the X.org/XFree86 server, the SiS X driver itself cannot change the gamma ramp; it requires sisctrl to do so. Sisctrl knows a command line switch to read these values from the SiS X driver as given by these options and recalculate and set the gamma ramp accordingly (without opening the gui and requiring user interaction).
If you want a permanent non-default (read: non-1.0) gamma brightness, it is mandatory to set these options in your xorg.conf/XF86Config(-4) as shown in the Current-tab in sisctrl, and to execute sisctrl -sg every time after starting the X.org/XFree86 server, for example by editing your .xinitrc or .xsession file. This will set the gamma brightness given through these options.
If you are running Xinerama, sisctrl must be called twice during server start, once for each screen.
On Debian (and perhaps other) systems, invoking sisctrl at server start is easily done by creating a file in your home directory named .xinitrc (if that file does not exist). Place the following commands in that file:
sisctrl -sg
sisctrl -screen 1 -sg
. /etc/X11/Xsession
The second execution (with -screen 1) is for Xinerama only; if you don't run Xinerama, the second call will do nothing. So it does not hurt having both there.
Both options take one or three real numbers in the range from 0.1 to 10.0. If only one value is given, brightness for red, green and blue will be the same. If three values are given, these are read in the order red-green-blue. The default is 1.0 for all red, green and blue.
Note: If you are running dual-head mode, these options should be placed in the Device section for CRT1 if they are meant for CRT1.
Note: The SiS driver for X.org 6.9.0 will support automatic gamma brightness setting, rendering the work-around to start SiSCtrl at server start obsolete.
Synopsis/Example:
X driver: Option "GammaBrightness" "1.2 1.0 0.8"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CRT2GammaBrightness
sisfb: n/a
top
Parameter: one or three floating point numbers
Chipsets: 300, 315, 330 series with SiS video bridge
Description: This option has the same meaning as GammaBrightness, except that it is for CRT2. A major difference is though that the driver can use them directly without the work-around involving SiSCtrl. (But see the note below for dual head/Xinerama.)
As its counterpart, the option takes one or three real numbers in the range from 0.1 to 10.0. If only one value is given, gamma brightness for red, green and blue will be the same. If three values are given, these are read in the order red-green-blue. The default is 1.0 for all red, green and blue.
Note: In dual head and Xinerama mode, this option is a plain syonyme for GammaBrightness (but rule if both the "CRT2" version and the version without "CRT2" are given) and it works exactly the same way as its counterpart, hence the SiSCtrl workaround is required. The SiS driver for X.org 6.9.0 will support automatic gamma brightness setting, rendering this work-around obsolete.
Synopsis/Example:
X driver: Option "CRT2GammaBrightness" "1.2 1.0 0.8"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: NoHostBus
sisfb: n/a
top
Parameter: boolean
Chipsets: 5597/5598
Description: This option disables the CPU-to-VGA host bus on the SiS5597/5598. This host bus accelerates the CPU's access to video memory. Normally you should not set this option; only in case you use a SiS5597/5598 with a non-Pentium CPU, the host bus might cause problems and thus should be disabled.
Synopsis/Example:
X driver: Option "NoHostBus" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: RestoreBySetMode
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315 and 330 series
Description: This option can be used to overcome problems on LCD panels which might occure on some machines when switching to a virtual console or quitting X. Some machines have very, very timing sensible LCD panels which go bananas during text mode restoration. This option, if set to "yes", forces the X driver to set the old mode instead of dumbly restoring the register contents. Note: This behavior is, regardless of this option, always used on machines with a SiS30x/B/C/LV bridge and on machines with a SiS730 and an LVDS transmitter. On other machines, this option defaults to yes.
Synopsis/Example:
X driver: Option "RestoreBySetMode" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: MergedFB
MergedFBAuto
CRT2Position
MetaModes
CRT2HSync
CRT2VRefresh
MergedDPI
NoMergedXinerama
MergedXineramaCRT2IsScreen0
sisfb: n/a
top
Parameter: see below
Chipsets: 300/315/330 series with video bridge
Description: These options enable and configure "Merged Framebuffer Mode". This mode is a special dual head mode with Xinerama-like features, but has several advantages over normal Xinerama: It is much faster; DRI works (300 series only); it is much more flexible than Xinerama.
First off, what is Xinerama? This is a dual head mode where the two output devices (monitors, LCDs, TV) together form a large screen. You can move windows from one screen to the other.
So, how does MergedFB mode work?
It's easiest to start the explanation with an example. Let's say you have a virtual desktop of 2100x2100. Like Xinerama, both CRT1 and CRT2 show parts of this virtual desktop. In the following figure, depicting this scenario, the red rectangle is the area of the desktop you see on CRT2, the green rectangle is what you see on CRT1:
MergedFB
Unlike Xinerama, in merged framebuffer mode, the visible areas for both heads (=output devices, speak: CRT1 and CRT2) are always joined ("merged") either aside of each other or on top of each other. Therefore, there is never an invisible area between the part shown by CRT1 and the part shown by CRT2. (The example above only shows one of 4 possible ways to place CRT2 relative to CRT1; alternatively, CRT2 can be right of, above or below CRT1.)
The total visible area consists of both the display mode of CRT1 and CRT2, which are added together. Hence, if both CRT1 and CRT2 run at 1024x768 like in the example above, you see an area of total 2048x768. If the virtual desktop is larger than the total visible area, moving the mouse cursor towards the edges will scroll ("pan") the display on both CRT1 and CRT2.
In the following, the term "meta mode" will be used to describe a "display mode which consists of both a display mode for CRT1 and a display mode for CRT2".
Metamode
In the above figure, the yellow rectangle marks the currently active "meta mode". As you see, this meta mode is a combination of both the display mode of CRT1 and CRT2. The meta mode in this example is (1024+1024)x768, hence 2048x768. But don't worry, you don't need to calculate any meta modes in order to configure MergedFB mode. Meta modes are not described by their total size but by the following notation: [mode for crt1]-[mode for crt2], for example "1024x768-1024x768"
* To enable "merged framebuffer" mode, set the option MergedFB to on. Alternatively, set MergedFBAuto to on. The difference being: The first option will force the driver to run in MergedFB mode, even if there is no device connected to CRT1 or CRT2. The latter will check if both CRT1 and CRT2 are detected, and only if both are found, enable MergedFB mode. Using MergedFBAuto (since 2005/03/02 also Option "MergedFB" "auto") is most convenient for notebook users; if you have your monitor attached when starting the X server, MergedFB mode will be enabled; if the monitor is absent, MergedFB mode is disabled. No need to change the XF86Config(-4) file or use a different server layout. For example:
Section "Device"
Driver "sis"
...
Option "MergedFBAuto" "on"
...
EndSection
As said, since 2005/03/02 the driver also accepts Option "MergedFB" "auto" instead of Option "MergedFBAuto" "on".
* Relative position: The option CRT2Position specifies how CRT2 is to be placed relative to CRT1. This option takes one string parameter, which is either LeftOf, RightOf, Above, Below or Clone. In the example figure, LeftOf is used ("CRT2 left of CRT1"). Clone shows the same image on CRT1 and CRT2, hence it is like the default mirror mode. The default is RightOf. For example:
Section "Device"
Driver "sis"
...
Option "MergedFBAuto" "on"
Option "CRT2Position" "LeftOf"
...
EndSection
* Display mode configuration: The main difference to Xinerama is that MergedFB mode only requires one Device section in XF86Config(-4)/xorg.conf. The modes CRT1 and CRT2 should use are not defined in a second Screen section, but by the option MetaModes. This option takes a list of modes or mode-pairs, describing which modes to use for each CRT1 and CRT2. Pressing CTRL-ALT-+ (or CRTL-ALT--) goes forward resp. backwards in *that* list.
As of XFree86 4.3 (and all versions of X.org), the Modes statement in the Screen section is not relevant anymore in MergedFB mode. It can basically be left out.
For XFree86 4.2 and earlier only:
First, we must create the Screen section's Modes-list, which works as a pool from which the driver will combine its meta modes from. The Screen section's Modes list is to be considered the pool of modes from which the driver can combine the meta modes. Note: *All* modes named in the list of MetaModes (regardless whether they are for CRT1 or CRT2) must be named in the Modes list in the Screen section, too. For example:
Section "Screen"
...
SubSection "Display"
...
Modes "1024x768" "800x600" "640x480"
EndSubSection
...
EndSection
An example for a MetaModes list would look like this:
Section "Device"
Driver "sis"
...
Option "MergedFBAuto" "on"
Option "CRT2Position" "LeftOf"
Option "MetaModes" "1024x768-1024x768 800x600-1024x768 640x480-1024x768 800x600+800x600 800x600"
...
EndSection
In our example for a list of MetaModes the driver will use 1024x768 on CRT1 and 1024x768 on CRT2 ("1024x768-1024x768") at server start. Pressing CTRL-ALT-+ will switch to 800x600 on CRT1 and 1024x768 on CRT2 ("800x600-1024x768"). Switching the mode once again will result in 640x480 on CRT1 and 1024x768 on CRT2.
The last two modes in this example are special: Either using the "+"-sign instead of "-" or by just giving a mode without a dash followed by another mode, such as "800x600", will switch to 800x600 on both CRT1 and CRT2, and both CRT1 and CRT2 will show the same image (which results in the same behavior as if giving Option "CRT2Position" "Clone"; the difference is that if CRT2Position is "Clone", all MetaModes will be clone-modes whereas in our example you can mix really merged modes with clone modes). Using the "+"-sign has the advantage that you can specify two different modes for CRT1 and CRT2 for cloning. These don't even have to be of the same resolution. "1024x768+800x600" is a valid "clone"-mode; in such as case, the smaller area (here CRT2) will be panned within the larger area (here CRT1). Note: The "+"-sign is supported as of 2004/10/15.
If the MetaModes option is missing, the driver will combine the largest available mode for CRT1 with the largest available mode for CRT2 to one single meta mode. This meta mode will be the only mode available and its dimension depends on the CRT2Position setting (which defaults to RightOf).
* Monitor configuration: The data in the (only) Monitor section, such as the frequency ranges, will be used for CRT1. Especially if you are using a secondary VGA monitor that lacks DDC support, the options CRT2HSync and CRT2VRefresh come handy. These take the same parameters in the same format as their counterparts in the Monitor section; for instance
Section "Device"
Driver "sis"
...
Option "MergedFBAuto" "on"
Option "CRT2Position" "LeftOf"
Option "MetaModes" "1024x768-1024x768 800x600-1024x768 640x480-1024x768 800x600"
Option "CRT2HSync" "31.5-84"
Option "CRT2VRefresh" "50-75"
...
EndSection
Note: As a general rule, leave these options out. The only case where they might eventually be required is if you use a (analog) CRT monitor connected to the secondary VGA that lacks DDC support. All other cases (LCD, TV, VGA with DDC support) will be handled automatically. [Technical information: If the CRT2HSync and/or CRT2VRefresh options is/are missing, the data provided via DDC, if available, will be used. If the CRT2 device does not support DDC (such as TV and most laptop LCD panels), the driver will choose sane values by itself. Only if that for some reason fails to produce a proper result, use these options.]
* Optional: The absolute size of the virtual desktop can optionally be specified with the generic keyword Virtual which is to be placed in the Screen section's Display subsections. In our example, this would look like this:
Section "Screen"
...
SubSection "Display"
...
Virtual 2100 2100
...
EndSubSection
...
EndSection
If the given virtual size is less than the resolutions of CRT1 and CRT2 added together, the areas shown on CRT1 and CRT2 will overlap. In most cases, you'll find it most useful to limit the virtual dimension to the largest combined mode ("meta mode"); if 1024x768 on CRT1 and 1024x768 on CRT2 are your highest modes, Virtual 2048 768 would be ideal (assuming that you place your output devices aside each other and not above each other; otherwise it would be Virtual 1024 1536).
Note: As a general rule, leave this option out. If the Virtual keyword is not provided in the configuration file, the virtual size will be the size of the largest meta mode. If the MetaModes option is missing, too, the virtual size will be the size of the automatically generated meta mode (see below).
* Monitor size configuration: If you start the X server in MergedFB mode and don't notice any changes in, for example, font sizes, you may skip this paragraph.
Many of X.org/XFree86's drawing functions depend on information on the physical display size. Basically, this means the absolute physical size of your output device. X.org/XFree86 uses this information to calculate the Dots Per Inch (DPI) of your display device. Among others, font pixel sizes are calculated based on this information. Many distributions, like Debian, by default, don't really care about this DPI value and use a default value (75 or 100) which is given to the XServer through the command line. However, if no DPI value is given through the command line, it is eventually calculated, either from DisplaySize information given in the Monitor section, or from such information provided by the monitor itself through DDC. If neither DisplaySize is in the Monitor section, nor data is delivered through DDC, 75 DPI is assumed.
If the DPI value is given through the command line, everything is OK. But it is obvious that the way the DPI value is calculated, if not given through the command line, requires some adaptions for MergedFB mode. First, if you specify a DisplaySize in the Monitor section, this display size must be the overall size of both CRT1 and CRT2. "Overall" means, depending on your setup, adding either the physical horizontal sizes (in case of placement side-to-side) or vertical sizes (if placed on top of each other), and give these dimensions to DisplaySize. I recommend not specifying DisplaySize.
If DisplaySize is omitted, the DDC data (if available) will be used. The driver, in MergedFB mode, will combine the physical display sizes of both CRT1 and CRT2, and calculate the DPI value from this combined information. This may fail to produce convenient results, especially if the physical sizes of CRT1 and CRT2 are very different. For such cases, the driver provides the option MergedDPI. This option takes, within quotation marks, two integer values, which represent the horizontal (X) resp. vertical (Y) DPI value to be used the the entire merged screen. For example:
Section "Device"
Driver "sis"
...
Option "MergedFBAuto" "on"
Option "CRT2Position" "LeftOf"
Option "MetaModes" "1024x768-1024x768 800x600-1024x768 640x480-1024x768 800x600"
Option "CRT2HSync" "31.5-84"
Option "CRT2VRefresh" "50-75"
Option "MergedDPI" "100 100"
...
EndSection
will set the DPI to 100 for both X and Y. (For technical reasons it is not possible to use different DPI values for CRT1 and CRT2 in MergedFB mode.)
I myself always use 100 DPI (given through the server command line as configured by Debian), which produces IMHO the best result.
* Automatic configuration: Since 2003/10/06, the driver will try to configure MergedFB mode automatically as soon as the options MergedFB or MergedFBAuto are set. All other options have defaults as follows:
1. If the option CRT2Position is missing, RightOf is assumed.
2. If the option MetaModes is missing, the driver will combine the largest available mode for CRT1 with the largest available mode for CRT2, forming one single meta mode.
3. If the CRT2HSync and/or CRT2VRefresh option(s) is/are missing, the driver will use the timing data derived from DDC; if the CRT2 device does not support DDC, the monitor data for CRT1 (from the Monitor section) will be used.
4. If the Virtual keyword is missing in the Screen section, the driver will adapt the virtual size to the size of the largest meta mode.
As you see, MergedFB mode can now be basically configured setting one single option, either MergedFB or MergedFBAuto.
Note that MergedFB mode, depending on the virtual framebuffer size, needs quite much video memory. You can calculate this by the formula X x (depth / 8) x Y. A virtual screen of 2048x768 at 24bpp needs 6MB. For 4088x4096 at 24bpp, 64MB are needed, which leaves no RAM for *anything* else. I recommend running this mode at 16bpp, which only requires half as much RAM. The reason for pointing this out is that sisfb needs to know that, too, if DRI is to be used!
One more hint: It is recommended to add "cloning" modes of common dimensions (such as 1024x768 and 800x600) to the list of meta modes, i.e. modes which are not specified in pairs (for instance: Option "MetaModes" ".... 1024x768 800x600"). The reason is the following: In merged framebuffer mode, the X server *only* sees the meta modes, speak: modes which are the result of combining the available modes for CRT1 and CRT2. It simply believes there are display modes like 2048x768 and so on. It does *not* see the modes originally given in the Modes list of the Screen section. Many applications, especially games, rely on the availability of commonly used modes such as 1024x768, 800x600 or 640x480. Adding them to the list of meta modes like in the example above makes these modes available to such applications.
About Pseudo-Xinerama support
If you are running a system with two monitors, it might very likely be desireable to allow window managers to place windows smartly with regard to the physical gap between the output devices, and to, for example, maximize windows only on one screen, not both. This is what, if running Xinerama, the Xinerama extension does for applications such as window managers: Technically speaking, the Xinerama extension provides a set of functions for clients to discover the current display mode configuration (screen sizes, edge coordinates, etc).
For MergedFB mode, the SiS X driver has a built-in (pseudo) Xinerama extension which is compatible to the "real" Xinerama extension as it tells window managers and other application about the screen layout, ie sizes etc. However, how useful the information delivered by this pseudo-Xinerama extension is, depends on the "sanity" of your MetaModes up to certain degree:
As you might have noticed, MergedFB mode is a little like Xinerama. But it goes beyond it in some important issues: The displayed area of the both heads may overlap, there is a "Clone" mode, and the boundary between CRT1 and CRT2 may float. While in real Xinerama, the "screens" displayed on CRT1 and CRT2 are always of the same size during an X session, this is not the case in MergedFB mode: Here, it depends on the current meta mode, where the two visible areas of the framebuffer are located, how big they are, and where the first head's one ends and the other head's one starts.
See the following figure on these conceptional differences between Xinerama and MergedFB mode:
MergedFBvsXinerama
Figure 1 shows "ideal" Xinerama mode: Both heads use their largest modes, showing all of their screens, forming one large "virtual screen" (the dark filled rectangle). Note the yellow line inbetween; this line marks the boundary between the two screens. This boundary is fixed, and cannot be changed by a mode switch on each of the heads, as depicted in figure 2: After a mode switch on each head, they each show a smaller area of their respective screens, and the visible area of each head can flow within the light red resp. light green area, which are in fact the boundaries of the two screens. The two visible areas can never go across the yellow line.
Figure 3 shows "ideal" MergedFB mode: Again, both heads use their largest modes, resulting in a completely visible "virtual screen". So far, this is like Xinerama. But why is there no yellow line? Look at figure 4: After a mode switch, the two heads show smaller areas of the "virtual screen", but they always stick together and the whole visible area can be panned within the whole "virtual screen". This is symbolized by the grey arrows. Therefore, there is no fixed boundary anywhere between the two heads.
Simply speaking, what the real Xinerama extension does for clients is to inform about the screen sizes and the boundary line. According to the figures above, this is the size of the light red and light green areas of figure 2, and the coordinates of the yellow line.
Things aren't that simple with SiS Pseudo-Xinerama: In MergedFB mode, as the figures clearly show, there is no light red or light green rectangle and there is no yellow line. Hence, to be absolutly accurate, the Xinerama information varies with each meta mode.
Since the concept of MergedFB mode is relatively new, many window managers and applications do not expect the Xinerama information about screen placement and size to change during a server session. However, KDM, the KDE display manager, is - under some circumstances - working correctly with dynamic changes as of KDE 3.3. But beware: Still many window managers query the Xinerama extension only once during startup. The yet common conclusion has to be that the Xinerama information is to be considered static during server run-time.
Therefore, the SiS X driver very carefully calculates this information once, based on all given meta modes. I won't give you a detailed explanation on how this is done as this certainly is beyond the scope of this document, but remember this: Unusual MergedFB mode configurations, such as overlapping visible areas (if the virtual desktop is smaller than the largest meta mode) or a virtual desktop larger than the largest meta mode, might seriously confuse some window managers and other applications. The result might be quite inconvenient. In this case, set the option NoMergedXinerama to yes which will disable the SiS X driver's pseudo-Xinerama extension. By default, this SiS pseudo-Xinerama extension is enabled.
Update: Since 2005/03/04, the X driver allows using the X Resize and Rotate extension (RandR) while in MergedFB mode and with pseudo-Xinerama enabled (while previous versions disabled RandR if pseudo-Xinerama was enabled). Usually, RandR and Xinerama are mutually exclusive: If you run your X server in (normal) Xinerama mode, RandR will be disabled. However, this is no longer the case with the SiS pseudo-Xinerama. But there are some caveats:
* The RandR extension in XFree86 4.3 and X.org prior to 6.8 had some bugs which might result in undesirable screen changes. Update to X.org 6.8.2 to avoid this.
* Choose your meta modes carefully. Remember that the server only sees the dimensions of the meta modes, not what display modes they consist of. This might lead to identically looking meta modes despite consisting of different display modes. For example, "1280x1024-1024x768" and "1024x768-1280x1024" both result in a meta mode of "2304x1024". If such a seemingly duplicate mode is encoutered by the RandR extension during initialization, it would normally ignore the second meta mode because RandR builds on the concept that a display size (= identical to "mode" for RandR) can only occure once. The SiS driver solves this by giving the second mode a different refresh rate. If you run the xrandr utility, you might therefore encounter unusual rates listed, such as 1075 and the like. The refresh rate xrandr shows here is the real refresh rate of the CRT1 mode, plus 1000 (or 2000, 3000) if more seemingly identical meta modes exist. In our example, xrandr would show a size of 2304x1024 with refresh rates of eg. 75 and 1075. If you select the size with refresh rate 1075, the second meta mode will be set (in our example "1024x768-1280x1024"). Using SiSCtrl simplifies this as SiSCtrl takes care of this duplication problem all by itself.
* Apart from the RandR problem, seemingly duplicate meta modes consisting of different display modes for CRT1 and CRT2 make a sane calculation of the Xinerama information extremely hard, if not impossible. Hence, try to avoid such a setup.
* As mentioned above, KDM is now capable of dealing with dynamic Xinerama information changes. However, it does this only if at the same time the display size (via RandR) is being changed. Hence, the X driver will not update its Xinerama information on each mode switch, but do so only if the display size is changed at the same time. (I have no information on other display/window managers in this regard).
* If your display/window manager is smart enough, using RandR with pseudo-Xinerama can do tremendous things. You can, for example, switch to a clone mode (and select "Resize to display mode" in SiSCtrl), and your whole desktop will adapt to the new layout, ie kicker will be at the correct place, windows will be properly maximized, etc and there will be no panning. For usage examples, see below.
Non-rectangular screens: (Requires X driver 2005/03/04 or newer with pseudo-Xinerama enabled.) If you have display devices with different maximum resolutions you might desire a non-rectangular screen to avoid panning. Let's say you have a laptop with a 1280x800 panel and a VGA monitor for 1280x1024. So you would say
Section "Device"
Driver "sis"
...
Option "MetaModes" "1280x1024-1280x800"
...
EndSection
Usually, the total screen size would be 2560x1024 in this case (2560 = 1280 + 1280; 1024 is the largest y resolution of all metamodes). However, given that the LCD only has a vertical resolution of 800, it will not entirely fit on it. Therefore, the driver will pan on the LCD when the cursor reaches the screen edges. Some people don't like that, and as a matter of fact, Window managers will treat the screen as 1280x1024, ie maximize windows to 1280x1024 on the LCD, etc. Now, in order avoid this, give
Section "Device"
Driver "sis"
...
Option "MetaModes" "1280x1024-1280x800"
Option "MergedNonRectangular" "on"
...
EndSection
Now the driver will calculate the Xinerama screen layout considering the maximum resolutions for each device. The Xinerama information passed to window managers will describe a non-rectangular layout:
MergedFBvsXinerama
Beware: This leads to an inaccessible area (dark yellow in the above figure). "Inaccessible" means that you cannot pan into it and you cannot move the mouse into it. However, dumb (ie not Xinerama-aware applications) might use to open windows in this area. These windows will not be accessible!
Be careful with your meta modes when enabling non-rectangular screens. As mentioned, (pure) modeswitching (without at the same time resizing the screen) will NOT change the Xinerama layout. Switching to a different meta mode than the one the Xinerama layout is based on might therefore have some really strange looking effects. Also, clone-modes will look odd on such setups: When a meta mode is a "cloning" mode, the X driver will ignore the previously inaccessible area and allow panning into it.
Screen enumeration: In real Xinerama, there are two screens (we call them "Screen 0" and "Screen 1" here for simplicity; these numbers are given in the XF86Config(-4) file). Unlike Xinerama, in MergedFB mode the X server only knows one screen. However, applications using the Xinerama extension always assume more than one screen. KDM, for example, seems to place its login window always on "Screen 0"; "kicker" appears to display on "Screen 0", too. In order to decide, which of the heads (CRT1 or CRT2) should be "Screen 0" (ie some sort of "master screen"), use the option MergedXineramaCRT2IsScreen0: If this is set to no, CRT1 will be "Screen 0" and CRT2 will be "Screen 1", otherwise vice versa - regardless of the relative placement of CRT1 and CRT2. By default, CRT2 will be "Screen 0" if placed left or below CRT1.
About offset support
What follows is a description of a feature hardly anyone will ever need. However, for completeness reasons, it is implemented anyway. The driver has this feature since 2004/11/30.
In cases where the physical output devices are not aligned, such as for example when the VGA monitor is located higher than the LCD panel, it might be desirable to reflect this misalignment in MergedFB mode. When you move a window from one screen to the other, it should not "jump" but be at the physically identical position. This is what the "Offset" is for.
MergedFBvsXinerama
In figure 1 above, CRT1 is positioned higher than CRT2, in figure 2 vice versa. The white arrows left/right of the images depict the offset. When you move a window from CRT2 to CRT1, it will be at the vertically same position as on CRT2, and vice versa.
Using the offset will result in a non-rectangular desktop, with two dead (ie inaccessible) areas, shown as yellow boxes above. As with non-rectangual screens in general, these dead areas cannot be panned into but this setup will not keep dumb (speak: non-Xinerama-aware) window managers from opening windows inside them. Basically, this is the same effect as for non-rectangular setups using the "MergedNonRectangular" option.
To create a setup like figure 1 above, the option CRT2Position can be given a numerical value besides the usual placement keyword. For example:
Section "Device"
Driver "sis"
...
Option "CRT2Position" "LeftOf 100"
...
EndSection
This tells the driver that CRT2 is located 100 pixels lower than CRT1. The meaning of the numerical argument depends on the positioning keyword:
* If CRT2Position is LeftOf or RightOf, the offset is meant vertically, where a positive number means "CRT2 lower than CRT1" (as in figure 1) and a negative number means "CRT2 higher than CRT1" (as in figure 2)
* If CRT2Position is Above or Below, the offset is meant horizontally, where a positive number means "CRT2 further to the right than CRT1" and a negative number means "CRT2 further to the left than CRT1"
Again, beware: Using this Offset requires the window manager to properly honour the Xinerama information provided by the driver's Pseudo-Xinerama extension. If it does not do that, you might end up with windows being opened in the dead areas.
Note that the RandR extension will be disabled if using the Offset.
The advantages of MergedFB mode:
* DRI works (on 300 series), while it is disabled in (real) Xinerama mode
* DGA works over both screens (just think of dual headed vmware...)
* No XServer computing overhead for two screens like in (real) Xinerama
Now for the limits of this mode:
* The absolute (theoretical) maximum virtual framebuffer size is 4088x4096
* On the 300 series, the accelerator engine is limited to a line length of 8191 bytes. This means that the maximum virtual screen width at 24bpp is 2040 for 2D acceleration. Above this, there will be no 2D acceleration. At 16bpp, the maximum for acceleration is 4088, though.
* 8bpp modes are not supported. This is a limit of all dual head modes, including Xinerama.
An example XF86Config-4 is available in the download section.
Usage examples (some require X driver and sisctrl from 2005/03/04 or newer)
* Simple setup: The most simple way to use MergedFB mode can be set up this way:
Section "Device"
Driver "sis"
...
Option "MergedFB" "auto"
EndSection
(With older drivers, the option "MergedFBAuto" should be set to "on" instead of "MergedFB" "auto".)
You don't need to set any other option unless the defaults don't suit you. By default, CRT2 is assumed right of CRT1 and the MetaModes as well as the total screen size will be calculated automatically by the largest supported modes for each CRT1 and CRT2. If your output devices support different maximum resolutions and you don't like panning, simply change the config to
Section "Device"
Driver "sis"
...
Option "MergedFB" "auto"
Option "MergedNonRectangular" "on"
EndSection
to avoid panning on the device with the lower maximum resolution.
* Laptop setup example: Let's say, you have a laptop with a 1280x800 LCD display, and an external monitor that can handle 1280x1024. The most convenient setup would be:
Section "Device"
Driver "sis"
...
Option "MergedFB" "auto"
Option "MetaModes" "1280x1024-1280x800"
Option "MergedNonRectangular" "on"
EndSection
This will result in a non-rectangular screen as described above. Now, let's say you want to disconnect your external monitor and continue working without restarting the X server. As a prerequisity, change your setup to
Section "Device"
Driver "sis"
...
Option "MergedFB" "auto"
Option "MetaModes" "1280x1024-1280x800 1280x800"
Option "MergedNonRectangular" "on"
EndSection
What you now can do, is simply using SiSCtrl to select "Resize to display mode" and switch to 1280x800. Viola... your desktop will be switched to a cloned 1280x800 mode and resized to 1280x800. You can now disconnect your external monitor. (Provided your window manager is smart enough to support RandR and dynamic Xinerama - KDM is as of 3.3.).
* Using your second screen as a looking glass: You can use your second display device as a looking glass. An example for this would be:
Section "Device"
Driver "sis"
...
Option "MergedFB" "auto"
Option "MetaModes" "1280x1024-1280x1024 1280x1024+640x480"
EndSection
The server will start with 1280x1024 on both displays showing a screen of total 2560x1024. After a mode switch you will be presented with CRT1 still running at 1280x1024, but CRT2 being 640x480. Since the "+" sign specifies a clone mode, both displays will show the same area. Try that out to see what I mean. If you use RandR (for example via SiSCtrl's "Resize to Display mode"), your desktop will be shrunk from 2560x1024 to 1280x1024 and hence be entirely visible on CRT1 while CRT2 is your looking glass by running a much lower resolution.
* * *
Name:
X driver: EnableSiSCtrl
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: This option enables the interface for sisctrl, the SiS Display Control Panel. If this option is not set to yes, sisctrl will not work. This option is there for security reasons; only root can set options in the X configuration file, and hence control whether the users are allows to tune their display.
The default is no; sisctrl will not work with this setting.
Synopsis/Example:
X driver: Option "EnableSiSCtrl" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: BenchmarkMemcpy
sisfb: n/a
top
Parameter: boolean
Chipsets: all
Description: By default, the X driver will benchmark different methods for transferring data from system memory to video memory. These methods consist of assembly routines using MMX, SSE, 3DNow! and other CPU features. This benchmark us performed once during X server start. That fastest of these routines is then chosen for Xv and other purposes.
If you for some reason don't want to the driver to use any of these methods, set this option to no.
Note: On any other CPU than x86 or AMD64 compatible ones, the system default memcpy() routine is used.
Synopsis/Example:
X driver: Option "BenchmarkMemcpy" "no"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: UseSSE
sisfb: n/a
top
Parameter: boolean
Chipsets: all
Description: One of the X driver's memory transfer methods makes use of SSE instructions on x86 (ia-32) and AMD64, if supported by the CPU. However, while the CPU might support SSE, the OS needs to specifically support it, too. Unfortunately, the X server does not allow checking operating system support for SSE; therefore, using SSE instructions is disabled by default. To enable it, set this option to "on".
Linux (2.4, 2.6) and *BSD generally support SSE (if the kernel is compiled for the correct CPU), so it's save to set this option to "on". If you get a "signal 4" during X server start, set this option to "off".
(X.org 6.9.0 will support automatic detection. I committed the required code to X.org CVS on 2004/10/29.)
Synopsis/Example:
X driver: Option "UseSSE" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: ScaleLCD
sisfb: scalelcd
top
Parameter: boolean
Chipsets: 300, 315, 330 series with digitally connected LCD panel
Description: LCD, plasma and other digital panels have a so-called "native resolution". This resolution matches the amount of LCD/plasma cells, horizontally and vertically. This resolution, on most devices, also marks the maximum resolution the panel can handle.
If a lower resolution should be displayed, there are basically two choices: 1) To scale (enlarge, zoom) the output to the panel's native resolution, or 2) to show the output in the middle of the screen and draw black bars around it.
Most (if not all) external panels have built-in scalers that handle lower resolutions automatically. Most laptop panels, however, do not. SiS chipsets support internal scaling, ie. they have a built-in scaler that is independent of the panel's scaler.
Setting the ScaleLCD option to yes (or 1 in case of sisfb) forces the driver to use the SiS hardware scaler in order to scale the output on the panel in modes with resolutions lower than the panel's native resolution to that native resolution. In other words: If this is enabled, LCD output will fill the whole screen, regardless of the display mode (with a few exceptions; some display modes cannot be scaled).
Setting the ScaleLCD to no (or 0 in case of sisfb) will disable usage of the SiS hardware scaler; different panels will, however, react differently to this. Laptop panels, as mentioned, usually lack a scaler. Therefore the driver, on such panels, will simply draw black bars around the image. For external panels (connected through DVI-D, for instance) the behavior depends on the CenterLCD option (see below). By default, the driver will pass the display mode timing (60Hz for built-in modes) directly to the panel which will eventually activate its own, built-in scaler (if available) and fill the whole screen. For more information, see immediatly below.
For some display modes in combination with some panels the ScaleLCD setting will be overruled by the driver. For example, 720x480, 720x576 and some further modes which are mostly intended for TV output will not be scaled to the LCD panel's native resolution.
Warning: Some external (ie. non-laptop) panels might lack an internal scaler or might not recognize some display modes. So if your panal only displays garbage or nothing, quit the X server and remove that option from the configuration file, or set the option CenterLCD to yes.
The default depends on the very panel.
This setting can be changed during runtime using the SiSCtrl tool.
Synopsis/Example:
X driver: Option "ScaleLCD" "yes"
sisfb (module): modprobe sisfb scalelcd=1
sisfb (kernel): video=sisfb:scalelcd:1
* * *
Name:
X driver: CenterLCD
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series with 301/301B/301C video bridge
Description: If scaling of LCD output is disabled (see immediatly above), the driver has two choices: Either output 1:1 data (ie pass the display mode timing unmodified to the panel) and rely on the panel to scale, or center the screen on the LCD panel's native mode (ie the mode which matches the panel's native resolution) and fill the rest with black bars.
This option is only supported for panels connected via DVI-D (ie TMDS devices). LVDS LCD devices, as driven by the 30xLV bridges, have no built-in scaler and won't be able to handle 1:1 data.
This option, if set to yes, will make the driver use the panel's native mode and center the (unscaled) image on the screen. For instance, if you have a 1280x1024 panel, all modes with resolutions lower than 1280x1024 will show black bars around the visible screen which itself is centered.
If this option is set to no, the driver will send out the same timing as for a normal CRT monitor (1:1 data at 60Hz for built-in modes; if the user specified a mode through a modeline, the modeline's exact timing is used). If the LCD panel has a built-in scaler, the screen will fill the whole panel. If the panel lacks a built-in scaler, behavior is unpredictable. Cheap panels are, however, not always able to recognize more than a limited number of display modes. If your panel shows garbage or nothing, quit the X server and switch on centering.
The default is to pass 1:1 data and to rely on the panel to scale. This is the recommended setting, especially for plasma panels and HDTV sets (if connected via DVI-D).
This setting can be changed during runtime using the SiSCtrl tool.
Synopsis/Example:
X driver: Option "CenterLCD" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: PanelDelayCompensation
sisfb: pdc
top
Parameter: integer
Chipsets: 300 series with LVDS transmitter or SiS301B-DH video bridge and LCD panel
315 series with SiS30xLV video bridge and LCD panel
Description: This option/parameter is only for machines with a 300 series chipset, LVDS transmitter or 301B-DH bridge and a LCD display, and for 315 series machines with a 30xLV bridge and LCD panel.
Due to bad BIOS design, the driver is not in all cases able to detect the correct LCD panel delay compensation value. Please don't bother with what this might be. The point is: If your panel shows a kind of "small waves" (I don't know a better way to describe this) or wrong colors after starting X, first try setting this option to either "4", "32" or "24" on 300 series, 6 or 4 on 315 series. If these values don't work, try any other value (300 series: between 4 and 60 in steps of 4; 315 series: any value from 0 to 31)
You will very probably not need this option. The X driver contains a "black-list" with machines known to require non-default values. Consult the X log to see if your machine is detected as such (MITAC 7521T). The Asus A1xxx laptops are not in this list because their PCI ID is not unique to systems requiring a special setting.
This option along with the PanelDelayCompensation1 option will probably not ever be needed on 661/741/760 since SiS finally had the bright idea to store the required values at fixed positions in the BIOS where the driver can read them out.
Synopsis/Example:
X driver: Option "PanelDelayCompensation" "32"
sisfb (module): modprobe sisfb pdc=32
sisfb (kernel): video=sisfb:pdc:32
* * *
Name:
X driver: PanelDelayCompensation1
sisfb: pdc1
top
Parameter: integer
Chipsets: 315 series with SiS30xLV or 301C video bridge and LCD panel
Description: This option has the same function as PanelDelayCompensation (see above), but for LCD-via-CRT1 mode. Valid range is from 0 to 31.
This option along with the PanelDelayCompensation option will probably not ever be needed on 661/741/760 since SiS finally had the bright idea to store the required values at fixed positions in the BIOS where the driver can read them out.
Synopsis/Example:
X driver: Option "PanelDelayCompensation1" "2"
sisfb (module): modprobe sisfb pdc1=2
sisfb (kernel): video=sisfb:pdc1:2
* * *
Name:
X driver: SpecialTiming
sisfb: specialtiming
top
Parameter: string
Chipsets: 300, 315, 330 series
Description:
This option is not needed on usual systems. Please do not play with it.
This option is only for very rare cases where the standard-timing of LCD panels does not work. A typical example for such a situation are the Barco iQ projectors. The driver is supposed to auto-detect these systems, but this may fail under some circumstances.
There are different ways for the driver to identify a machine requiring tweaks:
First, the driver is able to identify different systems, namely the Barco iQ R- and G-series by their current video BIOS. If that video BIOS is updated to a new version, auto-detection will fail.
Other machines requiring some tweaks are the Inventec/Compaq Presario 3045US/3017LC (1280x1024) and clones thereof, the Clevo L285/L287 (1024x768) as well as Clevo D4x0S/D4x0H (I don't exactly know which ones require this). These are less prone to such BIOS issues as they are detected by their PCI subsystem IDs. However, in case of some of the Clevos, the BIOS version is relevant, too.
Some embedded systems (so far only encountered with SiS630 or SiS550) use a 848x480 parallel or LVDS panel; since these cannot be detected correctly, setting this option respectively is mandatory. (Since this is for specially customized systems only, I will not document this feature and the consequences of enabling it furtherly here. If you have questions regarding this option, please ask.)
Basically, auto-detection should work (except for the 848x480 panels). In case it fails, set this option accordingly. Currently, the drivers know the following parameters to this option:
* BARCO_1366 (for Barco iQ R series),
* BARCO_1024 (for Barco iQ G series),
* COMPAQ_1280 for the Inventec/Compaq Presario 3045US, 3017LC and other models (1280x1024)
* CLEVO_L28X_1 and CLEVO_L28X_2 for (2 different types of) Clevo L285/L287,
* CLEVO_D4X0 for Clevo D400 (tested with 1400x1050 panel),
* CLEVO_D2X0ES for Clevo D22ES/D27ES,
* UNIWILL_N243S9 for Uniwill N243S9 (Siemens-Fujitsu Amilo EL),
* UNIWILL_N35BS1 for Uniwill N35BS1,
* ECS_A928 for some ECS A928,
* ASUS_L3X00 for Asus L3000D (SiS740 + Chrontel 7019), and
* PANEL848x480 for directly connected parallel or LVDS panels with a resolution of 848x480.
* NONE can be used to disable the automatic detection. No special timing will be used then.
Warning: Do not play around with this option unless you really know what you are doing. Wrong panel timing can damage your LCD panel.
Synopsis/Example:
X driver: Option "SpecialTiming" "BARCO_1366"
sisfb (module): modprobe sisfb specialtiming=BARCO_1366
sisfb (kernel): video=sisfb:specialtiming:BARCO_1366
* * *
Name:
X driver: LVDSHL
sisfb: lvdshl
top
Parameter: integer
Chipsets: 315, 330 series with 30xLV video bridge and LCD panel
Description: This option is only for machines with a SiS 301LV or 302LV video bridge and a LCD panel; hence mostly for laptops.
The only symptom that makes this option required is if the image on the LCD panel is too dark or shows very pale colors. In this (and only this) case try setting this option first to 1, and then try the other values 2, 3, 0. If that does not cure the problem, remove this option again (and contact me).
The parameter to this option is an integer from 0 to 3.
Warning: Do not use this option if the driver works well without it.
Synopsis/Example:
X driver: Option "LVDSHL" "1"
sisfb (module): modprobe sisfb lvdshl=1
sisfb (kernel): video=sisfb:lvdshl:1
* * *
Name:
X driver: EMI
sisfb: n/a yet
top
Parameter: integer
Chipsets: 315, 330 series with 302LV/302ELV video bridge and LCD panel
Description: This option is only for machines with a SiS 302LV or 302ELV video bridge and a LCD panel; hence mostly for laptops.
The only symptom that might make this option required is if the image on the LCD panel loses sync sometimes or shows uneven edges (like a comb), especially right after starting the X server or after mode switches. I came accross two machines yet which would need this option (Compaq 3045US and compatible with 1280x1024 panel; Compal machines with a 1400x1050 panel), but users of these two types of machines don't actually need to set the option because the driver recognizes them and uses the correct values automatically.
The parameter to this option is an integer from 0 to 0x60ffffff. The upper 8 bits should be either 0x20 or 0x60. This makes a big difference as I have found out. The most common, possibly required values are
* for 1024x768 panels: 0x60056033 or 0x600d7040
* for 1280x1024 panels: 0x2012d06b or 0x600d706b
* for 1400x1050 panels: 0x60066000 or 0x600d7040
* for 1600x1200 panels: ?
You may want to try these if the problem shows up on your machine, each either beginning with 0x60... or 0x20....
Warning: Do not use this option if the driver works well without it. It may have undesirable (but harmless) results.
Synopsis/Example:
X driver: Option "EMI" "0x2012d06b"
sisfb (module): n/a yet
sisfb (kernel): n/a yet
* * *
Name:
X driver: ForcePanelRGB
sisfb: n/a yet
top
Parameter: integer
Chipsets: 300, 315, 330 series with video bridge and (LVDS) LCD panel
Description: The only symptom that might make this option required is if the image on the LCD panel shows clear instead of smooth color gradients in 24bpp mode.
Usually, for LVDS LCD panels (be it on a SiS LV bridge, be it on a third party LVDS transmitter), the BIOS informs the driver about whether the LCD panel has a maximum color depth of 18 or 24 bit. In some very rare cases, the BIOS reports this wrongly (as it seems for example on the MSI m250).
This option takes an integer with the value 18 or 24.
Warning: Do not use this option if the driver works well without it. It may have undesirable (but harmless) results.
Synopsis/Example:
X driver: Option "ForcePanelRGB" "18"
sisfb (module): n/a yet
sisfb (kernel): n/a yet
* * *
Name:
X driver: TVStandard
sisfb: tvstandard
top
Parameter: string
Chipsets: 300, 315, 330 series; 6326 with TV (X driver only)
Description: The basic choice of TV standard is done in the BIOS setup utility on integrated chipsets. On dedicated cards, the TV standard is usually set by a jumper. However: The driver auto-detects the BIOS setup/jumper setting for PAL or NTSC (or PAL-M or PAL-N) in most of the cases. If it fails to do this on your machine, ie. you chose PAL in the BIOS setup but only get a black & white image, use this option to correct the problem. Valid values are PAL or NTSC, on the 630/730 and the 315/330 series with a SiS bridge or a Chrontel 7019 (not 7005!) also PALN (for Argentina, Paraguay, Uruguay), PALM (for Brazil), and NTSCJ (Japanese NTSC; untested).
On the 300, 315, 330 series the sisctrl utility allows changing the TV standard during X server run-time.
Remember to always give parameters in lower case for sisfb ("pal", "ntsc", "palm", "paln").
Synopsis/Example:
X driver: Option "TVStandard" "PAL"
sisfb (module): modprobe sisfb tvstandard=pal
sisfb (kernel): video=sisfb:tvstandard:pal
* * *
Name:
X driver: TVXPosOffset
TVYPosOffset
sisfb: tvxposoffset
tvyposoffset
top
Parameter: integer
Chipsets: 300, 315, 330 series; 6326 with TV output
Description: These options allow tuning the screen position on the TV by specifying an offset to the default position. Both options allow values from -32 to 32 (on the 6326 from -16 to 16). A negative value shifts the screen to the left/top, a positive value shifts to the right/bottom.
For Chrontel 700x only: The unit seems to be between 8 and 16 pixels. Since a negative absolute position is not allowed and some modes' default position is quite at some edge, it may happen that the position is not changed in the specified amount. An example for this is 800x600 in super overscan: The screen's default vertical position is almost at 0, so the remaining margin for moving up is very limited.
These options are not supported on the Chrontel 701x.
Since 2003/05/06, the 300/315/330 series also support XV properties for changing the position at run-time. By their nature, changes of XV properties only take effect during Xv usage. The properties are called XV_TVXPOSITION and XV_TVYPOSITION and accept values from -32 to 32.
On the 300, 315 and 330 series the position of the TV image can be changed during server-run-time using the sisctrl utility.
sisfb supports this parameter since 2004/05/21. For sisfb, the position can be changed later using the sisfbctrl utility.
Synopsis/Example:
X driver: Option "TVXPosOffset" "-10"
sisfb (module): modprobe sisfb tvxposoffset=10
sisfb (kernel): video=sisfb:tvxposoffset:10
* * *
Name:
X driver: CHTVType
sisfb: n/a
top
Parameter: string
Chipsets: 315, 330 series with Chrontel 7019/7020 TV Encoder
Description: This option is only for embedded systems featuring a Chrontel 7019 (or 7020). If the machine has either a SCART (for European TVs) or 480i HDTV (High Definition Television) connector, the driver is - for hardware design reasons - not able to distinguish between these two. Use this option to select either "SCART" or "HDTV" according to your hardware configuration.
Synopsis/Example:
X driver: Option "CHTVType" "SCART"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CHTVOverscan
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series with Chrontel TV Encoder
Description: This option is for systems with a Chrontel TV encoder only. The driver auto-detects the BIOS setting for TV over/underscan. If your BIOS lacks such an option, use this one to choose whether you want overscan or underscan. Please note: For some reasons, Chrontel did not bother to implement a real full-screen TV mode for PAL. So, although the name "overscan" should indicate a TV image without black bars around, such bars still exist even in overscan mode. They are, however, smaller than in underscan mode. NTSC overscan is really full-screen. Valid values are yes (overscan) or no (for underscan).
Synopsis/Example:
X driver: Option "CHTVOverscan" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CHTVSuperOverscan
sisfb: n/a
top
Parameter: boolean
Chipsets: 300 series with Chrontel 700x TV Encoder in PAL mode
Description: This option is for systems with a Chrontel 700x TV encoder and for PAL mode only. As I said above, the Chrontel TV encoders do not feature a real full screen mode in PAL. The newly implemented super overscan is the closest I could achieve: Using this option will result in a screen actually a bit larger than your TV. For normal work, this isn't ideal, of course. For video watching, it will do. This option overrules the CHTVOverScan option and it is only effective in PAL and only in modes 640x480 and 800x600. Valid values are yes (super overscan) or no (default; uses normal overscan or underscan depending on the BIOS setting and the CHTVOverscan option).
This option is for technical reasons ignored if the color depth is 8.
Synopsis/Example:
X driver: Option "CHTVSuperOverscan" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CHTVLumaBandwidthCVBS
CHTVLumaBandwidthSVIDEO
CHTVLumaFlickerFilter
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with Chrontel TV Encoder
Description: These options allow fine-tuning the luma filters of the Chrontel chip. However, they have little effect. The CVBS and SVIDEO variants only apply if your machine has a respective connector type. All these options allow values from 0 to 15 (although their internal resolution is not necessarily 16 steps).
The Luma flicker filter can be changed during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "CHTVLumaBandwidthCVBS" "7"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CHTVChromaBandwidth
CHTVChromaFlickerFilter
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with Chrontel TV Encoder
Description: These options allow fine-tuning the chroma filters of the Chrontel chip. Like their Luma couterparts, they have little effect. These options allow values from 0 to 15 (altough their real resolution isn't necessarily 16 steps).
The Chroma flicker filter can be changed during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "CHTVChromaBandwidth" "7"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CHTVTextEnhance
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with Chrontel TV Encoder
Description: This options allows setting up the Chronel's text enhancement feature. Setting this to higher values increases readability of text. Possible values are within the range between 0 and 15.
Text enhancement can be changed during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "CHTVTextEnhance" "15"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CHTVContrast
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with Chrontel TV Encoder
Description: This options allows selecting a contrast gain factor. Setting this to higher values increases the contrast. Possible values are within the range between 0 and 15.
The contrast can be changed during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "CHTVContrast" "15"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: CHTVCVBSColor
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series with Chrontel TV Encoder with CVBS connector
Description: This options allows disabling color in CVBS mode. According to the Chrontel specs, this avoids distubances by the color signal if a greyscale color palette is used. Thus, this is mainly useful for text processing where color isn't needed. Possible values are "on" (use color = default) or "off" (disable color).
Color for CVBS output can be enabled and disabled during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "CHTVCVBSColor" "off"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SISTVEdgeEnhance
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with SiS 301
Description: This options allows setting up the SiS 301 edge enhancement engine. This is said to increase TV output quality. Possible values are within the range between 0 and 15, but these values don't mean any kind of degree, ie this setting selects different modes for the edge enhancement engine. Please note that this option is only for the SiS 301, not its successors 30xB and later.
Edge enhancement can be changed during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "SISTVEdgeEnhance" "7"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SISTVAntiFlicker
sisfb: n/a
top
Parameter: string
Chipsets: 300, 315, 330 series with SiS 30x/30xB/30xC/30xLV
Description: This options allows setting up the anti flicker engine. This is said to increase TV output quality by reducing line flicker. Valid parameters are OFF, LOW, MED, HIGH or ADAPTIVE.
The flicker filter can be changed during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "SISTVAntiFlicker" "ADAPTIVE"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SISTVSaturation
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with SiS 30xB/30xC/30xLV
Description: This options allows tuning the TV color saturation. Possible values are within the range between 0 and 15. This setting is not supported for the SiS301.
The saturation can be changed during server-run-time using the sisctrl utility.
Synopsis/Example:
X driver: Option "SISTVSaturation" "15"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SISTVCFilter
SISTVYFilter
sisfb: n/a
top
Parameter: see below
Chipsets: 300, 315, 330 series with SiS 30x/30xB/30xC/30xLV
Description: These options allow configuring the TV filters of the SiS video bridges. The SISTVCFilter option can be set to either on or off to enable/disable the C (Chroma) filter.
The SISTVCFilter takes a numerical parameter from 0 thru 8. 0 disables the Y (Luma) filter, 1 sets it to its default, 2-8 select one of 7 possible filter configurations. The Y filter helps to reduce color cross-overs.
Both filters are especially useful if you use a composite (CVBS) connection to the TV; for S-Video connections these filters just blur the image.
Both filters can be enabled/disabled/changed during server-run-time using the sisctrl utility. Check the "Current"-tab in sisctrl to find out about the options to be set in your XF86Config-4 file in order to preserve the current state.
Synopsis/Example:
X driver: Option "SISTVCFilter" "off"
X Option "SISTVYFilter" "1"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SISTVXScale
SISTVYScale
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with SiS 30x/30xB/30xC/30xLV
Description: These options allow scaling ("zooming") of the TV image on SiS video bridges. Both accept numerical parameters, the range is -16 thru 16 for SISTVXScale (horizontal scaling) and -4 thru 3 for SISTVYScale (vertical scaling). Negative values shrink the image, positive enlarge it. 0 is the default for both options.
Vertical scaling is only supported for some display modes. These are 640x480 and 800x600, on the 315 and 330 series also 720x480, 720x576 and 768x576.
The scaler configuration can be changed during server-run-time using the sisctrl utility. Check the "Current"-tab in sisctrl to find out about the options to be set in your XF86Config-4 file in order to preserve the current state.
Synopsis/Example:
X driver: Option "SISTVXScale" "4"
X Option "SISTVYScale" "1"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SISTVColorCalibCoarse
SISTVColorCalibFine
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series with SiS 30x/30xB/30xC/30xLV
Description: These options are for TV color calibration on SiS video bridges by tuning the color subcarrier phase/frequency. Both accept numerical parameters, the range is -120 thru 120 for SISTVColorCalibCoarse and -128 thru 127 for SISTVColorCalibFine. 0 is the default for both options.
Use these options if you have color problems on your TV, such as the image showing reversed colors or lacking color at all. Color calibration might be neccessary due to slightly off-standard oscillator frequencies of your very machine.
To correct such a color related problem, start by finding out the coarse phase/frequency area by settings different values for the SISTVColorCalibCoarse option. Fine-tuning can be done later by adjusting SISTVColorCalibFine.
Color calibration can be performed during server-run-time using the sisctrl utility. Check the "Current"-tab in sisctrl to find out about the options to be set in your XF86Config-4 file in order to preserve the current state.
Note: Color calibration works presumably only for the current display mode. Different modes might require different color calibration values.
Synopsis/Example:
X driver: Option "SISTVColorCalibCoarse" "3"
X Option "SISTVColorCalibFine" "-118"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SenseYPbPr
sisfb: n/a
top
Parameter: string
Chipsets: 315, 330 series with SiS 301C, 30xLV
Description: This option enables or disables sensing (=detection of) a YPbPr HDTV.
If the driver wrongly detects a YPbPr-connected TV (such as in cases where your machine doesn't even have a YPbPr connector, or it actually has, but there is no TV attached) set this option to off. This will also be required if you have two TV sets connected, to S-video and composite (CVBS) at the same time.
By default, sensing of a YPbPr connection is enabled (on machines supporting it).
Synopsis/Example:
X driver: Option "SenseYPbPr" "off"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: YPbPrAspectRatio
sisfb: n/a
top
Parameter: string
Chipsets: 315, 330 series with SiS 30xC
Description: This option selects the aspect ratio for YPbPr (HDTV) output. Valid parameters are "4:3", "4:3LB" and "16:9". "LB" means letterbox.
This feature is only supported on some systems with a 301C video bridge and entirely untested.
Synopsis/Example:
X driver: Option "YPbPrAspectRatio" "16:9"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: TVBlueWorkAround
sisfb: n/a
top
Parameter: boolean
Chipsets: 315 series with SiS 301B-DH
Description: 315 series based machines with a 301B-DH video bridge come in two flavors, ie in two ways how the video bridge is connected to the graphics chip. The driver can't detect this because SiS was not smart enough to mark this anywhere in the BIOS. You will need this option only if TV output is somewhat "blue" or shows otherwise strange colors. It tells the driver which "flavor" the hardware is.
Note that this option, altough it takes a boolean value, has two positions apart from being disabled. To disable this work-around, do not set this option at all. true and false enable the work-around in two different ways. You will need to try out which setting is correct for you.
Synopsis/Example:
X driver: Option "TVBlueWorkAround" "true"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SIS6326TVAntiFlicker
sisfb: n/a
top
Parameter: string
Chipsets: 6326 with TV output
Description: This options allows tuning the hardware's anti flicker facility. Valid parameters are OFF, LOW, MED, HIGH and ADAPTIVE.
Synopsis/Example:
X driver: Option "SIS6326TVAntiFlicker" "ADAPTIVE"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SIS6326TVEnableYFilter
SIS6326TVYFilterStrong
sisfb: n/a
top
Parameter: boolean
Chipsets: 6326 with TV output
Description: The first of these options allows enabling/disabling the hardware's Y (luminance) filter; the second option determines if the filter should be strong or weak. Both options are boolean, ie they accept yes or no.
Synopsis/Example:
X driver: Option "SIS6326TVEnableYFilter" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SIS6326TVForcePlug
sisfb: n/a
top
Parameter: string
Chipsets: 6326 with TV output
Description: This option is mainly for folks connecting the 6326 to their TV via some sort of video adaptor. Such adaptors have the disadvantage that they likely disturb the TV detection. This might lead to a TV actually connected via CVBS (Chinch) being detected as connected via SVIDEO and vice versa. Possible parameters to this option are SVIDEO and COMPOSITE.
Synopsis/Example:
X driver: Option "SIS6326TVForcePlug" "COMPOSITE"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: SIS6326FSCAdjust
sisfb: n/a
top
Parameter: integer
Chipsets: 6326 with TV output
Description: This option allows fine-tuning the subcarrier frequency for color transmission of TV output. This option works similar to the color calibration options on newer hardware.
Some cards, for instance the Diamond SpeedStar A70, require such tuning, otherwise TV output will be black & white only. This option takes a positive or negative integer. The required value can only be found out by trial & error; the Diamond card requires setting it to 1024.
Synopsis/Example:
X driver: Option "SIS6326FSCAdjust" "1024"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvOnCRT2
sisfb: n/a
top
Parameter: boolean
Chipsets: SiS315, 650, 740; 76x if only shared framebuffer memory is available
Description: First, unless you have already done this, please read my basic information on hardware video acceleration here.
As mentioned there, the SiS 315, 650 and 740 only support one overlay; the 76x, if only shared memory is available, supports one or two overlays depending on memory bandwidth limits.
This overlay can be displayed on either CRT1 or CRT2. But how does the driver select this?
* If the driver detects either only CRT1 or only CRT2, the overlay will automatically used on that available output device.
* In MergedFB mode, the driver will switch to the respective output device automatically, depending on the screen location of the video to be displayed.
* In all other cases: If both CRT1 and CRT2 are detected and used (be it in mirror mode, be it in Dual Head mode), this option selects whether the overlay should be displayed on CRT1 (if the option is set to "no" or left out) or CRT2 (if set to "yes").
Note: This option only selects the default head. Since 2003/02/21, the X driver provides a XV property named XV_SWITCHCRT which allows selecting on which CRT the overlay should be displayed at run-time. Since not many Xv-aware applications are smart enough to detect this property, I also wrote a tool named sisswitchxvcrt. This tool is available for download here and is mostly self-explaining. Furthermore, this setting can be changed during server-run-time using the sisctrl utility.
This option is ignored on chipsets that support two overlays, and on all chipsets of the old series.
Note: This option only affects the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvOnCRT2" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvDefaultContrast
XvDefaultBrightness
XvDefaultHue
XvDefaultSaturation
XvDefaultDisableGfx
XvDefaultDisableGfxLR
sisfb: n/a
top
Parameter: see below
Chipsets: All
Description: The first four of these options allow defining the default settings for the XV properties Contrast, Brightness, Hue and Saturation. Hue and saturation are only available on the 315 and 330 series. I implemented these options because many Xv aware applications are too dumb to offer the user control over them at run time.
These options only accept numerical values, the ranges are: XvDefaultContrast 0 - 7, XvDefaultBrightness -128 - 127, XvDefaultHue -8 - 7, XvDefaultSaturation -7 - 7.
The last two options are mainly meant for slower machines or machines with a slow memory bus. These, along with the Xv properties XV_DISABLE_GRAPHICS and XV_DISABLE_GRAPHICS_LR allow disabling the graphics display during overlay usage. The XvDefaultDisableGfx option (like the XV_DISABLE_GRAPHICS Xv property) disables the entire graphics display except for the overlay (available for all chipsets except M650, 651, 330, 661FX, M661FX/MX, 741, 760 and for CRT1 only), while XvDefaultDisableGfxLR (like the Xv property XV_DISABLE_GRAPHICS_LR) only disables the graphics to the left and right of the overlay (available on 300, 315, 330 series only; not on old series). This speeds up Xv operations by ca. 5% (in case of LR) resp. 20% (if the entire display is off). Both options take a boolean parameter. Warning: Handle these with care. You will be completely blindfolded if the display is off! The only thing visible will be the hardware cursor and the overlay!
Note: If you are running dual-head mode, these option should be placed in the Device section for CRT1 if they are meant for CRT1.
Note: All these only affect the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvDefaultContrast" "4"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvGamma
sisfb: n/a
top
Parameter: boolean, or one or three floating point numbers
Chipsets: 315, 330 series only
Description: This option enables (or disables) a separate gamma correction facility for Xv (X video). This is only supported on 315 and 330 series, and only for CRT1.
By default, Xv gamma correction is disabled. This means that Xv will obey the normal gamma correction for CRT1. If Xv gamma correction is enabled, it will be separated from the normal gamma correction for CRT1.
This option takes either a boolean, or one or three real (floating point) numbers in the range from 0.1 to 10.0.
If a negative boolean (such as off) is given, Xv gamma correction will be disabled (default).
If a positive boolean (such as on) is given, Xv gamma correction will be enabled with the default of 1.0 for red, green and blue.
If one floating point number is given, this number will be used for red, green and blue. Lastly, if three floating point numbers are given, these will be read in the order red-green-blue.
Note: If you are running dual-head mode, this option should be placed in the Device section for CRT1.
Note: This option only affects the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvGamma" "1.0 1.2 0.8"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: NoYV12
sisfb: n/a
top
Parameter: boolean
Chipsets: SiS5597/5598, 6326, 530, 620
Description: The hardware has obviously problems with YV12 video overlays larger than 384x288 (meaning the video's source size, not the overlay size which might be the result of scaling). Set this option to "yes" to disable YV12 support, in order to force applications to use YUY2 or XShm for YV12 material.
Synopsis/Example:
X driver: Option "NoYV12" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvUseChromaKey
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: This option enables the so called chroma-keying. Chroma-keying means that the Xv overlay will be transparent on places where the video source is inside or outside a certain color range. This enables programmers to create blue-box-like effects, where you put a picture in the background and play a video above it - the video will be transparent at places where its color is inside/outside the color range defined by the ChromaMin and ChromaMax options.
The corresponding Xv property is called XV_USE_CHROMAKEY.
In order to avoid that the colorkey is painted over your background image, you should set the DisableColorKey option, see below.
Note: If you are running dual-head mode, this option should be placed in the Device section for CRT1 if it is meant for CRT1.
Note: This option only affects the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvUseChromaKey" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvInsideChromaKey
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: This option selects whether the video should be transparent if the video pixel color is inside (yes) or outside (no, default) of the chroma key range defined by XvChromaMin and XvChromaMax.
The corresponding Xv property is called XV_INSIDE_CHROMAKEY.
Note: If you are running dual-head mode, this option should be placed in the Device section for CRT1 if it is meant for CRT1.
Note: This option only affects the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvInsideChromaKey" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvDisableColorKey
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: This option is used in connection with chroma-keying. Setting it to yes will force the driver to 1) not paint the colorkey, and 2) to ignore "fill"-accelerator commands using the current colorkey as filling color. (The latter is for programs like Xine which paint the colorkey themselves.)
If this option is not set (which is the default), the SiS driver will paint the color key (and hence overwrite your background image used with chromakeying)
The corresponding Xv property is called XV_DISABLE_COLORKEY.
Note: If you are running dual-head mode, this option should be placed in the Device section for CRT1 if it is meant for CRT1.
Note: This option only affects the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvDisableColorKey" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvYUVChromaKey
sisfb: n/a
top
Parameter: boolean
Chipsets: 300 series only
Description: This option selects the chroma key format. yes means YUV, no (which is the default) means RGB.
On 315/330 series, the chromakey format always matches the video source format (ie. YUV if playing YUV material, RGB if playing RGB material).
The corresponding Xv property is called XV_YUV_CHROMAKEY.
Note: If you are running dual-head mode, this option should be placed in the Device section for CRT1 if it is meant for CRT1.
Note: This option only affects the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvYUVChromaKey" "yes"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvChromaMin, XvChromaMax
sisfb: n/a
top
Parameter: integer
Chipsets: 300, 315, 330 series
Description: These options select the color range for chromakeying. If the video color is inside/outside the range of ChromaMin and ChromaMax, it will be transparent and the background will be visible instead.
The format is either YUV or RGB (on the 300 series depending on the XvYUVChromaKey option, default is RGB; on the 315/330 series depending on the current video format). How the given value is interpreted depends on the format of the key. On 315 series, for instance, playing RGB 15bit material, the chroma key is interpreted 5 bit green, 5 bit red, 5 bit blue (in reversed order), and the whole value shifted by 8 bits. For example: 0xffe000 means purple (0xffe0 = 0xf800 | 0x07c0; 0xf8 = 11111b = blue, 0x7c = 11111b = red). The driver does not process the given values in any way, it just writes them to the hardware registers. You will need to play around with the values to achieve the desired result.
The corresponding Xv properties are called XV_CHROMAMIN and XV_CHROMAMAX.
Note: If you are running dual-head mode, these options should be placed in the Device section for CRT1 if they are meant for CRT1.
Note: These options only affect the overlay adaptor, not the video blitter adaptor.
Synopsis/Example:
X driver: Option "XvChromaMin" "0x123456"
Option "XvChromaMax" "0xabcdef"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: XvDefaultAdaptor
sisfb: n/a
top
Parameter: string
Chipsets: M650, 651, (M)661, (M)741, (M)760, 330
Description: This option selects whether the overlay or the blitter adaptor should be adaptor number 0, hence the default adaptor.
Please see here for more information about the difference between overlay and blitter.
Note: If you are running dual-head mode, this option must be in the Device section for CRT2; it effects both CRT1 and CRT2.
Synopsis/Example:
X driver: Option "XvDefaultAdaptor" "Blitter"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: UseColorHWCursor
sisfb: n/a
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: As of XFree 4.3, the X server supports multicolor alpha blended (ARGB) cursor images. This option allows enabling ("yes") or disabling ("no") support for color hardware cursors. (Note: XFree 4.3 will use the software cursor if support for multicolor hardware cursors is disabled. In other words: X.org/XFree86 will still display colored cursors if this option is set to "no"; however, no hardware acceleration for the cursor drawing is available in this case.)
The 300 series do not support alpha blending in hardware cursor images. Therefore, I implemented an emulation for this which works as follows: Pixels with a transparency level higher than a certain (selectable) threshold are being used to create a "ghost" pixel; such pixels will be displayed transparently, but they will in some sort "distort" the background pixel. Pixels with a lower transparency level than the threshold will be displayed as solid. Please see the following two options on how to control this behavior.
The RedGlass and WhiteGlass cursor themes that come with XFree 4.3 do not really look good using this emulation mode. However, it is possible to create cursor themes without alpha blending or perhaps even taking advantage of the emulation restrictions ("ghosting" instead of alpha blending). It's up to you. If you have created a cursor theme for the 300 series, I'd be glad to publish it on this site.
All this information on alpha blending emulation does not apply to the 315 or 330 series. These chipsets support alpha blended cursor images as XFree 4.3 supposes.
The old series don't support color cursors at all.
By default, color HW cursor support is disabled on the 300 series and enabled on the 315 and 330 series.
Synopsis/Example:
X driver: Option "UseColorHWCursor" "no"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: ColorHWCursorBlending
sisfb: n/a
top
Parameter: boolean
Chipsets: 300 series only
Description: As described above, the 300 series do not support alpha blending in cursor images. The X driver does an emulation of alpha blending on these chipsets. To disable this emulation, set this option to "off". All pixels which are not completely transparent will be shown as solid in this case.
Synopsis/Example:
X driver: Option "ColorHWCursorBlending" "off"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: ColorHWCursorBlendThreshold
sisfb: n/a
top
Parameter: integer
Chipsets: 300 series only
Description: This option, which takes an integer in the range from 0 to 255 as parameter, allows selecting a level of transparency which works as a threshold between pixels that are to be displayed as solid and such to be used to "distort" the background. There is no general rule for how to select the correct level, it depends on the image data. The default is 55 which is - in my humble opinion - the best possible threshold for the RedGlass cursor theme (It still doesn't look good anyway).
Synopsis/Example:
X driver: Option "ColorHWCursorBlendThreshold" "70"
sisfb (module): n/a
sisfb (kernel): n/a
* * *
Name:
X driver: n/a
sisfb: mode
top
Parameter: see below
Chipsets: 300, 315, 330 series
Description: The mode parameter specifies the display mode sisfb should use. This can be specified in the following formats: XxYxD, XxY-D and XxY-D@R where X is the desired X resolution, Y is the Y resolution, D is the framebuffer depth (8, 16 or 32) and R is the vertical refresh rate in Hz. For instance: 1024x768x8, 800x600-32@75, etc.
The special case mode=none is mainly for folks who dislike graphical consoles (like me): You may start sisfb with mode=none (or mode:none if compiled into the kernel). This makes sisfb skip the framebuffer initialisation, keeps the console screen in text mode but - and that's the point - sisfb will still do the memory management for DRI/DRM. Thus, insmod or modprobe sisfb with mode=none and you will be able to use DRI under X.
If compiled as a module, you may likewise omit the mode parameter if you want to use sisfb without switching to a graphical console. sisfb by default chooses mode=none if started as a module, and 800x600x8 if compiled into the kernel.
There is a downside to this: Using sisfb with no mode keeps the X driver from detecting it. Thus, the automatic MaxXFBMem detection does not work and you need to set the heap start manually (by the option MaxXFBmem). Please see above.
The none keyword is no longer supported in kernel 2.6. Please see above.
Synopsis/Example:
X driver: n/a
sisfb (module): modprobe sisfb mode=1024x768x16
sisfb (kernel): video=sisfb:mode:none
* * *
Name:
X driver: n/a
sisfb: vesa
top
Parameter: integer
Chipsets: 300, 315, 330 series
Description: Sisfb's vesa parameter lets you choose the desired mode by using VESA mode numbers (decimal or hexadecimal). If you don't know what that is, never mind. It's just an alternative way to select the mode.
Synopsis/Example:
X driver: n/a
sisfb (module): modprobe sisfb vesa=0x117
sisfb (kernel): video=sisfb:vesa:0x117
* * *
Name:
X driver: n/a
sisfb: rate
top
Parameter: integer
Chipsets: 300, 315, 330 series
Description: The rate allows choosing the vertical refresh rate of the desired mode in Hz. It is mainly used in connection with the alternative mode selection without a rate in the argument (see above, for instance 800x600x8).
Synopsis/Example:
X driver: n/a
sisfb (module): modprobe sisfb mode=1024x768x16 rate=60
sisfb (kernel): video=sisfb:mode:1024x768x16,rate:60
* * *
Name:
X driver: n/a
sisfb: noaccel
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: Sisfb does 2D acceleration for scrolling, etc. by default. If you for some reason want to disable this feature, use this option.
Synopsis/Example:
X driver: n/a
sisfb (module): modprobe sisfb noaccel=1 (1=disable, 0=enable 2D acceleration)
sisfb (kernel): video=sisfb:noaccel (no parameter! If omitted, default is 2D accel on)
* * *
Name:
X driver: n/a
sisfb: noypan
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: SiSfb knows to ways to scroll text: By redrawing the screen, or by panning. Panning works as follows: A virtual screen, larger than the visible area, is initialized and scrolling is done by letting the hardware point to a different part of that screen. If even the virtual screen area is full, it starts at the beginning. Y-panning is a lot faster than redrawing. If you for some reason want to disable y-panning, use this option.
Synopsis/Example:
X driver: n/a
sisfb (module): modprobe sisfb noypan=1 (1=disable, 0=enable y-panning)
sisfb (kernel): video=sisfb:noypan (no parameter! If omitted, default is y-panning on)
* * *
Name:
X driver: n/a
sisfb: nomax
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: If y-panning is enabled, sisfb, by default, uses a virtual screen as large as the video memory allows. This is called auto-maximizing. If you want to disable this feature, set this option. However, since y-panning relys on a large virtual screen for speed improvement, disabling auto-maximizing is not recommended.
Synopsis/Example:
X driver: n/a
sisfb (module): modprobe sisfb nomax=1 (1=disable, 0=enable auto-maximize)
sisfb (kernel): video=sisfb:nomax (no parameter! If omitted, auto-maximize is on)
沒有留言:
張貼留言