www.winischhofer.net
HTML 4.01 compliant CSS compliant
Friday, 06-Feb-2004 19:35:41 CET
Home Inhalt Hem Database e-mail

Disclaimer: The information and software available on this site is provided AS IS and I herewith disclaim all warranties with regard to this information and software, including all implied warranties of merchantability and fitness. In no event shall I be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use of this information and/or the use or performance of this software.

Since I do not see any reason to protect ways of thinking, I don't care about software patents. In case any software available on this site infringes any of these so called software patents, this infringement is entirely unintentional and a pure coincident.

no software patents

[Driver options] * [FAQ] * [Changelog] * [Download] * [Installation]

SiS グラフィックチップセットと XFree86/Linux

目次
0. ページ概略

SiSグラフィックカード用のXFree86ドライバが欲しいですか? ダウンロードセクションからダウンロードできます。 インストール方法解説に書いてあるように インストールして、ただ ドライバ "sis" を、 /etc/X11/XF86Config か /etc/X11/XF86Config-4 の Device セクションの 中におけばいいだけです。

XFree86ドライバには、sisctrlという 附属のディスプレイ管理ツールがあって、 それを使えばXサーバをリスタートする必要なく、ドライバを設定できます。 このツールもダウンロードセクションにあります。

それに加えて、いくつかのSiSグラフィックカード用の Linuxカーネルフレームバッファドライバもここで手に入ります。 このドライバは、インストールするためにカーネルの設定とコンパイルに関し ある程度の知識が必要なので、より熟練したユーザ向けと言えます。

このウェブサイトから入手できるどのドライバのインストールも、 いわゆる「サードパーティ」ソフトウェアのインストールではありません。 私は実のところ、XFree86のSiSドライバと LinuxカーネルのSiSフレームバッファドライバの 正式な著者であり保守担当であるからです。

もちろん、このページは巨大です。 しかしもし嫌なら、全部読む必要はありません。そう、少なくとも最初は。 XFree86ドライバに関しては、基本的な動作のためには、 何も特別な設定やオプションは必要ありません。 ただ必要なのは、(この概略パラグラフで最初に述べたように) XFree86サーバに、"sis"ドライバを使うように教える事です。 初心者ユーザには、次の段階としてsisctrlで遊ぶ事を勧めます。 このツールはドライバの機能と、 XF86Config(-4)の設定を変更するためにどのオプションを設定したら良いかを 教えてくれるでしょう。

I. はじめに
1. このページの目的?

可愛いlinuxロゴをlinuxドライバのページに掲げていても, SiSは残念ながら Linuxをサポートしないその手の企業の一つです。 彼らは製品について何も(僅かの例外はありますが)技術資料を公開しておらず (これからもしないでしょう)、マイクロソフトのDOS拡張環境 (巷ではウィンドウズとか呼ぶそうな)のドライバしか書きません。 彼らはかつてlinuxドライバをリリースしたことはありますし、 最近も(バイナリの)SiS650ドライバをリリースしましたが、 それらはとんでもなくバグだらけで、最低限の品質しか持たないものです。 一言で言えば、彼らのXFree86ドライバは使い物になりません。 もしノートPCを使っているのなら、 彼らのドライバは、試してみる価値さえないでしょう。

私はいかなるNDAにもサインした事がなかったとはいえ、 何ヶ月かそれらをデバッグし、その後関連する情報を得ようとしましたが、 もたらされた情報は不完全なだけでなく、 時として単純な間違いでさえありました。 SiS従業員の中にはlinuxに取り組もうとする人もいるのですが、 企業の公的な姿勢としては、「残念だがlinuxは禁止」と言っているようです。 この方針は、グラフィック部門が、他の部署の従業員に対しても 技術情報を機密扱いするほど、徹底されています。

2003年6月、SiSのグラフィック部門は、 Tridentのグラフィック部門に統合され、XGIという名前の新しい会社に なりました。このことがSiSのグラフィックチップの未来にとって どういう意味を持つのか、まだわかりません。

始める前に、XFree86とlinuxカーネルを適正に設定するために、 知っておかなければならないいくつかの技術的な基礎知識があります。 私は魔法のように自動的に自身を設定する「ウィザード」を提供できないことを 非常に残念に思っています。その代わり、この説明を一種のインストールガイドと 思って、これで、繋いで祈る(Plug & Pray)インストールをして下さい。 問題を解決するのがより簡単になるようにお助けできると思います。 でも心配しないで下さい:少なくともXFree86ドライバは、 ほとんど完全に自分で自動設定できる機能を持っています。

2. サポートされる SiS グラフィックチップ と ビデオブリッジ

現在 SiS VGA コントローラには次の4タイプがあります:

  • old シリーズ (5597/5598, 6326/AGP/DVD, 530, 620),
  • 300 シリーズ (300/305, 540, 630/S/ST, 730/S),
  • 315 シリーズ (315/E/H/PRO, 550, 650, 651, M650, 740, 661FX, M661FX, M661MX, 741, M741),
  • 330 シリーズ (330 "Xabre", 760, M760).

(ここに書いたもの以上に古いチップセットはサポートされていません)

これらのグループ内のコントローラは(多少とも)互いに互換性があります。 番号 > 3xx のチップは(6326を除き)、 PCI/AGP/ISA ブリッジとメモリーコントローラ、ネットワークアダプタと その他機能もチップ内に埋め込まれた統合チップセットです。 550はある意味特殊で、これは完全なワンチップコンピュータで、x86互換CPUさえ 含んでいますが、。3D描画エンジンはありません。 550はSiSの非常に珍しいlinuxサポート済み製品ですが、 不思議なことにそのグラフィック機能はサポートに含まれません...

SiS6325がないことに注意して下さい。 0x6325は SiS650, 651, M650 及び 740のグラフィック制御部分の PCI IDです。 この番号はデバイスを一意に識別しません。 それで「SiS6325」というグラフィックチップセットはなく、 代わりに、SiS650、651などと呼ばれているのです。 同じ事が0x6330にもいえます - それは(M)661、(M)741か(M)760です。 (以後の説明ではこれらを「661シリーズ」と呼ぶ事があります)

300, 315 と 330シリーズは、同時に2つの異なるディスプレイデバイスに 出力する2つのCRTコントローラを持っています。 第1のCRTコントローラは主に古典的なVGA出力を担当し、 第2のCRTコントローラ(CRT2)は、ほとんどの場合、 「ビデオブリッジ」と呼ばれるもの、または LCD(液晶)/プラズマ/DVI-D (ディジタル) 出力、 TV出力 または 第2VGA/DVI-A (アナログ) 出力 を制御する、ビデオブリッジ類似の装置へ結線されています。 TVに関しては、ブリッジはS-Video経由、コンポジット出力(CVBS)経由、 またはYPhPr(コンポーネント)経由で、出力する事ができます。

グラフィックコントローラ と ビデオブリッジ の 関係は下図を見てください:

videobridge

1. SiS ビデオブリッジ

SiSのビデオブリッジにはいくつかのタイプがあります。 現在知られている(私が知っていてドライバがサポートしている)ものは

  • 301 (旧式、時代遅れ。LCDをTMDS経由で、解像度800x600までのTV、 ハイビジョン1080i TV、第2VGAをサポート)、
  • 301B (LCDをTMDS経由で、解像度1024x768までのTV、 ハイビジョン1080i TV、第2VGAをサポート)、
  • 301B-DH (解像度1024x768までのTV、ハイビジョン1080i TV、第2VGAをサポート)、
  • 301C (LCDをTMDS経由で、解像度1024x768までのTV、 YPbPr HDTV、第2VGAをサポート)、
  • 302B (2チャンネルのLCDをTMDS経由で、解像度1024x768までのTV、 ハイビジョン1080i TV、第2VGAをサポート)、
  • 301LV (LCDをLVDS経由で、解像度1024x768までのTV、YPbPr HDTVをサポート)、
  • 302LV (2チャンネルのLCDをLVDS経由で、解像度1024x768までのTV、 YPbPr HDTVをサポート)、
  • 302ELV (2チャンネルのLCDをLVDS経由でサポート)

ディジタル出力に関しては、301、301B、301C と 302B は、 TMDS ("Panel Link" = DVI-D)のLCDとプラズマパネルしか制御できません。 それぞれの、LVで終る名前を持つものは、LVDSフラットパネルだけを制御します。 301B-DH は 301B の機能縮小版で、LCDパネルの制御機能を持っていません。 301B-DH を搭載したラップトップは、LCD出力を、 別個の独立したLVDSトランスミッターを使って行なっています (ECS デスクノート 90x シリーズのような場合です)。

302B/LV/ELV ブリッジは、2チャンネルの出力が可能ですが、 301/B/C/LV ブリッジは1チャンネルだけの出力をするデバイスです。 この違いは、マシンがDVIコネクタを持つ時には重要になります。 1チャンネルなら、ドットクロックが最大108Mhzであることを意味します (301Cでは162Mhzです)。 2チャンネルのデバイスでは、より高いドットクロックが必要になります。

TV出力に関しては、全てのSiSブリッジはS-Videoとコンポジット (CVBS)出力をサポートします。 301/301B/302Bビデオブリッジは、1080iハイビジョン出力をサポートします。 301C/301LV/302LVは、YPbPr 480iをサポートし、 同様に480p と 720p (別名 525i, 525p, 750pとも呼ばれます)は、 YPbPr 1080iをサポートしますが、ハイビジョンはサポートしません。 (1080iハイビジョンは日本の1080i標準規格で、 YPbPr 1080iに非常に似ています。 「YPbPr」という名前は、Y、Pb、Prデータの別々に入出力するという意味で、 通常は3針コネクタです。YPhPrをS-Videoやコンポジット(CVBS)端子から 出力する事はできません。もしHDTVをDVI経由で接続しようとしている場合、 ここに書かれている事は参考になりません。 YPhPrとは、YPbPr 直接出力 を意味しています。 上記のディジタル出力 の記述を参照して下さい)

2番目のアナログ出力(VGA2 = DVI-A。301、301B、301C と 302Bのみ) に関しては、ビデオブリッジは、それぞれ異なったドットクロックの最大値を サポートします。301 は最大135Mhz (60Hzで最大解像度 1280x1024)まで、 301B と 302B は最大162Mhz (60Hzで最大解像度 1600x1200)までです。 301B-DH は、ドットクロック最大100Mhz (85Hzで最大解像度 1024x768)まで に限定されています。 301C は最大202Mhz (75Hzで最大解像度 1600x1200)までサポートします。

2. CRT2出力に使われるその他のデバイス

マシンにSiSビデオブリッジがない場合、 TV出力が個別のTVエンコーダによって行なわれている間、 LCD出力は、 (おそらくはTrumpion Zurac LVDSスケーラなどを用いて)、 LVDSトランスミッターを通して行なわれます。 最も普通に使われるTVエンコーダは、 a300シリーズと共に使われる場合はChrontel 7005、 315/330シリーズと共に使われる場合はChrontel 7019です。

3. 共通する情報

以後の記述では、CRT1は(第一の)VGAを意味します、 CRT2は、LCD(またはDVI-Dに接続されているなんらかのデバイス)、 TVまたは第二VGA(またはDVI-Aに接続されているなんらかのデバイス)を、 意味します。 ラップトップを含むほとんどのマシンにあるVGAプラグは、 第一VGA出力、すなわちCRT1です。 CRTと言う語は cathode ray tube の頭文字で、 普通は ブラウン管の VGA monitorを意味しますが、 CRT2 と言う表現は SiS-語 では、"LCDかTVか第2(外部)VGA"という意味になります。 また、ビデオブリッジと言う語は、 SiS のビデオブリッジ、LVDSトランスミッター、TVエンコーダを全て含みます。

一般的に、技術上の理由から、同時には一つのCRT2デバイスだけしか 有効になりません。そのため、ノートブックPCをTVにつないで、 TV出力を選択したら、ノートブックのLCDパネルはオフになります。 しかし、ある種のマシンでは、LCDとTVを同時に制御できます。 まず、これは、SiS650/M650/651/661/741/760 VGAコントローラと、 301C/30xLV/ELV ビデオブリッジの組合せの場合に当てはまります。 こういったマシンでは、XFree86ドライバは、 LCDとTV出力を同時にサポートします (より詳細な情報は、ここを読んで下さい)。 また、SiS650/M650/651とChrontel 7019の組合せでも、 理論的にはこれが可能です。 ただし、私のドライバでは、この組合せでは、 LCDとTVの同時出力はサポートしていません

重要事項: このページで使われる短縮語「VESA」は、カーネルのVESAフレームバッファドライバを 意味しません ここで議論しているドライバを使いたい時は、 カーネルのVESAフレームバッファドライバは無効にして下さい。 (つまり、カーネルコンフィギュレーションで、"VESA VGA graphics console"を 無効にし、"vga=???"記述をブートマネージャ設定ファイルから取り去ることです)

3. どのチップセットがどのドライバでサポートされるか?

以後の記述では、「Xドライバ」という語は、SiS XFree86ドライバを指します。 sisfbは、Linuxカーネルの、SiSグラフィックコントローラの フレームバッファドライバです。

概略ステータスは、以下の表を見てください :

XFree86 driver sisfb
CRT1 CRT2
LCD TV VGA2
LVDS 301 30xB/C 30xB-DH
(via LVDS)
30xLV DSTN/FSTN Chrontel 301 30xB/C 30xLV 301, 30xB
old series OK NO NO NO NO NO NO OK
(6326 only)
NO NO
300 series OK OK OK OK OK OK NO OK OK OK ? OK Like X driver
315 series
except 550
OK OK OK OK NO OK NO OK OK OK OK OK Like X driver
550 OK ? ? ? ? ? ? ? ? ? ? ? Like X driver
330 OK NO ? ? ? ? NO NO ? OK ? ? Like X driver
661/741/760 OK NO ? ? ? ? NO NO ? ? ? ? Like X driver

661FX、M661FX、M661MX、741、M741、760 および M760のサポートと、 新しいビデオブリッジ 301C/302ELV は、既にコードに含まれますが、 まだしっかりとテストされていない事にご注意下さい。

1080iハイビジョンHDTVは、SiS 301、301B、302B ビデオブリッジで サポート済みですが、現在まだテストが済んでいません。 YPbPr (HD)TV 出力(480i、480p、720p、1080i)は、 315/330シリーズで、SiS 30xLV および 301C ビデオブリッジとの組合せのみ サポートされますが、これもまだテストが済んでいません。

II. 詳細情報
1. SiSグラフィックチップ用のLinuxフレームバッファドライバ (sisfb)

The Linux kernel framebuffer driver - hereinafter called sisfb - only supports the 300, 315 and 330 series.

どうしてフレームバッファドライバが必要なの?

ううん: Linus Torvaldsはフレームバッファを採用することが お嫌い みたいだけど、sisfbは楽チン。 高解像度のコンソール画面が欲しい時にはお役に立ちます。

300シリーズでは、sisfbはDRIとの接続で重要な役目を果たします。 sisfbはDRIがテクスチャデータで使うメモリーヒープを管理するのです。 このメモリー管理はDRIを使うためには必須ですが、 次のような理由でXドライバーには実装されません。 DRIはXFree86だけで使うわけではないのです。 DRM/DRIインフラストラクチャの非常に多くの部分が、 カーネルの一部分であり、だからメモリー管理もカーネルに含まれるべきなのです。 (より詳しくは私のDRI ページを 参照してください)

もしフレームバッファドライバの採用についてLinusのようにお考えなら、 sisfbはDRIのメモリー管理を提供するのみに留め、コンソールは標準のままに しておくとよいでしょう。 詳しくはオプションの章を参照してください。

よく間違えられるのですが、sisfbとカーネルのVESAフレームバッファドライバは 同時には使えません!

sisfbにはどのようにパラメータが渡されるか?

そうね、場合による:カーネルにスタティックにコンパイルされてる場合、 liloのappend文を使って、 カーネルコマンド行にパラメータを追加します。 より詳細は、liloの(またはGRUBの)説明書を参照して下さい。 sisfbがカーネルモジュールの場合は、 パラメータはmodprobe(またはinsmod)コマンドで渡されます。

カーネルにスタティックにリンクされたsisfbの場合: 次の行をlilo.confに付け加える:

append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"

sisfbがモジュールの場合: sisfbモジュールを、次のようにタイプして起動する:

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

カーネル内にコンパイルされたドライバを使う時に、 間違ったパラメータフォーマットを使う方がいます。 ご注意ください: カーネル内にコンパイルされた時は、 パラメータフォーマットはvideo=sisfb:mode:none、 またはvideo=sisfb:mode:1024x768x16 (または他のお好みのモードを、 上記のいずれかのフォーマットを使って指定するか、または、 vesa キーワードを mode の代りに指定するか)です。 モジュールとしてコンパイルされた場合は、パラメータフォーマットは mode=none または mode=1024x768x16 (または他のお好みのモード)です。 ":"を使う代りに"="を使う事(またはその逆)は重大な違いです! ついでに言うと: もし2つ以上のパラメータを、 カーネル内のsisfbに与える時は、パラメータを';'で区切ります。 例えば: video=sisfb:mode:1024x768x16,mem:12288

ビデオモード選択

サポートされたディスプレーモードについては、 下記を見て下さい。 sisfbはそのリスト中の、組み込みモードだけしかサポートしません。

期待される(デフォルトの)ディスプレーモードは、 パラメータを伴った modeキーワードを使って、 以下のいずれかのフォーマットで指定できます: XxYxDepthXxY-DepthXxY-Depth@RateXxY、 または、単に16進または10進のVESAモード番号を使ってです。 (後の5つの指定方法は、sisfb バージョン 1.6.04 でのみ可能です。) 例えば、1024x768x161024x768-16@751280x1024-16 など。もしDepthが指定されなければ、8ビットがデフォルトとなります。 Rateが指定されなければ、60Hzがデフォルトとなります。

それに加えて、sisfbは、10進または16進のVESAモード番号を伴った キーワード vesa指定を認識します。 例えば: vesa=791vesa=0x117

Sisfb と 2.6 カーネル

2.6とそれ以後のバージョンは、 内部のプログラミングインターフェースに留まらず、 ユーザのハンドリングインターフェースについても、 多くの変更が行なわれています。 最も重要な変更は、フレームバッファドライバ(この場合はsisfb)と コンソールドライバ(fbconと呼ばれる)が、完全に分離されたことに 起因するものです。 フレームバッファドライバは低レベルのハードウェアプログラミングのみを 扱うものとなり、一方コンソール層はそれ以外の扱いを担当します。 この変更の目的は、コンソールコードをその外側に移すことで、 フレームバッファドライバを統一的にし、簡素化することでした。

しかしながら、この開発者たちの試みがうまくいったかどうかの評価は、 まだはっきりとはしていません。

ユーザの扱いの観点から、知っておかねばならない非常に重要な事実は、 (それがモジュールとしてコンパイルされている場合) sisfbを単独で開始したら、それは‥何もしない、と言うことです。 より正確に言うと:目に見える効果がなにもないと言うことです。 ディスプレイモード(それはやはり2.4の時と同様に、例えば mode=XxYxDvesa=xxx などのように指定されますが)は、 con2fbというツールを使って (コンソールドライバfbconが、 カーネルにスタティックにコンパイルされている場合)、 または、fbconドライバをロードして (fbconが、モジュールとしてコンパイルされている場合)、 フレームバッファをコンソールに接続するまでは、 変更されません。 この時点で、sisfbがもはや、mode=noneを 受け付けない - 理由はもはやそれが必要ではないから、 という事実を知ることは興味深いと思います。 もしグラフィカルコンソールが必要なら、 後で、con2fbコマンドで起動することができます。 しかし注意して下さい:sisfbやコンソールドライバが、 カーネルにスタティックにコンパイルされていれば、 コンソールドライバはブート時に自動的に開始されます。 現時点では、これを回避する方法はありません。

音に問題がある?

  • sisfbとfbconがカーネルにスタティックに含まれる時: カーネルはブートでグラフィックモードに入ります。 どのモードも指定されていなければ、 800x600x8がデフォルトとなります。
  • sisfbがモジュールで、fbconがカーネルに含まれる時: modprobeでロードされたsisfbは、 con2fbを使って、 フレームバッファがコンソールに接続されるまで、 ディスプレイモードを変更しない。
  • sisfbとfbconがモジュールの時: modprobeでロードされたsisfbは、 modprobe fbconが実行されるまで、 ディスプレイモードを変更しない。 モードが指定されないと、800x600x8がデフォルトとなる。
  • sisfbがカーネルに含まれ、fbconがモジュールの時: ブートでは、何も目に見える変化はなく、ディスプレイモードは modprobe fbconによって変更される。 現状では、これによって、Linuxペンギンが画面に現れるが、 VTの切替えによってそれが消される。

もう一つの2.4シリーズとの重要な違いは、 fbset(2.4でコンソールの解像度を変更するツール) が、多少なりともその役割を減じていることだ。 「多少なりとも」と表現するのは、コンソール開発者がいまだ、 移行する目標としている、- IMHO - と呼ばれる、 sttyの、全体的に使いにくい代替品を、 どのような物にするか決めていないためだ。 sttyは、現在コンソールの解像度を変更するために 使われているが、期待されるディスプレイモードは、 我々が通常するように、 x解像度、y解像度、depthとリフレッシュレートを指定されず、 その代り、文字数単位での行数カラム数で指定される。 つまり、デフォルトコンソールフォント(8x16)を使っている場合、 stty rows 128 cols 48 によって、1024x768のディスプレイモードが選択される。

2.6でディスプレイモードを変更するために fbsetをコールしても、 コンソール次元(つまりカラム数と行数)は変更されず - ディスプレイ表示が破壊されます。 fbsetは、リフレッシュレートとdepthを 変更する目的でのみ使用するようにして下さい。

2. The XFree86 ドライバ

最初に初心者向けの説明です: このページで論じているXFree86ドライバを使用するには、 /etc/X11/XF86Config か /etc/X11/XF86Config-4 ファイル ( -4 ファイルが存在すれば、その設定が優先されます)の、 Driver文を、 Driver "sis" を読むように変更する必要があります。

XFree86ドライバの機能のいくつかとしては:

デュアルヘッドモード と Xinerama モード

SiS SiS XFree86ドライバは、SiS 300、315、330シリーズで、 ビデオブリッジが存在する場合は、 デュアルヘッド対応です。 (勿論のことですが、2つのVGAカードを使用している場合だけです。 この場合、以下で記述される解像度/カラーのdepth制限は当てはまりません)

「デュアルヘッド」って何? そう、通常、VGAと、LCD、TV、第二VGAが両方接続されている時、 XFree86ドライバは、「鏡像」モードとなり、 つまり同じイメージを両方の出力デバイスに表示します。 「デュアルヘッド」とは、ドライバが2つの異なった画面に、 同時に異なった解像度と異なったカラーdepthで、 CRT1とCRT2を設定する、と言う意味です。 このモードでは、2つの独立したXサーバセッションが (Xineramaではない)デュアルヘッドモードで構成され、 片方の画面からもう一方の画面へウィンドウを移動することはできません。

「Xinerama(ジネラマ)」って何? これはデュアルヘッドモードの特別な種類です。 ジネラマモードでは、両方の出力デバイスに表示される画面は、 仮想的に一つの大きな画面を作り出す。 これで例えば、ウィンドウをVGAモニターからLCDへ、またはその逆方向へ 移動させることができる。 ジネラマモードでは、一つのXサーバセッションだけが構成される。

ジネラマの HOW-TO がある。 これを読む時は、「XF86Config」を「XF86Config-4」と同じ物とし、 2つのグラフィックカードが必要と言う記述は無視して下さい。 両方のDevice セクション で、同じ BusIDDriver を使い、代わりに対応する Screen0Screen 1 を追加して下さい。

デュアルヘッドとジネラマモードを設定するには、XF86Config(-4)に、 それぞれのヘッドに対して一つずつ、 2つの Device セクション、 2つの Monitor、 2つの Screenセクションが必要です。 下記の download sectionの XF86Config-4の例を見て下さい。

  • 2つの画面のカラーdepthと解像度は異なることが可能である。 ジネラマモードでは、しかし、 2つの画面のカラーdepthは同じでなければならない (解像度は異なっていても構わない)。
  • メモリーバンド幅の制限に依存して、 解像度/カラーのdepth/リフレッシュレートは制限を受けるかも知れない。
  • DRIはデュアルヘッドとジネラマモードではサポートされない
  • 8bpp (256色)モードはデュアルヘッドとジネラマモードではサポートされない
  • 300シリーズでは、CRT2の320x200、320x240、400x300、512x384及び640x400は、 デュアルヘッドとジネラマモードではサポートされない
  • 繰り返します: XF86Config-4ファイルの例を読んで下さい!
混合フレームバッファモード

2003/03/25以来、XFree86ドライバは混合フレームバッファモード (MergedFB mode)もサポートするようになりました。 この機能はNVidiaのバイナリドライバ (そこではこれを「TwinView」と呼んでいる)と XFree86のmgaドライバ に触発された物です。 SiS XFree86ドライバは、このオプション指定方法の点では、 mgaドライバに完全互換となっています。

MergedFBモードはジネラマモードの特別な種類です。 それは実質的にジネラマのように動作し、 つまりは、アプリケーションに透過的な 2つのヘッドでの大型画面を構成します。 しかし、このモードではジネラマとは違い、 1つの画面を、それ自体一つのXサーバとしても扱えるように 偽装します。 このことは一つの主要な優位性を提供します、 すなわちジネラマより高速に動作します。

300シリーズでは、ジネラマに対するもう一つの優位性として、 MergedFBモードではDRIが使用できるということがあります。

315、650、740では、MergedFBモードは、 ハードウェアビデオアクセラレーション(Xv)の点で、はるかに優れています。 以下のXvに関する説明を見て下さい。

MergedFBモードは、デュアルヘッドやジネラマモードとは違った方法で 設定されます。 より詳しい情報については オプション解説の章 を見て下さい。

注意: sisctrlツールは、ジネラマよりもこのモードでの方が、 ずっとよく機能します。 ジネラマより、MergedFBを使うことを、大いに推奨します。

Xv (ハードウェアビデオアクセラレーション)

ハードウェアビデオアクセラレーション ("Xv") は、 グラフィックハードウェアによって実現される 「オーバレイ」ウィンドウと呼ばれるもので実現されます。 基本的には、ビデオを再生したいアプリケーションは、 単にビデオイメージデータをXサーバに渡すだけです。 それにより、このビデオイメージデータは、 オーバレイウィンドウの中で表示されます。 このオーバレイは他の画面の画像の上(または下)に、 他の操作なしで、表示できます。 これは、他の画面画像と完全に独立に、オーバレイを作ることができ、 また、ソフトウェアによってRGBに変換する必要のない、 ビデオの標準の色空間フォーマット(YU12, YUV2, UYVY, ...)で エンコードされた、ビデオのイメージデータを扱うことができるため、 高速です。

Xvはは全てのチップセットでサポートされています。 しかしながら、ハードウェアバグのため、 古いシリーズでは、色表示の誤りや、縁の消失などの問題が 起こることがあり得ます。

ドライバは以下の色空間("fourcc")フォーマットを直接サポートします: YV12、I420、UYVY、YUY2、RV15、RV16。 315シリーズでは、YVYUもサポートします。 330シリーズでは、NV12 と NV21もサポートします。

ビデオフレームの最大サイズ(ビデオソースの大きさ)は

  • 5597/5598 では 384x288、
  • 6326、530/620、300 シリーズ では 720x576、
  • 315 と 330 シリーズ では 1920x1080、
  • しかし:CRT1とCRT2が両方有効な時は、 M650、651 では 960x1080 (多分 661FX、M661FX/MX、741、760 では 1536x1080)

輝度、コントラスト、色相、彩度のデフォルト値は (後の2つは、315及び330シリーズのみ)、 ドライバオプションでセットできます。 ここを参照。

以下の情報は、300、315、330シリーズだけに該当します:

  • 315、650、740 及び 330 (Xabre) は、 1つのビデオオーバレイをサポートします (ビデオは CRT1 または CRT2 に表示できます)。 その他は2つのビデオオーバレイをサポートします
  • 一つのオーバレイをサポートするチップセットについて:
    • ミラーモード(つまりCRT1とCRT2が同じ映像を表示する)では、 オプションXvOnCRT2 で、CRT1かCRT2のどちらにオーバレイを表示するかを選択できます。 他方のディスプレイには、カラーキーのみ(デフォルトでは青い画面)か、 オーバレイが適用できないことを示す黒と赤のパターンが、 表示されるだけです。
    • ジネラマでないデュアルヘッドモードでは、同様に、 オプションXvOnCRT2 で、CRT1かCRT2のどちらかを選択できます。 他方のディスプレイには、 オーバレイが現在予約されていることを示す黒/赤のパターンが、 表示されます。
    • ジネラマモードでも同様になります。 ジネラマでないデュアルヘッドモードとの違いは、 パターンはなく、カラーキー(通常は青画面)だけが、表示されることです。
    • MergedFBモードでは、ドライバは、 オーバレイがどこに位置しているかによって、 自動的にCRT1またはCRT2を選択します。
    • SiSCtrlを使って、オーバレイを、CRT1からCRT2に、またはその逆に、 切替えることができます。
  • 2つのオーバレイをサポートするチップセットについて:
    • ミラーモード(つまりCRT1とCRT2が同じ映像を表示する)では、 ビデオはCRT1とCRT2の両方に表示されます。
    • ジネラマでないデュアルヘッドモードでは、 ドライバはヘッド毎に一つのオーバレイをサポートします。 これにより、2つのビデオを同時に、つまりヘッドごとに1つずつ、 再生することができます。
    • ジネラマモードでは、なんの制限もありません。 ビデオは両方のヘッドに表示されます。
    • 混合フレームバッファモードでは、なんの制限もありません。 ビデオは両方のヘッドに表示されます。
  • メモリ帯域幅の制限から、 ディスプレイモードが一定の限界以上のドットクロックで動作していると、 Xvは正常に動作しません。 ドットクロックが高過ぎると、 ドライバはオーバレイを無効にし、同時に、 そのことを示す、黒いウィンドウに赤いパターンを表示します。
  • ドライバはある種の標準でないXVプロパティをサポートします。 ここにその概略を示します (詳細はオプション章を参照して下さい):
    • XV_SWITCHCRT は、オーバレイが表示されるCRT番号を切替えるために使います。 (XvOnCRT2オプションと類似しています 上の記述とここを見て下さい)。 このオプションは、当然ですが、1つだけしかオーバレイをサポートしない チップセットだけで有効です。
    • XV_DISABLE_GRAPHICS は、Xvが使われている間、グラフィック出力を無効にします (これでメモリ帯域幅利用を最小限度にできる有利さがあります)。
    • XV_DISABLE_GRAPHICS_LR も似た機能を持ちますが、 オーバレイの左右のグラフィックディスプレイだけを無効にします。 works in a similar way, but disables graphics display only left and right of the overlay.
    • XV_TVXPOSITION 及び XV_TVYPOSITION は、TVセットの画面位置を微調整することができ、 TVXPosOffset 及び TVYPosOffset オプション (ここを見て下さい)。 と同様に動作します。
    • ドライバのクロマキー機能の情報については、 ここ を見て下さい。
DRI:
  • DRI ("Direct Rendering Infrastructure") は、OpenGLとハードウェア3Dアクセラレーションを基盤としている。 DRIがない場合、XFree86は、殊のほか遅い、OpenGLと3Dの ソフトウェアレンダリングを使用する。
  • このページで扱っているXFree86ドライバは、DRIに関しては何もしません。 代わりに、この機能の専用ドライバを必要とします。 この専用ドライバは、DRI開発者により作られています。 私はDRI関係の開発は全く行なっていないので、 私にDRIについてお尋ねになるのは、全く意味がありません (そしてそういった質問にはお答えしないでしょう)。
  • DRIは300シリーズ(300/305、630、730)でだけサポートされています。 SiS 300シリーズ用のDRIドライバは、XFree86 4.1、4.2(.1) 及び 4.4 で 実現されています。XFree 4.3には、SiS DRIドライバは含まれません。 しかし、4.2(.1)のドライバをインストールすれば、正常に動作します。 (Debianユーザへ: XFree 4.3をインストールした後、 xlibmesa3 パッケージをインストールして下さい。 しかしご注意:xlibmesa3パッケージは、 Xサーバと同じリビジョンのコンパイラでコンパイルされていなければ なりません。)
  • 繰り返します: SiS 6326, 5597/5598, 530/620, 315, 550, 650, M650, 651, 740, 330, 661FX, M661FX/MX, 741, 760 のDRI/OpenGL/3Dサポートはありません。
  • 300シリーズのDRIの情報がもう少しあります。 ここ を見て下さい。
256 色 (8bpp) モード:
  • 300、315 及び 330 シリーズでは、ハードウェア設計の制限により、 CRT1とCRT2が同時に使われる時の、8ビットのカラーdepthのモードは、 うまくサポートされていません。 CRT1とCRT2は、両方とも、完全に同じタイミング値を使わなければならず、 このことから、CRT1のリフレッシュレートは、極めて低くなります。 CRT2が無効にされた時は、CRT1は通常のリフレッシュレートで動作します。
  • ハードウェア設計の制限により、8ビットのカラーdepthのモードは、 デュアルヘッド、ジネラマ、MergedFBモードではサポートされません。
3. The SiS Display Control Panel (sisctrl)

sisctrl is a tool for setting/changing some driver parameters during runtime on a 300, 315 or 330 series based machine/card. It requires the gtk+ 2.0 (or later) library. SiSCtrl will not work on the old series!

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

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

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

Display mode CRT2 type Gamma TV Video Current config

As regards the display modes and the CRT2 type, sisctrl has some limitations:

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

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

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

sisctrl also knows some command line options. sisctrl -h will show a short help text.

4. Display modes and monitor configuration for XFree86
Old series

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

300, 315 and 330 series

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

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

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

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

Notes on modes for LCD panels:

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

On the 301, 301B, 301C and 302B, the X driver has the ability to drive LCD panels with non-standard resolutions. To make this as easy to configure as possible, the X driver will automatically add proper modelines to its built-in list according the panel's very needs. However, this feature has a few requirements:

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

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

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

Summary: Enough techno-babble!

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

Monitor configuration is done by setting VertRefresh and HorizSync in the Monitor section(s) of the configuration file. These settings are only used for CRT1 (VGA output) and CRT2 if CRT2 is (secondary) VGA. You don't have to worry about your LCD panel or your TV; timing will be done automatically for these - no need to fiddle with monitor settings, the driver will do everything automatically.

If you have a DDC2 compliant monitor, the driver will use the DDC data. In this case, the VertRefresh and HorizSync don't need to be set. Otherwise, these must be set to somewhat reasonable values to keep the X server's mode validation logic from deleting desired (and hardware-wise supported) modes from the list of default modes.

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

Available built-in modes on the 300 series:

CRT1 LCD TV VGA2
LVDS 301 30xB 30xLV Chrontel 301 30xB 30xLV 30x/B only
320x200 OK
(70Hz only)
OK ? ? ? NO ? ? ? ?
320x240 OK
(60Hz only)
OK ? ? ? NO ? ? ? ?
400x300 OK
(60Hz only)
OK ? ? ? NO ? ? ? ?
512x384 OK
(60Hz only)
OK ? ? ? NO ? ? ? ?
640x400 OK
(70Hz only)
OK OK OK ? OK OK OK ? ?
640x480 OK OK OK OK OK OK OK OK ? OK
720x480 OK
(60Hz only)
NO NO NO NO NO OK
(NTSC only)
OK
(NTSC only)
OK
(NTSC only)
OK
(60Hz only)
720x576 OK
(56Hz only)
NO NO NO NO NO OK
(PAL only)
OK
(PAL only)
OK
(PAL only)
OK
(56Hz only)
768x576 OK
(56Hz only)
NO NO NO NO NO OK
(PAL only)
OK
(PAL only)
OK
(PAL only)
OK
(56Hz only)
800x480 OK NO NO NO NO NO NO NO NO OK
848x480 OK NO NO NO NO NO NO NO NO OK
856x480 OK NO NO NO NO NO NO NO NO OK
800x600 OK OK OK OK OK OK OK OK ? OK
1024x600 OK
(60Hz only)
OK NO NO NO NO NO NO NO OK
(60Hz only)
1024x576 OK NO NO NO NO NO NO NO NO OK
1024x768 OK OK OK OK OK NO NO OK ? OK
1152x768 OK
(60Hz only)
? NO NO NO NO NO NO NO OK
(30xB only)
1152x864 OK NO NO NO NO NO NO NO NO OK
(30xB only)
1280x720 OK NO NO NO NO NO NO NO NO OK
(30xB only)
1280x768 OK
(60Hz only)
? ? ? ? NO NO NO NO OK
(30xB only)
1280x960 OK NO OK ? ? NO NO NO NO OK
(30xB only)
1280x1024 OK ? ? ? ? NO NO NO NO OK
(30xB only)
1360x768 OK
(60Hz only)
NO NO NO NO NO NO NO NO OK
(30xB only)
1360x1024 OK
(60Hz only)
OK
(see below)
NO NO NO NO NO NO NO OK
1600x1200 OK NO NO NO NO NO NO NO NO NO
1920x1440 OK NO NO NO NO NO NO NO NO NO

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

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

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

CRT1 LCD TV VGA2
LVDS 30x/B/C 30x[E]LV Chrontel 301 30xB/C 30xLV 301 30xB/C 301B-DH
320x200 OK
(70Hz)
? OK OK ? OK OK OK OK
(70Hz)
320x240 OK
(60Hz)
? OK OK ? OK OK OK OK
(60Hz)
400x300 OK
(60Hz)
? OK OK ? OK OK OK OK
(60Hz)
512x384 OK
(60Hz)
? OK OK NO OK
(PAL/PAL-N)
OK
(PAL/PAL-N)
OK
(PAL/PAL-N)
OK
(60Hz)
640x400 OK
(70Hz)
OK OK OK ? OK OK OK OK
(70Hz)
640x480 OK OK OK OK OK OK OK OK OK
720x480 OK
(60Hz)
NO NO NO NO OK
(NTSC/PAL-M)
OK
(NTSC/PAL-M)
OK
(NTSC/PAL-M)
OK
(60Hz)
720x576 OK
(56Hz)
NO NO NO NO OK
(PAL/PAL-N)
OK
(PAL/PAL-N)
OK
(PAL/PAL-N)
OK
(56Hz)
768x576 OK
(56Hz)
NO NO NO NO OK
(PAL/PAL-N)
OK
(PAL/PAL-N)
OK
(PAL/PAL-N)
OK
(56Hz)
800x480 OK NO NO NO NO OK
(HiVision)
OK
(HiVision/1080i)
OK
(1080i)
OK
800x600 OK OK OK OK OK OK OK OK OK
848x480 OK NO NO NO NO NO NO NO OK
856x480 OK NO NO NO NO NO NO NO OK
1024x576 OK NO NO NO NO OK
(HiVision)
OK
(HiVision/1080i)
OK
(1080i)
OK
1024x768 OK OK OK OK OK NO OK OK OK
1152x864 OK NO NO NO NO NO NO NO OK OK NO
1280x720 OK NO ? ? NO OK
(HiVision)
OK
(HiVision/1080i)
OK
(1080i)
OK OK NO
1280x768 OK
(60Hz)
? OK ? NO NO NO NO OK OK NO
1280x800 OK
(60Hz)
NO OK ? NO NO NO NO OK OK NO
1280x960 OK NO OK OK NO NO NO NO OK OK NO
1280x1024 OK OK OK OK NO OK
(HiVision)
OK
(HiVision/1080i)
OK
(1080i)
OK OK NO
1360x768 OK
(60Hz)
NO NO NO NO NO NO NO OK OK NO
1400x1050 OK OK ?
(301B/C)
OK
(302[E]LV)
NO NO NO NO NO OK NO
1600x1200 OK ? ?
(301C)
?
(302[E]LV)
NO NO NO NO NO OK NO
1680x1050 OK NO ?
(301C)
?
(302[E]LV)
NO NO NO NO NO OK NO
1920x1440 OK NO NO NO NO NO NO NO NO
2048x1536 OK NO NO NO NO NO NO NO NO

Remarks for 300/315/330 series:

Modes marked with X are technically possible, but I lack knowledge of the required timing data. Modes marked with - are not supported due to hardware limitations. Modes marked ? should work but have not been tested.

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

Note on TV modes on SiS bridges: 512x384, 720x576 and 768x576 are only supported in PAL/PAL-N mode. 720x480 is only supported in NTSC/PAL-M mode. All modes for NTSC are supported in YPbPr 480i, 480p and 720p HDTV mode, too. YPbPr and HiVision are only supported on the 315/330 series. Modes marked with "HiVision" and/or "1080i" are supported in HiVision or YPbPr 1080i HDTV mode only (and hence not PAL/NTSC or YPbPr 480i, 480p and 720p). 1280x720, 1024x576 and 800x480 are meant for YPbPr HDTV output (via video bridge = CRT2); on CRT1 these have identical timing like 1280x1024, 1024x768 and 800x600 but with a reduced visible area. If you connect, for instance, a projector to CRT1 (VGA plug) and want real wide-screen modes, simply add a proper modeline to your Monitor section. YPbPr and HiVision support is yet untested. Both YPbPr and HiVision require the machine to have a proper YPbPr connector; if you intend to connect your HDTV via DVI, the "LCD" tab in the tables above applies instead.

For interlace-related issues, see the FAQ

5. High resolution modes and TV output on the SiS6326

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

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

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

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

Just place these modes in the Screen section of your XF86Config-4, for example as follows:

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

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

6. Driver options

For the XFree86 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
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
ForceCRT2ReDetection force driver to ignore BIOS info and redetect CRT2 type
NoCRT2Detection disable auto-detection of CRT2 type
CRT1Gamma*
CRT2Gamma*
enable/disable gamma correction
StoredGammaBrightness*
StoredGammaPreBrightness*
define default gamma brightness (requires SiSCtrl to take effect)
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
set up Merged Framebuffer mode
EnableSiSCtrl enable/disable SiSCtrl interface
2. LCD related options
ScaleLCD enable/disable scaling of LCD output
PanelDelayCompensation [panel timing related]
SpecialTiming [panel timing related]
LVDSHL [panel timing related]
EMI [panel timing 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)
YPbPrAspectRatio select aspect ratio for YPbPr (HDTV) 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
ChromaMin
ChromaMax
select chroma key
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
specialtiming
noaccel
noypan
nomax

* * *

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 XFree86 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) 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. The XFree86 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 XFree86 driver do not share a common video memory management. This option/parameter is meant to avoid a conflict between sisfb and the XFree86 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 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 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 XFree86, the green area is reserved for DRI)

maxxfbmem

Usually, sisfb is started before XFree86. The SiS XFree86 driver, during its startup, checks if sisfb is running and queries it for how much video memory XFree86 is allowed to use. However, there are two situations where does not work: If you are running a 2.4 series kernel and
  1. start sisfb with no mode or
  2. have compiled sisfb as a module and did not load it before starting XFree86,
the XFree86 driver cannot communicate with sisfb. Therefore, in these two cases - and only in these two cases, the XFree86 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 XFree86 driver by setting the Option "MaxXFBMem" "8192".

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 (XFree86 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 XFree86 is not necessary in this case.
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 XFree86 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: 650, M650, 651, 661, 741, 760 with 301C/30xLV video bridge (mostly laptops)
Description: This option introduces a new concept as regards CRT1 and CRT2 cooperation and LCD handling: Effectively, it allows simultanious LCD and TV output on machines supporting this.

Important: This concept only works on machines with a SiS 301C or 30xLV video bridge, and which have the bridge wired to the VGA controller in a special way. I believe that most current machines with a 650, M650 and 651 comply to this requirement, as do the 661, 741 and 760. The 740 and 315 do not.

On such machines, the scheme shown above varies in the following way:

VideoBridgeLCDA

As you can see, on such machines, the CRT1 output of the VGA chip is wired to the LCD panel. (Well, this is not entirely accurate actually, as the CRT1 output is in fact connected the the so-called "Channel A" of the video bridge; but we'll ignore this detail here for educational reasons).

This enables us 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 650, M650, 651, 661, 741 and 760 and a SIS 301C or 30xLV video bridge.
  • LCD panels must have a native resolution of 1024x768, 1280x1024, 1400x1050 or 1600x1200. (Tested only on 1024x768 and 1400x1050 yet, others untested!)
  • The 650 (but not later chips) has 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 CRT1! (Might require reversing in the screen order in dual head and MergedFB mode, etc)
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.

On the SiS 550, this option also accepts DSTN and FSTN for DSTN/FSTN LCD panels. FSTN only supports 320x240 panels. This feature 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 SVideo and CVBS, the driver might wrongly detect a HDTV. That is a hardware limitation.
  • All YPbPr (HDTV) modes are entirely untested. "HDTV" means direct YPbPr output; if you're thinking about connecting your HDTV via DVI, this is a different story.
  • 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"
    • The SiS301 and the Chrontel 7005 support resolutions up to 800x600. The 30xB/C/LV and the Chrontel 7019 support resolutions up to 1024x768.
    • 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.
    • 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.
    • 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.
Synopsis/Example:
X driver:Option "ForceCRT2Type" "TV"
sisfb (module):modprobe sisfb forcecrt2type=TV
sisfb (kernel):video=sisfb:forcecrt2type:TV

* * *

Name:
X driver:ForceCRT2ReDetection
sisfb:n/a
top
Parameter: boolean
Chipsets: 315, 330 series with a SiS 301/301B/301C/302B video bridge
Description: Newer 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:CRT1Gamma and CRT2Gamma
sisfb:n/a
top
Parameter: boolean
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 70xx). 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.

Note: If you are running dual-head mode, the CRT1Gamma option should be placed in the Device section for CRT1.
Synopsis/Example:
X driver:Option "CRT2Gamma" "off"
sisfb (module):n/a
sisfb (kernel):n/a

* * *

Name:
X driver:StoredGammaBrightness
StoredGammaPreBrightness
sisfb:n/a
top
Parameter: one or three floating point numbers
Chipsets: 300, 315, 330 series
Description: XFree86's gamma correction is quite simple, usually. You select (one or) three gamma values between 0.1 and 10.0 in the Monitor section, from which XFree86 will compute a default gamma ramp. XFree86's configuration file does not support things like setting gamma brightness.

What sisctrl does when you change the gamma brightness or pre-brightness, is recalculating the gamma ramp. This is the curve as seen in sisctrl.

These options provide a work-around for the missing feature of defining a gamma brightness in the XFree86 server configuration. They pre-define the gamma brightness and pre-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 XFree86 server, the SiS XFree86 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 XFree86 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 or pre-brightness, it is mandatory to set these options in your XF86Config(-4) as shown in the Current-tab in sisctrl, and to execute sisctrl -sg every time after starting the XFree86 server, for example by editing your .xinitrc or .xsession file. This will set the gamma brightness and pre-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 option should be placed in the Device section for CRT1 if they are meant for CRT1.
Synopsis/Example:
X driver:Option "StoredGammaBrightness" "1.2 1.0 0.8"
sisfb (module):n/a
sisfb (kernel):n/a

* * *

Name:
X driver:UseROMData
sisfb:userom
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: Using this option is not recommended. [Documentation removed]

* * *

Name:
X driver:UseOEMData
sisfb:useoem
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: Using this option is not recommended. [Documentation removed]

* * *

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. How does it 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 (aka "merged") either aside 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 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. Another possibility is to 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. The latter will check if both CRT1 and CRT2 are detected, and only if both are found, enable MergedFB mode. Using MergedFBAuto 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


  • The absolute size of the virtual desktop is specified with the generic XFree 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 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).

    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).

  • 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). 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.

    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. 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"
    ...
    EndSection


    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. If a mode for CRT1 or CRT2 does not meet the hardware/monitor specs, it will be discarded and cannot be used as part of a meta mode.

    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 mode in this example is special: 800x600 (without a dash followed by another mode) 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").

    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). If the Virtual keyword is missing (as well), the driver will adapt the virtual desktop size to the size of this meta mode.

  • Monitor configuration: The data in the Monitor section will be used for CRT1. Especially if you are using a secondary VGA monitor, 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: You need to use sane values, regardless whether CRT2 is LCD, TV or secondary VGA. They are required to keep the X server from deleting modes from the list. For TV and LCD, ranges like 30-50 for HSync and 50-75 for VRefresh do fine.

    If the CRT2HSync and/or CRT2VRefresh options is/are missing, the data provided via DDC will be used. If the CRT2 device does not support DDC (such as TV and most laptop LCD panels), the monitor data for CRT1 will be used (which is the data from the Monitor section).

  • 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 XFree86's drawing functions depend on information on the physical display size. Basically, this means the absolute physical size of your output device. 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 Virtual keyword is missing in the Screen section, the driver will adapt the virtual size to the size of the largest meta mode.
    2. If the option CRT2Position is missing, RightOf is assumed.
    3. 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.
    4. 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.

    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 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:

For MergedFB mode, the SiS XFree86 driver has a built-in (pseudo) Xinerama extension, allowing windows managers to place windows smartly, and applications to do a proper full-screen mode (which fills only one of the two heads). Technically speaking, this pseudo-Xinerama extension provides a set of functions for clients to discover the current MergedFB mode configuration. 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 (RandR disregarded for educational reasons), this is not the case in MergedFB mode: Here, it depends on the current Metamode, 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 scrolled 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 area, and there is no yellow line. Hence, to be absolute accurate, the Xinerama information varies with each meta mode.

Since the concept of MergedFB mode is relatively new, window managers and applications do not expect the Xinerama information about screen placement and size to change during a server session. KDM, the KDE display manager, for example, queries the Xinerama extension only once during startup. As a conclusion, the Xinerama information is to be considered static.

Therefore, the SiS XFree86 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 XFree86 driver's pseudo-Xinerama extension. By default, this SiS pseudo-Xinerama extension is enabled.

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.

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.

* * *

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 was introduced 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:ScaleLCD
sisfb:scalelcd
top
Parameter: boolean
Chipsets: 300, 315, 330 series
Description: Setting this option to yes (or 1 in case of sisfb) forces the driver to scale the output on LCD panels in modes lower than the panel's native resolution to that resolution. In other words: If this is enabled, LCD output will always fill the whole screen, regardless of the display mode.

Setting this to no (or 0 in case of sisfb) will disable scaling; different panels will, however, react differently to this. Most laptop panels will simply show a black bar around the image. External panels (connected through DVI,for instance) will activate their own, built-in scaler and fill the whole screen.

For some display modes in combination with some panels this setting will be overruled by the driver.

Warning: Some panels might not support disabling scaling. So if your panal only displays garbage, quit the X server and remove that option from the configuration file.

The default depends on the panel.
Synopsis/Example:
X driver:Option "ScaleLCD" "yes"
sisfb (module):modprobe sisfb scalelcd=1
sisfb (kernel):video=sisfb:scalelcd:1

* * *

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) after starting X, first try setting this option to either "4", "32" or "24" on 300 series, 3 or 51 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)

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.
Synopsis/Example:
X driver:Option "PanelDelayCompensation" "32"
sisfb (module):modprobe sisfb pdc=32
sisfb (kernel):video=sisfb:pdc:32

* * *

Name:
X driver:SpecialTiming
sisfb:specialtiming
top
Parameter: string
Chipsets: 300, 315, 330 series
Description: 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), 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 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.)

Basically, auto-detection should work (except for the 848x480 panels). In case it fails, set this option accordingly. Currently, the driver knows 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 parallel or LVDS plasma panels with a resolution of 848x480.
  • NONE can be used to disable the automatic detection. No special timing will be used then.
In sisfb prior to 2003/11/11, these options are still called:
  • BARCO1366 (for Barco iQ R series),
  • BARCO1024 (for Barco iQ G series),
  • COMPAQ1280 for the Inventec/Compaq Presario 3045US, 3017LC and other models (1280x1024)
  • CLEVO1024 and CLEVO10242 for (2 different types of) Clevo L285/L287,
  • CLEVO400 for Clevo D400 (tested with 1400x1050 panel),
  • UNIWILL1024 for Uniwill N243S9 (Siemens-Fujitsu Amilo EL),
  • ECS1024 for some ECS A928,
  • ASUSLVDS1024 for Asus L3000D (SiS740 + Chrontel 7019), and
  • PANEL848x480 for directly parallel or LVDS plasma 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 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.
Synopsis/Example:
X driver:Option "EMI" "0x2012d06b"
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 driver auto-detects the BIOS setting for PAL or NTSC (or PAL-M or PAL-N) in 99% of the cases. If it fails to do this on your machine, ie. you chose PAL in the BIOS 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) and PALM (for Brazil), and NTSCJ (Japanese NTSC). PALM, PALN and NTSCJ are available in the X driver only. However, in case of the SiS bridges, not all machines are capable of using PAL-M and PAL-N. This obviously depends on the hardware and cannot be worked around. If the hardware does not support PAL-M or PAL-N, PAL will be used.

On the 300, 315, 330 series the sisctrl utility allows changing the TV standard during server-run-time.
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:n/a
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.
Synopsis/Example:
X driver:Option "TVXPosOffset" "-10"
sisfb (module):n/a
sisfb (kernel):n/a

* * *

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"
XOption "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"
XOption "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"
XOption "SISTVColorCalibFine" "-118"
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 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: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
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. 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.
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.
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.
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.
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.
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.
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.
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.
Synopsis/Example:
X driver:Option "XvChromaMin" "0x123456"
Option "XvChromaMax" "0xabcdef"
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: 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)

III. Summary of changes
a) since the release of XFree86 4.2

The SiS driver that comes with XFree86 4.2 and 4.2.1 is an older version of my driver. Since then, the following changes have been made (rough overview):

  • For the 300 series, the whole mode switching code was re-written
  • Support for 315 series was added (including 2D acceleration, Xv and DPMS)
  • Dual Head support for the 300, 315 and 330 series was added
  • Support for 30xB, 30xLV video bridges (on 300, 315, 330 series) was added
  • Support for 630ST was added
  • LVDS support for the 315 series was added (for LCD panels up tp 1400x1050)
  • Chrontel 7019 support for the 315 series was added
  • For the 300 series, numerous bugs were fixed (Xv did not work on CRT2; Xv scaled the video incorrectly in some cases; OpenOffice.org and Mozilla revealed a few bugs in the 2D accelerator; the TurboQueue could cause a machine hang; etc.)
  • The 2D accelerators on the 530/620, 300 and 315 series now support transparent BitBlits
  • Various bugs for the 530/620 were fixed (hardware cursor, etc.)
  • The 2D accelerator on the 530/620 now supports Scanline-CPU-To-Screen-Color-Expansion, lines and dashed lines
  • Xv support for the 300, 5597/5598, 6326, 530 and 620 was added
  • Support for I420, UYVY, RGB555 (RV15) and RGB565 (RV16) color space was added in Xv part (all supported chipsets).
  • Support for v4l (video4linux) was added in Xv part (all supported chipsets)
  • The driver now supports SiS VGA devices as secondary display adapters
  • Gamma correction facility for CRT1 (VGA) was added (all supported chipsets)
  • Numerous driver options were added
  • Support for TV output on the SiS 6326 was added
  • Preliminary support for the 330 series was added
  • Support for color HW cursors on 300/315/330 series was added (XFree 4.2.99.3 or later required)
b) since the release of XFree86 4.3
  • Numerous bug fixes (duh!)
  • 330 (Xabre) support was fixed and completed
  • Implemented DVI-D (LCD/Plasma) and DVI-A (secondary VGA) output support
  • Implemented LCD and VGA2 detection via DDC2B
  • Enhancements to Xv part for 315/650/740 (output CRT number switchable, etc.)
  • Merged Framebuffer mode was implemented (including Xv and HWCursor support, as well as a pseudo-Xinerama extension for window hinting)
  • Specific support for some 1280x768 LCD panels via DVI-D was added
  • Support for 1280x960 and 1280x1024 LCD panels via DVI-D was fixed
  • Support for non-standard LCD/Plasma resolutions and auto-detection thereof was added (SiS301, 301B, 301C, 302B only)
  • A small, internal database for some Plasma panels and their supported modes was added (no need for Modelines if panel is in database)
  • Support for using user-provided Modelines for LCD and secondary VGA was added (SiS301, 301B, 301C, 302B only)
  • Various TV problems on 301, 30xB and 30xLV were fixed; 1024x768 for NTSC and 768x576 for PAL were added; etc.
  • Support for Barco iQ R and G series projectors was added
  • Support for Xv chroma keying was added (300, 315 and 330 series)
  • SiSCtrl, the SiS Display Control Panel, was written and the driver was enhanced to support this
  • YPbPr (480i, 480p, 720p, 1080i) and HiVision (1080i) (HD)TV output was implemented
  • (Widely untested) support for 661, 741 and 760 and new video bridges (301C, 302ELV) was added
  • For 315/330 series, RENDER is now accelerated (as regards text-antialiasing and blitting ARGB bitmaps). The 2D acceleration for these chipsets does no longer use MMIO but a video RAM based command queue.
  • Support for Trumpion Zurac LVDS scalers was added (for 1024x768 LCD panels and on 300 series only)

IV. Troubleshooting and FAQ

In this section I have compiled some questions (including their answers) which use to come up from people out there using the driver.

  • Q: Is TV output on the 6326 supported?
  • A: Yes, it is (since 2002/10/28). Please see here.
  • Q: Why do I only get black and white on my TV?
  • A: Check the PAL/NTSC setting in the BIOS. If this is set to NTSC, a picture might be displayed on PAL sets, but colors are missing. Instead of using the BIOS setting, you can also overrule the choice by using the option TVStandard. If the TV standard is correct and you are using a SiS 6326, try playing around with color calibration done with the option SIS6326FSCAdjust (see here). On SiS video bridges, color calibration can be done by the options SISTVColorCalibCoarse and SISTVColorCalibFine (see here).
  • Q: I have a machine with a Chrontel TV encoder. Why does my TV show a black bar around the screen?
  • A: Please see my comments on the tvoverscan option above.
  • I installed XFree 4.3 and I don't have 3D support anymore on my 300 series chipset. What's wrong?
  • Due to the inclusion of Mesa version 4 in XFree 4.3, the SiS DRI driver was disabled because nobody converted it to Mesa 4. You can still use Mesa version 3 which came with XFree 4.2. Debian users may just install the xlibmesa3 packages from 4.2 (which are available in the download section on this page.) Users of other distributions should backup all existing libGL.so*, libGLU.so* files as well as all files in /usr/X11R6/lib/modules/dri/ before installing XFree 4.3. After that simply copy them back to their old locations. But beware: The DRI driver files *must* have been compiled with the same version of gcc as the X server. Update: An updated DRI driver is in XFree86 4.3.99.14, meaning that there is no such workaround required if you are using this version or later.
  • Tuxracer is terribly slow on my SiS315/550/650/651/M650/330/661/741/760
  • DRI and hardware accelerated OpenGL/3D is not supported on these chipsets. I don't know how many times I must say this. And besides, I don't do any DRI related development. Complaints should be sent to the DRI project's mailing lists (dri.sf.net)
  • I have problems with DRI.
  • Please stop asking me questions about DRI. All information I have is available at my DRI page. And no, I do not develope anything DRI related. Please contact the DRI project for problems with DRI/OpenGL/hardware accelerated 3D.
  • Xv is terribly slow and takes 30% CPU time or more. What's wrong?
  • As of 06/05/2003, there is a confirmed bug in the SuSE 8.2 XFree 4.3 packages and probably in XFree 4.3 packages of some other distributions as well. I know of at least Debian's 4.3.0pre1v1 containing this bug, too. This is no SiS driver bug and there is no real workaround available. However, on some systems, especially Athlon based ones, it helps setting the option XvUseMemcpy to false. Later versions of XFree86 will hopefully fix this problem rendering this option unneccessary. (Technical explanation: There is a problem with memory access in these versions of XFree86, rendering memcpy-operations to video RAM extremely slow. SiS hardware is not the only one affected, there were numerous complaints from users of other hardware, too. This bug is also known as the "O_SYNC bug". If you want to know more, search the archive of the xdevel mailing list for a thread named "Athlon related mystery".)
  • On my M650/651 machine, Xine's video output is distorted when I play the Matrix Reloaded or Matrix Revolutions ultra trailer or any other large video.
  • The Matrix trailers trailers are 1000x540 resp. 1024x534 in size. If you use both CRT1 and CRT2 (be it in clone mode, dual head mode or merged framebuffer mode), the maximum Xv image size is 960x1080, hence smaller than the video source material. Unfortunately, Xine (and Mplayer, by the way), don't care about eventual limits of the image size. Disable either CRT1 or CRT2 and the video will play correctly. (The same basically applies to the 661/741/760, although the limit is 1536 instead of 960 on these.)
  • sisfb does not compile on my vendor kernel
  • Sisfb is designed for stock vanilla kernels from www.kernel.org. Some distributors like Red Hat have changed their kernels which might result in compilation problems. In case of Red Hat's 2.4.20 and later, compilation fails in sis_main.c at a io_remap_page_range() call. Add "vma" as the first parameter to the function call.
  • The X driver fails to work on my XFree86 4.1 system with some int10 related unresolved symbols
  • In fact, it's not the SiS driver that has unresolved symbols but the VBE module which the SiS driver loads. Add load "vbe" and load "int10" to the Module section of your XF86Config-4.
  • The SiS driver complains about unresolved "glx..." symbols.
  • Solutuion: Either add Load "glx" to the Modules section of your XF86Config(-4), or disable DRI with Option "DRI" "off" in the Device section. Explanation: A while back, the driver was changed to load the DRI module automatically (which was previously done with Load "dri" in the Modules section of your config file). Now, even if that Load "DRI" statement is missing, the driver will load the DRI module unless this is disabled with the Option "DRI" "off" (in the Device section). The DRI module, however, is not really smart. It does not load the "glx" module automatically. So, if you have no Load "glx" in the Modules section, the DRI module (which is loaded by the SiS driver) will fail with unresolved "glx" symbols.
  • Since Dec 9, 2003, video applications (Xine, mplayer, etc) suddenly show videos too dark or too light.
  • The XV contrast settings was the wrong way until that day (higher value meant lower contrast). I reversed that, so you need to tell your video application the new best value (such as in case of Xine which saves the XV properties in its config file). The default was 5 and is now 2.
  • Why does output of interlaced video via TV show a "comb-like" "interlace"-effect? If the source material is interlaced and the TV output is interlaced, shouldn't this match?
  • CRT2 does not support interlace. Therefore, the driver can't feed interlaced output into the video bridge (which handles TV output, be it a SiS video bridge, be it a Chrontel TV encoder). The video bridge can only convert a progressive scan (=non-interlaced) input into TV-suitable interlaced output. The driver can neither change this nor control which of the frames sent to the bridge is the even/odd field. Long story short: If you want to output interlaced material on your TV without using a software de-interlacer, you need to add a proper Modeline for interlaced PAL/NTSC timing (easily found on the internet) and an external VGA-to-TV converter connected to CRT1. Otherwise you have to use a software de-interlacer.

V. Changelog

I frequently update this page whenever I have time, so the information is more actual the farther down. And please: Before reporting bugs, always try the most current version of the drivers and read this page.

[Older information on changes was moved to a separate page.]

UPDATE (03/07/02) Fixed setting the TV position for 1024x768 in NTSC.

NEWS: The last two days I have been busy writing a program called SiS Display Control Panel, short: sisctrl, which will accompany the X driver from now on. This panel allows, among other things, switching the CRT2 output type during runtime. Check it out, it's in the download section. Note: This tool is in the first phase of its development, so please be patient if it does things it's not supposed to.

UPDATE (03/07/03) Fixed small bugs in X driver's TV option handling. Big update of the sisctrl tool: Chrontel TV parameters added, various bugs fixed. Addendum: Fixed another hardware cursor bug for the 330 series (the Xabre's engine is really skrewed). (Hopefully) fixed PAL-M and PAL-N support in sisctrl.

UPDATE (03/07/04) Some further enhancements and fixes for sisctrl. Please always update your X driver and sisctrl!

UPDATE (03/07/05) Some further enhancements and fixes for sisctrl: Added option to enable and disable CRT1.

UPDATE (03/07/06) Updated sisfb for 2.5.74.

UPDATE (03/07/09) Further additions to sisctrl: Video settings, gamma correction, new layout, new graphics. Don't forget to update the X driver as well!

UPDATE (03/07/11) Enhanced sisctrl and the X driver. Fixed 640x400 for 300 series with Chrontel TV encoder. Addendum: The sisctrl source archive now uses the GNU autoconf/automake system. Please read the README on how to compile and install it. Addendum 2: Disabled Chrontel 700x 8bpp modes with SuperOverscan.

UPDATE (03/07/12) Another update of sisctrl (and the X driver). From now on, one must set the Option "EnableSiSCtrl" "true" in XF86Config-4, otherwise the sisctrl tool will refuse to start. The other changes within sisctrl are pretty much self-explaining.

UPDATE (03/07/13) Fixed a small bug in sisctrl.

UPDATE (03/07/14) Further enhancements for sisctrl: Current tab prints current configuration in XF86Config-4-compatible manner. Addendum: Another update for sisctrl, along with a new X driver.

UPDATE (03/07/15) Well, here's another update of the X driver and sisctrl. Mostly bug fixes.

UPDATE (03/07/16) Inspired by some friendly Debian user, I created Debian packages for the X driver and sisctrl. See the download section for more information.

UPDATE (03/07/17) Update for the Debian packages of sisxdriver: This package now installs a diversion of the original sis_drv.o; this means that updating the xserver-xfree86 package will no longer overwrite the driver installed by sisxdriver.

UPDATE (03/07/19) Some fixes for the SiS620 in the X driver.

UPDATE (03/07/28) Fixed "BadAtom" error in sisctrl on 300 series. Fixed 720xXXX modes for TV on 30x/B/LV.

UPDATE (03/08/01) Added some further TV settings for SiS bridges to sisctrl, such as scaling the TV output (315/330 series only), color calibration, luma (Y) and chroma (C) filter setup, etc. Added respective driver options, please see here. / Fixed sisctrl Debian package (which I had accidently compiled using XFree 4.3 resulting in an incompatible binary complaining about a missing library).

UPDATE (03/08/02) TV scaling is now supported on the 300 series as well. However, while the driver supports scaling of 800x600, 720x480, 720x576 and 640x480 on the 315 and 330 series, scaling is only supported for 800x600 and 640x480 on the 300 series. Addendum: Re-wrote the code for vertical scaling, this is now supported for 768x576 as well (on 315/330 series). Fixed a bug in the mode verification routine of sisctrl; this requires an update of both the X driver and sisctrl.

UPDATE (03/08/04) Implemented a small Xinerama extension for MergedFB mode, allowing applications to place their windows intelligently. Please see the options chapter for more information.

UPDATE (03/08/05) Whoops, uploaded broken archives....

UPDATE (03/08/06) Changed some data for 1024x768 panels on 30xLV bridge.

UPDATE (03/08/07) Fixed X driver and sisfb for Clevo L285 and propably L287 LCD-PCs. Added a new special timing, named CLEVO1024 for cases where the detection fails. Addendum: Some small fixes for sisctrl, requires updating the X driver to today's version.

UPDATE (03/08/10) Implemented advanced gamma correction in sisctrl. Again, this requires an update of both sisctrl and the X driver. Added some gamma correction options, please see the options chapter for more information. Addendum: Fixed the TV position offset options, these had no effect recently...

(03/08/21) Currently, I am busy rewriting the 2D acceleration part for the 315 and 330 series to use a new kind of command queue mode (VRAM queue). Works already, but requires some testing before I will release the code. The reason for this is the simple fact that it is much easier to write a DRI driver for 315/330 with this VRAM queue mode. But beware, I do not intend to write such a driver myself, so any respective questions will remain unanswered.

UPDATE (03/08/23) The new X driver contains all the changes annouced August, 21. Furthermore, it knows a new option named LVDSHL for machines with a 301LV or 302LV video bridge and LCD panels. This option should be used in case the LCD display is "too dark" (and only in this case), see the options chapter. SiSCtrl only contains a few smaller changes, but please update anyway. The new sisfb knows the lvdshl option, too. Addendum: Fixed crash on 300 series with DRI enabled.

UPDATE (03/08/26+27) Fixed dual head related crash on 315 series (introduced with VRAM queue mode); fixed LVDSHL option (had no effect...); added RENDER hardware acceleration for 315 series - this speeds up some operations (like AA text under some circumstances) and provides accelerated alpha-blended bitblits. Added support for another type of Clevo L285/287 (see SpecialTiming) / sisfb sync'd. Addendum: Further fix for (second version of) Clevo L285/287. Addendum 2: Solved the PDC problem on LV bridges; this requires an update of both the X driver and sisfb (latter only, if actually used, of course).

UPDATE (03/08/27+28) Fixed bug in Render acceleration (caused "blocks instead of fonts"). On my machine (P4 2.0Ghz), x11perf -aa24text without acceleration reported 25500/sec, now with acceleration 105000/sec. Very nice...

UPDATE (03/08/29) More or less cosmetic fixes for the X driver. Updated sisfb: Compiles with 2.6.0-test4 now; sync'd mode switching code.

UPDATE (03/08/30) X driver: CRT1 is now forced in dual head and MergedFB mode (does no longer require the ForceCRT1 option if monitor is connected after booting); video contrast setting is now reversed on 300/315/330 series (was done the wrong way previously). You will probably re-adjust your Xine/Mplayer/whatever video player settings as regards to the contrast.

UPDATE (03/09/02) X driver: This is quite an important update. It fixes a hang of the X server when using MPlayer. / Furthermore, I discovered a bug in the X server's XAA code (outside the SiS driver), which has been there since before 4.1 - and was never detected until recently. This bug is now more often triggered by the RENDER acceleration, but might show up even without it, for example, after heavy Xv usage. To fix this, I provide patched libxaa.a files in the download section which are to be placed in /usr/X11R6/lib/modules. / Added transparency support for mono 8x8 pattern fills (300/315/330 series), added color 8x8 pattern fill support (315/330 series).

UPDATE (03/09/04) X driver/sisfb: Added support for another customized system, the Clevo D400 (with 1400x1050 LCD panel). I don't know if this is required for all models (D400S/D400H/D410S/D410H) and/or all panel sizes yet. Added respective option parameter for SpecialTiming. / Added proper CRT1 detection code, so that ForceCRT1 is no longer needed if connecting the monitor after booting. / sisfb code sync'd.

UPDATE (03/09/05) Fix a small bug in CRT1 detection, might have hung 300 series based machines with sisfb running. This update is for both the X driver and sisfb.

UPDATE (03/09/08) Fix for people using the SiS X driver together with the kernel's VESA framebuffer driver. This works now, but is not recommended. Use sisfb instead. / Update for sisctrl, added a little eye-candy (bad luck guys, she is my girlfriend), along with some small bugfixes (locale number format fix) and additional command line options. Type sisctrl -? to see a list of options.

UPDATE (03/09/09) X driver/sisfb: Removed code to setup the magnetic spectrum; differs from machine to machine and is setup by the BIOS anyway. However, folks with a SiS302LV (which practically means all machines with LCD panels larger than 1024x768) should test this and report any eventual regression. sisfb: Fixed compile bug for 2.6.x kernels. Further update for SiSCtrl, screenshots, too.

UPDATE (03/09/19) X driver: Introduced simultanious LCD and TV output on some machines. For more information, please see here. Requires an update of both the X driver as well as sisctrl. I'd welcome testing reports on this new feature as it is something that neither the BIOS, nor the Windows driver support.

UPDATE (03/09/20) X driver: Fixed a small bug (LCD wansn't blanked when using TV output).

UPDATE (03/09/22) X driver: Allowed LCD-via-CRT1 on all 650-based machines (with a 30xLV bridge), not just the M650 and 651. Works at least on Mitac machines... Changed gfx in sisctrl (for private reasons).

UPDATE (03/09/23) X driver: Fixed Xv and LCD-via-CRT1 related bug; overlay could not be switched to other CRT under some circumstances (SiS650 only). sisctrl may report an error on switching the CRT2 type for the moment; I'll fix that later today.

UPDATE (03/09/24) Fixed sisctrl's wrong error message when switching CRT2 type. Built an experimental rpm for sisctrl; but beware: I have no idea if that works correctly as this rpm is built on a Debian system using alien.

UPDATE (03/09/26) X driver: Fixed LCD-via-CRT1 bug; top-most line was cut away on 1024x768 panels. 1280x1024 and 1400x1050 panels still untested, reports welcome.

UPDATE (03/09/28) X driver: Reverted fix for LCD-via-CRT1 from previous version. I encourage people with a 650+30xLV to test LCD-via-CRT1 and report a) if it works at all, and b) if there are any lines (top, bottom) missing on the LCD. Please include your X log.

NEWS (03/09/28) Today, Eric Anholt's new DRI driver for the 300 series was merged in XFree's CVS. This means that there will be DRI again for the 300 series in XFree86 4.3.99.14 and later. No need to install any files from 4.2 from this point on if you're using the CVS version.

UPDATE (03/10/03) X driver: Code clean-up.

UPDATE (03/10/05) X driver: Added option "DRI". This option enables/disables DRI (if supported on your hardware). In order to avoid error messages in the log, please remove Load "dri" from your XF86Config[-4]. The driver now loads the DRI module automatically, if needed. sisfb: Fixed important (but not often showing) bug; removed all double and float usage from kernel code. Sync'd mode switching code.

UPDATE (03/10/06) X driver: Implemented some kind of auto-configuration for MergedFB mode; if the MetaModes statement is missing, and/or the Virtual keyword in the Screen section is missing, the driver combines the largest modes for each CRT1 and CRT2 to one single meta mode, and adapts the virtual desktop size to this combined mode. In essence, the only thing you need to do to enable MergedFB mode from now on, is setting the option MergedFB. / Discovered another XAA bug related to color 8x8 pattern fills. Fixed in my libxaa replacements below.

UPDATE (03/10/07) X driver: Disabled TV saturation setting for SiS301. The hardware does not support this.

UPDATE (03/10/08) X driver: Added work-around for DPI problem in MergedFB mode; added MergedDPI option, see here.

UPDATE (03/10/13) X driver: Removed CRT1 sensing, and replaced CRT1 detection by a method that uses DDC2. The old method did not work reliably on many machines, and wrongly detected a CRT1 detection where there was none. The new method has the disadvantage that it only works if the monitor supports DDC2. If your monitor does not, it must either be connected at boot-time, or you need to use the ForceCRT1 option. Until this is fixed in sisfb as well, please use the forcecrt1 parameter for sisfb, otherwise the X driver will fall back to the (wrong) result of CRT1-sensing done by sisfb.

UPDATE (03/10/16) X driver: Fix bug in video overlay handling for CRT1. Fix long-standing dithering bug (made 24bit RGB panels look somewhat dull). Added further support for the 661/M661/741/760 and 301C/LVX.

UPDATE (03/10/18) Fixed a compiler warning in sisfb. Note that the CRT1 detection of sisfb is still broken. However, this is fixed in my development version, but this new version does not work with current 2.6.x kernels because the new framebuffer framework by James Simmons has not been merged into the main line kernel yet. So there is no point in releasing this version here at this time. In case you are using James' 2.6 fbdev kernel tree, sisfb is fixed there. / X driver: Added further support for 661/741/760 and the new video bridges 301C/LVX. Fixed PAL-M support in 1024x768. Hopefully fixed problems on 300 series' 720x576 TV output.

UPDATE (03/10/20) X driver: Further support for 661/741/760. SiS told me that the 661 and 741 are similar to the 650/651/740, ie their core is a 315. The 760 has a Xabre-like GPU core. This knowledge caused some changes. / Can confirm that TV mode 720x576 now works on the 300 series as well. Please test this version intensively and report bugs as soon as possible. I need to commit the code to the XFree CVS for inclusion in XFree86 4.4 very soon.

UPDATE (03/10/22) X driver: Fixed LCD-via-CRT1 on some ECS A928 machines (LCD was missing topmost line). / Added (untested) Xv support for 661/741/760. / Fixed Xv-problems after swsuspend. / Just saw that I accidentally deleted a changelog entry from about a week ago, introducing the MergedFBAuto option. Reinserted the documentation of this options here.

UPDATE (03/10/23) X driver: Hopefully corrected LCD-via-CRT1 for Acer and Compaq machines with 1280x1024 panels, the Clevo L285/287 (1024x768) and the Clevo D4xx (1400x1050).

UPDATE (03/10/24) X driver: Added NTSC-J (Japanese NTSC) support for SiS video bridges. Anyone using this driver in Japan in kindly requested to test this. It should work up to 800x600; 1024x768 might require color adjustments (color calibration). In case you don't get color, please try adjusting the color subcarrier frequency with sisctrl and tell me which values worked. To enable NTSC-J, set the option TVStandard to NTSCJ. SiSCtrl updated to support NTSC-J. Addendum: Added another machine for special handling of LCD-via-CRT1 (Uniwill N35BS1). Renamed the parameters for the option SpecialTiming because the names got too similar recently. Addendum 2: Added (untested) NTSC-J support for Chrontel 7019. Fixed (?) PAL-N support on Chrontel 7019.

UPDATE (03/10/26) X driver: Fix stupid typo (made PAL TV output black & white). SiSCtrl: Added more command line switches upon public demand. Type sisctrl -? for help.

UPDATE (03/10/30) X driver: Fix Xv misbehavior on 315/650/740 in MergedFB mode. Fix handling of interlace modes in "LCD-via-CRT1" mode. Allow interlace modes in single head, non-MergedFB mode (won't be used on CRT2, but allows using them for CRT1). Add two more systems for "LCD-via-CRT1" line shift fixing (topmost scanline missing). Users of Compaq laptops with a 1280x1024 panel are especially encouraged to test this version; I have had reports that the LCD suddenly "shifts" during normal operation, or that it loses sync after a mode switch. That should be fixed. / SiSCtrl: Small fixes.

UPDATE (03/11/03) X driver: Work around a small HWCursor hardware bug in MergedFB mode. Add support for simultanious composite and svideo output (on machines which have both connectors). However, this mode will never be chosen automatically, even if two TV sets are connected at server start. To enable both svideo and cvbs, set the option ForceCRT2Type to SVIDEO+COMPOSITE. Enhanced sisctrl to support this, too.

UPDATE (03/11/06) X driver: Small fixes; Made LCD and VGA2 detection via DDC more robust.

UPDATE (03/11/07) X driver: Added the option AGPSize (alias GARTSize) for selecting the size of the AGP memory buffer in MB used for DRI on the 300 series. If your DRI application quits with a "out of video memory" error, try setting this option to 8, 16, 32, 64 in this order. The valid range is from 8 to 512; the default is 8. If the given number exceeds the size of the AGP aperture (see dmesg output), the default will be used. / Fixed low resolution modes on 300 series if CRT1 is disabled.

UPDATE (03/11/11-1) sisfb: Added support for DirectFB driver, which is currently under development (by DirectFB folks, not by me). Added nomax parameter, see options chapter. Note: This new version of sisfb works only for 2.4 series kernels, and 2.6 series kernels which have been patched with James Simmons's fbdev patch. For vanilla 2.6 series kernels, please use the previous version.

UPDATE (03/11/11-2) X driver: Added separate gamma correction for Xv on CRT1. Please see here for more information. Removed the StoredGammaBrightnessXXX and the corresponding PreBrightnessXXX options in favor for these new options. SiSCtrl updated to support this. / Fixed numerous problems with gamma correction in dual head/Xinerama mode.

UPDATE (03/11/12) sisfb: Fix compile bug.

UPDATE (03/11/18) X driver: Rename "301LVX" to "302ELV" which seems to be the official name. / Tune refresh rates for secondary VGA on 315/330 series. / Further support for 301C video bridge. / Code cleanup. / sisfb: Similar changes.

UPDATE (03/11/19) X driver: Cleaned up mode verification code. Fixed hi-res modes for secondary VGA (some modes with high refresh rates didn't work correctly previously). This requires an update of both sisctrl and the XFree86 driver. Addendum: Fixed serious bug that caused a wrong color palette on CRT2 in dual head mode. Version number not changed, so please update again even if you already did today.

UPDATE (03/11/20) sisfb: Fix compile bug. X driver: Various small fixes and code clean ups.

UPDATE (03/11/22) X driver: Fix MergedFB mode for 1400x1050 panels (1400x1050 was not wrongly disallowed for CRT2 in MergedFB mode) / Re-included EMI code for 302LV/302ELV. This will require a bit of testing; EMI is short for electromagnetic interpherence. The 302LV/302ELV, due to their dual-link capability, require some counter-measures for avoiding EMI. The effects of a wrong EMI setup are, for example, that the panel shows a "comb"-like sync disturbance at the display edges, or loses sync after mode-switches. I herewith urge all users of a machine with a 302LV/302ELV (such as all machines with a LCD panel larger than 1024x768, plus some Clevo L28x with a 1024x768 panel) to test this version and to report problems as described asap. / Fixed 640x480 for 1280x768 Fujitsu panels.

UPDATE (03/11/23) sisfb: Re-include EMI code for 302LV/302ELV. Please update, especially if your machine has a 302LV/302ELV.

UPDATE (03/11/24) X driver: Fix panning in 1400x1050 mode and other modes which horizontal resolutions which aren't a multiple of 16 (showed gargabe at right edge of screen); Disabled loading DRI on chipsets other than 300 series by default (saves users from eventual unresolved symbols).

UPDATE (03/11/29) X driver: Some further EMI fixes (for some Compal machines). Since XFree86 4.4 is going into code-freeze phase really soon (a few days), I urge everybody and especially users of machines with a 302LV to test this version - as it is probably going to be the final version for 4.4.

UPDATE (03/12/02) X driver: This EMI stuff is driving me nuts. Added another EMI fix for Inventec (Compaq 3045US and others) with 1280x1024 panel. Hopefully this will finally do. Added option EMI to make the EMI values user configurable in those rare cases where the BIOS uses wrong or bad ones.

UPDATE (03/12/04) X driver and SiSCtrl: Added RANDR support. SiSCtrl can now not only change the display mode, but also resize your desktop using the X Resize AND Rotate (RANDR) extension. Note: Your window manager must support RANDR, otherwise you may end up with unaccessible windows. This feature requires an update of both the X driver as well as SiSCtrl. Since the RANDR extension is only working in XFree86 4.3 and later, I provide two versions of the pre-compiled SiSCtrl package now. Debian users, who use Debian's experimental XFree86 4.3 packages, MUST use the experimental versions, too, from now; please adapt your /etc/apt/sources.list as described in the download section.

UPDATE (03/12/08) X driver: From now, RandR (Resize and Rotate Extension) is disabled if running MergedFB mode with pseudo-Xinerama; these two didn't really like each other. / Fixed possible sig 11 at server exit in dual head mode.

UPDATE (03/12/09) X driver: Fix VT switching if a custom panel is attached by saving/restoring the registers that contain the LCD info. Addensum: Reversed XV contrast setting. Note: Some video applications like Xine save the contrast (and other settings) in their configuration file and re-load these settings at program start. This update requires resetting the contrast in video applications. For Xine, just delete ~/.xine/config to force xine to read out the default value.

UPDATE (03/12/12) SiSCtrl: Added Xv preview icon for more intuitive Xv (video) setup. This can be disabled with the command line switch -noxvdemo / X driver: Got some reports that the driver has problems on Asus 2500L/H, but so far these people did not provide me with more information. How I am supposed to fix this without the BIOS image or a log is beyond me.

UPDATE (03/12/23) X driver: Hopefully solved the Asus 2xxxH/L problems. / Implemented preliminary support for HiVision and 525i, 525p and 750p YPbPr (HDTV) for SiS661/741/760 and later with a 30xLV/301C bridge. Although older hardware already has supported HiVision for a long time, I have never seen a machine actually featuring connectors for this... A machine with a component connector for YPbPr is yet to be seen. (This feature can't be activated currently; only the code is there).

UPDATE (03/12/24) X driver: Implemented further support for HiVision and YPbPr; this can now be enabled (see updated description of the option ForceCRT2Type), but remember: SiS661/741/760 with 30xLV/301C bridge only. Hm, are this hardware on the market yet? Merry christmas to all of you.

UPDATE (04/01/04) X driver: Updated the license terms, re-licensed under a BSD-like license. All previous licenses revoked for new works.

UPDATE (04/01/06) X driver: Rewrote HWCursor code for 315 and 330 series in order to fix it for the 661/741/760 as well. However, testing results welcome.

UPDATE (04/01/07) X driver: Further fixes for the 661. Console restoring might not work yet, though. HWCursor works, and the machine no longer hangs at log out. That's something for one day... isn't it. Oh yeah, and video seems to work, too.

UPDATE (04/01/09) X driver: HiVision 1080i HDTV output is now supported on all chipsets with a SiS video bridge. However, this feature is entirely untested. Update of SiSCtrl supporting this is on its way.

UPDATE (04/01/12) X driver: YPbPr (HDTV) 525i, 525p and 750p is now supported on the 315/330 series (previously 661 and later only) and the 301C/30xLV. Remember: This is untested. SiSCtrl will be adapted soon.

UPDATE (04/01/14) X driver: Changed the names of the HDTV modes (525i = 480i, 525p = 480p, 750p = 720p), see above. Rewrote BIOS detection code (BIOS looked for using PCIR BIOS header instead of SiS signature; this should prevent the driver from failing to find the ROM on some OEM cards with non-SiS strings). SiSCtrl updated to support HDTV.

UPDATE (04/01/19) X driver/SiSCtrl: Some YPbPr fixes; Added aspect ratio support for YPbPr; proper TV scaling for 301C/302ELV. Both untested. Fixed small Xv bug (very large videos were displayed incorrectly when after switching output devices).

UPDATE (04/01/21) X driver: Put less stress on LCD backlight by making delays between switching it on and off longer (301LV).

UPDATE (04/01/22) sisfb: Updated. Since it does not seem that James Simmons' fbdev stuff is going to be merged to 2.6 anytime soon, the new code is clean of offending code for 2.6.1 (and later) vanilla. The current version of sisfb will therefore not compile if you have applied James' patch.

UPDATE (04/01/23) X driver/sisfb: Fixes for 301C DVI output; Rewrote the PanelDelayCompensation code (has become a chaos recently). Addendum: After conducting a survey on about 10 different PAL TV sets (mainly Philips, Siemens and Panasonic), I changed the default Y position of PAL TV output to the best average. This means that, if you had a custom position set up using SISTVYPosOffset, you'll need to re-adjust this. Furthermore the Y position can now be set twice as exact.

UPDATE (04/01/26) sisfb: Fixed usage of 720x576, 768x576 and 720x480 for TV output. These were not accepted previously by mistake. They are, however, only supported on SiS video bridges.

UPDATE (04/01/26) X driver: Improved RENDER acceleration for 315/330 series (added support for ARGB alpha textures).

UPDATE (04/01/27) X driver: Furtherly improved RENDER acceleration by adding support for source alpha. (Component alpha not yet supported though, but XAA doesn't do that either.)

UPDATE (04/01/31) X driver/sisfb: Add support for very rare machines which use a Trumpion Zurac LVDS scaler (early Clevo notebooks with SiS 630 for example). Addendum: Fixed LCD-via-CRT1 for Clevo D4xx (1024x768).

UPDATE (04/02/06) X driver: Big update: Rewrote LCD-via-CRT1 code to calculate the timing instead of carrying around a lot of data tables. Fixed driver for new BIOS for 661/741/760; SiS folks have changed the data layout in the BIOS resulting in a massive failure of the previous version. Fixed HWCursor on Xabre and 661/741/760 in TV 1024x768 NTSC/PAL-M mode. Added preliminary support for 1280x720, 1280x800 and 1680x1050 LCD panels. Major code-reduction, removed many duplicates, cleaned-up. Testing reports extremely welcome.

Current testing requests:

  • HDTV - If someone has an Asus Digimatrix box and a HD-TV or a projector capable of YPbPr input I'd be grateful for testing results. HDTV (YPbPr) is entirely untested.
  • 661/741/760 support as well as support for the 301C/302ELV video bridge is entirely untested. Reports welcome.
  • All users of machines with a 302LV/302ELV are requested to test mode-switching and to report, if the LCD panel loses sync or shows some other disturbing effects. Do this by cycling though all configured modes often; start and stop X a number of times, switch back and forth from/to the text console, etc. Please attach your video BIOS and the X log to your report.
  • All users of laptops with a 650/M650/651 and a 30xLV video bridge are requested to test LCD-via-CRT1 and report if it works and if all scanlines of the LCD are visible. The easiest way to see if a line is missing, is to move the mouse cursor as far as possibe to the top and bottom of the screen and then switch between CRT2 type "LCD" and LCD-via-CRT1 (using SiSCtrl). The amount of scanlines of the mouse cursor which are visible if the cursor is at the top or bottom of the screen must be identical in both modes. Don't forget to include your X log with your report.
  • Please report if DDC for CRT1 fails to work with your monitor. I have heard of such monitors, but I currently know of no one actually having one of that kind. The usual symptom is that the driver first reports "CRT1 DDC probing failed", but later is able to read the DDC data via the VBE (VESA BIOS extension).
  • Generally, please test as many of the features of the driver as possible. XFree 4.4 is going into code freeze phase very soon.

VI. Download the latest versions

Before downloading the drivers, please consider this:

I have spent far over 2000 hours in developing these drivers since 2001, not counting the numberless hours I spent answering your mails. SiS did not support me in any way (with very few exceptions) and fact is: They make money because of my work - they sell a lot of chips to companies like ECS who even deliver the machines with pre-installed Linux/XFree86 in many cases. Needless to say, ECS and other companies using SiS chipsets in their machines did not support me either.

Considering this, I think it is only fair to expect a little donation from you, the people using this driver and perhaps also making money by using it. Since my apartment is already stuffed with computer hardware, I am in no direct need of hardware donations. From companies selling Linux/XFree86 based machines using my drivers I think a one-time financial contribution in the amount of EUR 100 / US$ 100 is not beyond a reasonable scale. For private usage, I'd welcome a one-time donation in the amount of EUR 11 / US$ 11. In case you agree to this thought, please transfer your contribution to my bank account at BANK AUSTRIA CREDITANSTALT AG, account holder: Thomas Winischhofer, IBAN number AT181200000706360542 (account number 706360542, SWIFT/BIC code BKAUATWW, Bankleitzahl 12000). Or use PayPal: e-mail: thomas@winischhofer.net, type "Service", currency: EC countries EUR, outside of EC US-$. If you use PayPal, please transfer the amount you would like to donate plus EUR 2,-- / US-$ 2 (which PayPal will keep as fee). Thank you.

If you want to keep open source alive in the future, please sign the petition against software patents in Europe. Simply click on the banner above.

For newbies: What you probably want is a binary (=precompiled) XFree86 driver. The "source" of the driver is only required if your system does not work with one of the binary ones (or, of course, if you want to compile XFree86 for yourself; but then again, if you intend to do this, you're certainly no newbie...)

1. My drivers and the SiSCtrl utility
License terms, unless otherwise stated in the source code:

Code which is contained in both the SiS Linux kernel framebuffer driver and the XFree86 driver is dual-licensed. If distributed as part of the Linux kernel, this duplicate code is licensed under the terms of the GPL. Otherwise, the license terms for unique XFree86 driver code, as stated below in italics and in the source code, apply.

The remaining part of the SiS Linux kernel framebuffer driver (which is unique to this driver and does not appear in the XFree86 driver) is licensed under the terms of the GPL only. Its source code contains the respective license terms in each file.

The remaining part of the XFree86 driver (which is unique to this driver and does not appear in the SiS Linux kernel framebuffer driver) is licensed under the following terms (written in italics), unless otherwise stated in the source code:

"Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes software developed by Thomas Winischhofer, Vienna, Austria."
  4. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."

SiSCtrl is licensed under the terms of the GPL version 2 or later.
  • XFree86 driver (pre-compiled) for XFree86
  • X driver source (02/06-1) for XFree86 >= 4.1
  • SiSCtrl (SiS Display Control Panel): A gtk+2 tool for manipulating various driver parameters during runtime (switching the CRT2 type, re-position the TV output, etc). For compilation, it requires the gtk+2.0 and the X11 headers as well as pkg-config. To work correctly, this tool requires an X driver which must not be older than the tool itself. The best way to avoid problems is to update the X driver and sisctrl at the same time. Desktop icons for sisctrl can be found in the source archive (under icons/).
  • Debian users: There are Debian packages available for the XFree86 driver and sisctrl. Add the following to your /etc/apt/sources.list, according to the distribution you use:
    • stable (woody): deb http://www.winischhofer.net/sis/debian/stable ./
    • stable source: deb-src http://www.winischhofer.net/sis/debian/stable ./
    • unstable (sid): deb http://www.winischhofer.net/sis/debian/unstable ./
    • unstable source: deb-src http://www.winischhofer.net/sis/debian/unstable ./
    • experimental: deb http://www.winischhofer.net/sis/debian/experimental ./
    • experimental source: deb-src http://www.winischhofer.net/sis/debian/experimental ./

    Testing (sarge) should work with the unstable versions.

    Users of the experimental XFree86 4.3 packages should use the experimental versions (due to XRANDR support).

    Basically, there are two packages provided: sisxdriver works similar to msttcorefonts: It downloads and installs the (then current) X driver from this website. The package does not contain the driver itself! sisctrl contains the sisctrl utility.

    As for the source, you may want to use apt-src; two packages are provided, sisxdriver and sisctrl. sisxdriver does not contain the X driver source, but the source of the installation package (which will not be useful for you unless you are interested in perl scripts). sisctrl contains the complete source for sisctrl and can be built by invoking debian/rules binary.

    For stable (woody), there is only one "binary" package available: sisxdriver. Since I don't have a system running woody, I cannot provide binary packages for woody otherwise. sisctrl must hence be built from source (or you can try the version for unstable, perhaps it works).

    For unstable (sid) and experimental, sisxdriver and sisctrl are both available as binary and as source packages.

    An old XFree86 SiS driver binary is originally contained in the xserver-xfree86 package. Installing the sisxdriver package will at the same time install a "diversion" of the original SiS XFree86 driver, meaning that an eventual update of xserver-xfree86 will not overwrite the driver installed by sisxdriver.

    If you happen to upgrade to a newer version of Xfree86 (eg. from 4.1 to 4.2, or from 4.2 to 4.3), run dpkg-reconfigure sisxdriver. This will recognize that you are running a different version and download the correct version of the SiS driver automatically.
  • sisfb source (01/31-1) for linux kernels >=2.4.14, >=2.6.1.
2. XFree86 XAA library patch (Recommended)

I discovered a bug in the X server's XAA code (outside the SiS driver), which has been there since before 4.1 - and was never detected until recently. This bug is now more often triggered by the RENDER acceleration, but might show up even without it, for example, after heavy Xv usage. Download the archive for your version of XFree below, extract the archive and copy the file libxaa.a over the old one in /usr/X11R6/lib/modules. Don't forget to do that again everytime you update your X packages! Debian users: Debian's 4.2.1-12 and 4.3.0-pre1v3 versions do not require this patch, previous versions do.

Update 2003/10/06: I discovered another bug in XAA related to 8x8 color patterns. I managed to trigger this bug by starting KDE 3.1.4 with a blue background at 16bpp, but it might occure any time. The result is not a machine crash (like with the bug mentioned above), but drawing errors. So, if you ever experience errors in areas filled with a pattern, update libxaa from the files below. Debian users: 4.3.0-pre1v4 fixes this bug, hence this patch is not needed. The versions of 4.2 which currently are in sid/testing still need it.

3. Other stuff (optional; educational)

VII. Installation

As regards the XFree86 driver, you can choose whether you want to use one of my pre-compiled binaries or compile the driver for yourself. Follow the respective instructions below. As for sisfb, this one can't be pre-compiled, hence you need to rebuild and reinstall your Linux kernel.

  • XFree86 driver pre-compiled binary: [If you use the Debian packages, you can skip this paragraph.] Download the XFree86 driver binary for your version of XFree86. Extract the downloaded archive, ignore eventual "ignoring trailing garbage" warning messages during extraction and copy "sis_drv.o" (which is the only file in the archive) over the existing one which is normally located in /usr/X11R6/lib/modules/drivers/. To find out which "_gcc?_" version you need, open a shell and type gcc -v. If you get "unresolved symbol" errors when starting XFree86, you chose the wrong version. Debian sid/unstable and sarge/testing users need the gcc2 version for XFree86 4.2 despite the fact that gcc 3.3 is the default compiler. XFree86 4.3 is almost always compiled with gcc3.
  • XFree86 driver source:
    • Note 1: The following instructions assume that you have installed binary XFree86 packages and only want to (re)compile sis-related code and not the whole XFree86 environment.
    • Note 2: You need the whole XFree86 source tree to build the SiS XFree86 driver.
    • Extract my source archive to a temporary directory, ie. anywhere but the XFree86 source tree. Ignore an eventual "ignoring trailing garbage" messages during extraction.
    • For 4.1.x, 4.2.x: Copy Imakefile as well as all .c and .h files from that temporary directory over the existing ones inside the XFree86 source tree (programs/Xserver/hw/xfree86/drivers/sis/)
    • For 4.3: Copy all .c and .h files from that temporary directory over the existing ones inside the XFree86 source tree (programs/Xserver/hw/xfree86/drivers/sis/). DO NOT COPY THE Imakefile!
    • Source from XFree.org: cd into the "xc" directory of the XFree86 source tree and run "make World". At first, this will create Makefiles, convert font files and do some other stuff. Then it will start compiling. If you only want to compile the sis driver and not the whole XFree86 environment, you can cancel the building process as soon as sis_dri.so has been compiled.
    • Debian source: cd into the directory where the Debian source code is located (where you see a "debian" and a "build-tree" directory) and run "debian/rules build". At first, this will create Makefiles, convert font files and do some other stuff. Then it will start compiling. If you only want to compile the sis driver and not the whole X environment, you can cancel the building process as soon as sis_dri.so has been compiled.
    • cd into the sis directory (programs/Xserver/hw/xfree86/drivers/sis/), run "make clean" and then "make".
    • Copy the newly generated sis_drv.o from programs/Xserver/hw/xfree86/drivers/sis/ over the existing one. Normally, the file is located in /usr/X11R6/lib/modules/drivers/.
    • For 4.1.x, 4.2.x: Copy the newly generated sis_dri.so in lib/GL/mesa/src/drv/sis/ over the existing one in /usr/X11R6/lib/modules/dri/.
    • To install the sis manpage, gzip the file sis._man, rename the gzipped file to sis.4.gz and copy this file to /usr/X11R6/man/man4/.
  • SiSCtrl: (binary; not Debian package)
    • Download the binary archive and extract it somewhere.
    • Copy sisctrl (which is the only file in the archive) to /usr/X11R6/bin or /usr/bin. It does not really matter.
    • [Eventually create Desktop icons to start SiSCtrl. How this is done depends on the desktop environment you use. Some icon graphics are included in the source archive under /icons.]
  • SiSCtrl: (building from source)
    • Download the source archive and extract it somewhere, for example in /usr/src. Ignore eventual "ignoring trailing garbage" messages during extraction.
    • cd into the directory where you extracted the archive (/usr/src/sisctrl...), and type ./configure - this will check if all necessary tools and library headers are installed. You need the X11 development headers, pkg-config and the gtk/glib 2.x development headers.
    • Type make - this compiles sisctrl into the current directory.
    • Type make install - this installs sisctrl to /usr/local/bin, its manpage into /usr/local/man and some icons to /usr/local/share.
    • Alternate for Debian source package: cd to /usr/src, type apt-get source --compile sisctrl and install the binary package (which is produced during apt-get) from the current directory using dpkg -i sisctrl...._i386.deb.
  • sisfb:
    • You need a complete Linux kernel source tree on your machine.
    • It has come to my attention that RedHat and perhaps some other distros have patched the kernel in a way that makes it impossible to compile my version of sisfb. Bad luck. Use a stock kernel instead. These work well, too.
    • Download the sisfb source archive and extract it somewhere. Ignore eventual "ignoring trailing garbage" messages during extraction.>
    • Don't worry about an eventually empty sis.h file in my archive. This is ok.
    • Read the README file in the archive.
    • For Linux kernel 2.4: Copy the Makefile, all .c and .h files EXCEPT "sisfb.h" over the existing ones in the Linux kernel source tree ([kernel-tree]/drivers/video/sis/)
    • For Linux kernel 2.4: Copy sisfb.h over the existing one in [kernel-tree]/include/linux.
    • For Linux kernel 2.6: Copy all .c and .h files EXCEPT "sisfb.h" over the existing ones in the kernel source tree ([kernel-tree]/drivers/video/sis/). Do NOT copy the Makefile.
    • For Linux kernel 2.6: Copy sisfb.h over the existing one in [kernel-tree]/include/video/.
    • Locate eventual further copies of sisfb.h on your harddrive and replace them with the new file as well.
    • cd to the kernel tree directory, in most cases /usr/src/linux/.
    • Run "make clean". This is important, otherwise the kernel might ignore your startup parameters for sisfb.
    • Then reconfigure the kernel (using for instance "make menuconfig") and enable "Prompt for development and/or incomplete code/drivers" in Code Maturity Level Options, "SiS Acceleration" (along with your type of chipset) in Console Drivers->Framebuffer support. If you happen to select Advanced Low Level Driver Options (which I do not recommend), you *must* select "8 bpp packed pixel support", "16 bpp packed pixel support" and "32 bpp packed pixel support" as well. For 2.6, the options and their names have slightly changed. I am sure you will find them.
    • Run "make dep" (for kernel 2.4 only), then recompile and reinstall the kernel and the modules.

VIII. Contact information

Please observe the following guidelines before posting questions and bugs:

  • Try the most recent drivers; if you are using sisfb and XFree86, update both (even if you think the problem is only one of them)
  • Read this page from top to bottom
  • If your question or report regards sisfb, attach the syslog and tell me which kernel version you use and - in detail - what your problem is.
  • If your question or report is about the XFree86 driver, attach the XFree86 log and XF86Config(-4), and tell me in detail what your problem is; "it does not work" is not sufficient. If the matter is about a mode-switching problem on 300/315/330 series, please include your video BIOS (do
    dd if=/dev/mem of=/tmp/vidbios.bin bs=1 count=65535 skip=786432
    to save it to /tmp/vidbios.bin, and send me that file.)
  • Don't ask me about "why does DRI lock up my machine". If you have followed the installation instructions and DRI still locks up, I don't know. I works on my machine. You can find a few further configuration hints on this page.
  • And for the last time: There is no DRI/OpenGL (hardware accelerated 3D) support for the SiS 315/65x/74x/66x/760.

Don't take me as arrogant but I have more important things to do than explaining the same matter for the 30th time just because folks can't read. Therefore, I will ignore emails that do not follow the guidelines above - with one exception: I really appreciate e-mails telling me that the driver works, too (which also gives me some sort of overview on how many people actually use it).

To contact me, send your mail to thomas@winischhoferXXX.net (but leave that "XXX" out of the address).

BACK