■レンタルサーバご利用参考資料
サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project.
JF は, Linux に関する解説文書・FAQ などを作成・収集・配布するプロジェクトです.
グリーンネット・トップページへ戻る
一覧に戻る
XFree86 Video Timings HOWTO
Eric S. Raymond
Version 4.4, 13 Mar 2000
The Linux JF Project
XFree86 において、お手元のカードやモニタの組み合わせに合わせてモード行
を作成する方法を説明します。現在の XFree86 の配布物は、ほとんどの標準
的な組み合わせに対応して設定できる素晴らしい機能を持っています。した
がって、この文書は主に、モード行を高性能なモニタやとても変わったハード
ウェア向けにカスタマイズして調整したい場合に役立ちます。ま
た、kvideogen を使ってモード行を作る場合や、標準的なモード行がお手元の
モニタにあまり適していない時に xvidtune を使ってモード行を変更する場合
にも役立つかもしれません。
______________________________________________________________________
目次
1. 免責事項
2. はじめに
3. 自動計算のためのツール
4. ビデオディスプレイの動作原理
5. ディスプレイとアダプタについての基礎知識
5.1 モニタの同期周波数
5.2 モニタのビデオ信号帯域幅:
5.3 カードのドットクロック値
5.4 これらの特性は何を制御するのか?
6. 基本仕様の読み方
6.1 帯域幅について
6.2 同期周波数とリフレッシュレート:
7. システムの設定におけるトレードオフ
8. 要求されるメモリ量
9. フレームサイズの計算
10. 黒魔術と同期信号
10.1 水平同期:
10.2 垂直同期:
11. 全体のまとめ
12. モニタの仕様外使用
13. インタレースモードを使用する
14. 質疑応答
15. 画像表示の問題修正
15.1 画像が左か右にずれている場合
15.2 画像が上下にずれている場合
15.3 画像が垂直と水平の両方に膨らんでいる場合
15.4 画像が水平方向に広すぎる(狭すぎる)場合
15.5 画像が垂直方向に膨らんでいる(細くなっている)場合
16. モニタの特性をプロットする
17. 協力者、提供者について
17.1 日本語訳について
______________________________________________________________________
1. 免責事項
この文書の情報はあなた自身の責任においてのみ使ってください。メーカーの
仕様外の使い方をした場合には、モニタとあなた自身の両方に障害を与える可
能性があります。詳細な警告については ``モニタの仕様外使用'' を読んでく
ださい。仕様外の使い方をした場合に読者の皆さんやモニタが受けた被害は、
全て読者の皆さん自身の問題です。
この HOWTO の最新版は Linux Documentation Project
のウェブページにあります。
改良のための率直なご批評、ご批判やご提案は esr@snark.thyrsus.com まで
お願いします。お使いのモニタの特殊な問題について魔法みたいな解決法を期
待する電子メールは送付しないでください。そんなことをしても、私の時間は
無駄になるし、あなたはいらいらするだけです。私の知っていることは全部こ
の文書に書いてあります。
2. はじめに
XFree86 サーバを使用すると、ユーザは自分のビデオサブシステムを設定し
て、既存のハードウェアを最大限に利用できるようになります。この文書の目
的は、ビデオカードとモニタを最適に使用するためのタイミング調節の数値の
作り方を学ぶためのお手伝いをすることです。
この文書では、まず XFree86 サーバを何とか動かすための方法を提示し、そ
れを基礎に実験をしながら、自分の好みに合わせて設定を最適化する方法を説
明します。
だいたい動作するモードが既にある場合(特に、予め設定されている VESA モ
ードが安定しているものの、左右に片寄ったり、小さすぎたり、大きすぎる場
合)には、そのまま ``画像表示の問題修正''の節まで進んでください。この節
を読めば、タイミング値を調整して良い結果を得る方法がわかるでしょう。
X をインストール直後に起動した時に画面が乱れていたからといって、必ずし
もモード調整の必要があると思い込まないでください。出荷時のモード行のほ
とんどは正しく、あなたがデフォルト値として使った値がたまたまハードウェ
アに合わなかっただけかもしれません。ですから、調整を考えるよりも前に、
用意されているモードを CTRL-ALT-KP+ を使って全て順番に試してください。
うまく動作しているように見えるモードがいくつかあれば、640x480 のモード
を除いて全てのモードをコメントアウトし、そのモードが動作するかどうかを
確認します。これが動作したら他のモード(例えば、解像度が 800x600 や
1024x768 で、あなたのモニタが扱えるはずの周波数を持つモードなど)を有効
にします。
他にも便利な方法ができてきました。リリースされたばかりの XFree86 4.0
に入っているドライバの多くは DDC(VESA Display Data Channel 機能)をサポ
ートしています。DDC を有効にすると、モニタは対応しているモード行を実際
に XFree86 に教えます。したがって、XFree86 4.0 と最近のモニタを一緒に
使えば、設定を行う必要はたぶん全くないでしょう。
3. 自動計算のためのツール
PnP 仕様に対応している比較的新しいモニタ(1996 年以降の製品)をお使いで
あれば、edid 読み取りプログラムを使ってモニタに基本特性値を問い合わ
せ、モード行を自動的に計算できる可能性があります。詳しくは
をご覧ください。
バージョン 3.2 以降の XFree86 には、ビデオのタイミング値を直接いじらず
に、動作するモニタのモードを対話的に簡単に作成できる XF86Setup(1) プロ
グラムが付属しています。したがってほとんどの場合、基礎となるモニタのモ
ードを実際に計算する必要はありません。ただし残念ながら XF86Setup(1) に
はいくつかの制限があります。例えば、1280x1024 までの標準的なビデオのモ
ードについてしか情報を持っていません。また、非常に高性能で 1600x1200
以上が使えるモニタを持っている場合はまだ、基礎となるモニタのモードを自
分自身で計算しなければいけません。
KDE には、モニタとカードの基本特性値からモード行を計算する KVideoGen
というツールがあります。筆者
はこれを使ってモード行を作成するテストは行いましたが、そのモード行を実
際に試したことはありません。kvidegen の水平と垂直の「リフレッシュレー
ト(refresh rate)」パラメータは、後述の同期周波数である HSF および VSF
と同じです。「水平同期信号(horizontal sync pulse, HSP)」数は、同期信号
幅をマイクロ秒単位で表したもののようです(このツールでは「フロントポー
チ(front porch)」 HGT1 値と「バックポーチ(back porch)」 HGT2 値は定数
としています)。「水平同期信号」数がわからなければ、デフォルト値を使う
のが安全でしょう。
最近の XFree86 には xvidtune(1) というツールが付属しています。これはモ
ニタのモード行のテストや調整に役立つことがお分かりいただけるでしょう。
このツールは間違えて使った時の結果について恐ろしげな警告を出して起動し
ます。この文書に書かれていることによく注意し、xvidtune のウィンドウに
表示されるたくさんの数値の裏にある意味がわかるようになれば、自信を持っ
て効率的に xvidtune を使えるようになるはずです。
xvidtune(1) を持っている場合、X の設定ファイルを変更せずに、あるいは X
サーバの再起動さえ行わずに、そのままの状態で新しいモードをテストできま
す。xvidtune がなくても、XFree86 では XF86Config ファイルに定義されて
いる複数のモードの間をホットキーを使って移動できます(詳しくは
XF86Config.man を参照してください)。この機能を使って面倒を避けましょ
う! 新しいモードをテストするときは、このモードに固有のラベルを与えて、
ホットキーリストの 最後 に追加してください。新しいモードが動かなかった
ときの保険として、既に動いているモードはデフォルト値のままで残しておき
ましょう。
本文書の終わりの方に `modeplot' 用のスクリプトを載せています。このスク
リプトを使うと、利用可能なモードのアナロググラフを作成できます。これは
モード行の作成に直接役立つわけではありませんが、モード行を定義している
各数値の関係を理解する上で役に立つと思います。
4. ビデオディスプレイの動作原理
ディスプレイの動作原理を知ることは、Xconfig ファイルの色々な場所にどん
な数字を入れるかを理解する上で重要です。これらの値は、 XFree86 サーバ
がディスプレイをハードウェアレベルで制御するのに使用します。
ディスプレイは、ラスタドットの集まりと考えられるものを使って画像を表示
します。このドットを左から右へ並べて線を作ります。そして、この線を上か
ら下へ並べて画像を作ります。ドットはディスプレイ内部で電子ビームを当て
られたとき発光します。それぞれのドットは自分の色を持っています。それぞ
れのドットに均一に電子ビームを当てるために、電子ビームはラスタと呼ばれ
る一定のパターンでディスプレイ上を走査します。
最初に「ドットの集まりと考えられるもの」と書いたのは、これらのラスタ
ドットは実は物理的な発光体のドットと対応していないからです。物理的な発
光体のドットはラスタのドットよりもずっと小さいのです――ラスタのドット
の方が小さくなければなりません。もしそうでなければ、ディスプレイにはモ
アレ効果が出てひどいことになってしまいます。ラスタドットは実際にはドラ
イバから来るアナログ信号をサンプリングしたものであり、これがドットの格
子として表示されるのは、信号の山と谷が非常に規則的であり、かつうまく間
隔が取られているからに過ぎません。
このパターンはスクリーンの左上から始まり、ごくわずかな「下り坂」(この
下り坂は非常に緩やかで人にはわからないくらいです)を下りながら右方向へ
まっすぐにスクリーンを横切ります。そして電子ビームはディスプレイの左端
に戻って新しい線を開始します。新しい線は、最初の線の時と同じようにディ
スプレイを左から右へ走査します。このパターンはディスプレイの一番下の線
を走査するまで繰り返されます。それから電子ビームは(数回画面を往復して
走査しながら)ディスプレイの右下から左上まで移動し、それから最初から全
ての動作を繰り返します。
走査には インタレースと呼ばれる別種類の方法があります。インタレースと
は、最初の半フレームでは一つおきの線しか走査せず、二回目の半フレームで
残りの線を走査するという方法です。
ディスプレイの左上の電子ビームの開始点はフレームの始まりと呼ばれます。
フレームは、電子ビームがディスプレイの右下隅まで届いてから左上隅に再び
戻ってきたときに終了します。フレームはディスプレイの一番上から一番下ま
での全ての電子ビームの線でできています。
もし電子ビームがフレームを移動している間ずっと「オン」だったら、ディス
プレイの全てのドットは点灯してしまい、ディスプレイの縁には黒い部分はな
くなるでしょう。そしてディスプレイの縁では、電子ビームの制御が難しいの
で画像が歪んでしまうでしょう。この歪みを減らすため、ディスプレイの縁の
ドットは、電子ビームが届いても(「オフ」になっているため)ドットが輝かな
いようになっています。ディスプレイの実際に表示される領域が小さくなって
いるのは、こういうわけなのです。
理解すべきもう一つの重要なことは、表示する領域を描画していない時に電子
ビームがどうなっているかということです。ディスプレイの両端を描画するた
めに使われるはずだった時間は、電子ビームを右端から左端まで戻すために使
われます。ディスプレイの上端および下端を描画するためにかかるはずだった
時間は、電子ビームをディスプレイの右下隅から左上隅まで移動させるために
使われます。
アダプタカードは信号を生成し、絵を描くのに使うそれぞれのドットの位置で
(表示させたい色に従って)ディスプレイの電子銃を点灯させます。また、アダ
プタカードは水平同期信号と呼ばれる信号を生成し、電子ビームが右端から左
端に戻るタイミングを制御します。水平同期信号は、全ての行の最後でひとつ
発生します。さらに、アダプタカードは電子ビームをディスプレイの左上隅に
移動させるための垂直同期信号も生成します。垂直同期信号は全てのフレーム
の終わり近くに生成されます。
ディスプレイは電子ビームの位置を安定させるため、水平同期信号と垂直同期
信号の前後に短い時間を必要とします。電子ビームの安定化ができないと画像
が安定しません。
詳しくは TV and Monitor Deflection Systems
のページ
をご覧ください。
後の節では、定義と公式、例題を使えるようにするため、再びこれらの基本事
項に触れます。
5. ディスプレイとアダプタについての基礎知識
Xconfig の設定項目をいじる前に、次の基礎的な事項を知っておく必要があり
ます:
o 使用できるモニタの水平同期信号と垂直同期信号の周波数
o モニタの周波数帯幅
o ビデオアダプタの動作クロック周波数、すなわち「ドットクロック」
5.1. モニタの同期周波数
モニタの水平同期周波数とは、そのモニタが 1 秒間に描ける水平走査線の数
のことで、これはモニタの最も重要な特性です。垂直同期周波数は、そのモニ
タが 1 秒間に電子ビームを縦方向に行き来させられる回数のことです。
同期周波数は普通、モニタのマニュアルの仕様のページに載っています。垂直
同期周波数の数値は一般的に Hz(秒当たりの回数)で、水平同期周波数は
KHz(秒当たりの千回数)で計測されています。通常の範囲は、垂直で 50Hz か
ら 150Hz 程度、水平で 31KHz から 135KHz 程度です。
マルチシンクモニタの場合、その周波数は幅のある値として表示されていま
す。ローエンドの製品に多いのですが、複数の固定した周波数を持っているモ
ニタもあります。このようなモニタも普通のモニタと同様に設定はできます
が、モニタの持つ特性に厳しく制限されてしまうでしょう。できるだけ高い解
像度で、できるだけ高い水平同期と垂直同期周波数の組み合わせを選択してく
ださい。また、固定周波数モニタでは設計値より高い周波数を与えるとモニタ
を傷めるおそれがあるので注意してください。
この文書の初期の版では、マルチシンクモニタの仕様外使用にかなり無頓着で
あり、より良い性能を得るために垂直同期周波数の名目上の最高値を超えさせ
ていました。その後、この状況への警告である、さらに多くの指摘を受けまし
た。後述の ``モニタの仕様外使用'' で説明します。
5.2. モニタのビデオ信号帯域幅:
モニタのビデオ信号帯域幅はマニュアルの仕様に関するページに載っていま
す。これが無かった場合は、モニタの最も高い解像度のところを見てくださ
い。解像度から帯域幅(つまり使用できるドットクロックの大まかな上限値)を
推定するための経験則を以下に示します:
640x480 25
800x600 36
1024x768 65
1024x768 インタレース 45
1280x1024 110
1600x1200 185
ところで、この表に載っているのは謎の数字ではありません。これらの数字
は、 XFree86 標準のモード値データベースから各解像度の最も低いドットク
ロック値を集めただけのものです(最後の値だけは別です。これは外挿して求
めました)。モニタの帯域幅は、一番上の解像度で必要な最低限の帯域幅より
も実際には高いでしょうから、恐れずに数 MHz 高めのドットクロックを試し
てみてください。
また、65MHz あたり以下のドットクロックでは帯域幅はほとんど問題にならな
いことに注意してください。SVGA やほとんどの高解像度のモニタでは、これ
はモニタのビデオ信号帯域幅の限界よりもはるかに低い周波数だからです。以
下に例を示します:
ブランド名 ビデオ信号帯域幅
---------- ---------------
NEC 4D 75MHz
Nano 907a 50MHz
Nano 9080i 60MHz
Mitsubishi HL6615 110MHz
Mitsubishi Diamond Scan 100MHz
IDEK MF-5117 65MHz
IOCOMM Thinksync-17 CM-7126 136MHz
HP D1188A 100MHz
Philips SC-17AS 110MHz
Swan SW617 85MHz
Viewsonic 21PS 185MHz
PanaSync/Pro P21 220MHz
一番下のクラスのモニタでも、解像度に関してビデオ信号帯域幅から厳しい制
約を受けることはありません。NEC Multisync II が良い例です。このディス
プレイは仕様によると 800x600 は表示できず、800x560 しか表示できませ
ん。このような低解像度の場合は、高いドットクロックや大きなビデオ信号帯
域幅は必要ありません。多分 32MHz か 36MHz で十分で、両方の周波数ともモ
ニタの公称のビデオ信号帯域幅である30MHz からそれほど離れた値ではありま
せん。
これら 2 つの動作周波数では、ディスプレイが持っているはずの性能よりも
画面がくっきりと映らないかもしれませんが、それでもかなりの品質だと言っ
てもいいでしょう。もちろん、NEC Multisync II がもっと高い、例えば
36MHz のビデオ信号帯域幅を持っているに越したことはありません。しかし、
大きく画像が歪む程周波数がかけ離れていなければ、文章を編集する等の一般
的な作業には問題はありません。(もし画像の歪みがあまりにも大きい場合に
は、目で見てすぐわかるでしょう)。
5.3. カードのドットクロック値
ビデオアダプタの仕様書には普通、カードの最大ドットクロック値が書かれて
います(ドットクロックとは画面へ 1 秒間に表示できる点の総数です)。
ドットクロックの情報を与えなかった場合は、X サーバが自力でそれを取得し
ます。最近の全ての X サーバ は、X の実際の起動やビデオモードの変更を行
わずにドットクロックの情報の出力だけを行う --probeonly オプションをサ
ポートしています。
-probeonly オプションが無くても気にしないでください。X がモニタを固ま
らせても、クロック値やその他の情報に関する行が標準エラー出力に書き出さ
れます。これをファイルにリダイレクトすれば、たとえコンソールに戻るため
に再起動が必要な場合でも、記録を残すことができます。
検出の結果や起動メッセージは、以下の例のようになります:
XFree86 の場合:
Xconfig: /usr/X11R6/lib/X11/Xconfig
(**) stands for supplied, (--) stands for probed/default values
(**) Mouse: type: MouseMan, device: /dev/ttyS1, baudrate: 9600
Warning: The directory "/usr/andrew/X11fonts" does not exist.
Entry deleted from font path.
(**) FontPath set to "/usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/"
(--) S3: card type: 386/486 localbus
(--) S3: chipset: 924
---
チップセット -- これは正確なチップの種類です。86C911 の前のものです。
(--) S3: chipset driver: s3_generic
(--) S3: videoram: 1024k
-----
ボードに載っているフレームバッファ RAM の大きさ
(**) S3: clocks: 25.00 28.00 40.00 3.00 50.00 77.00 36.00 45.00
(**) S3: clocks: 0.00 0.00 79.00 31.00 94.00 65.00 75.00 71.00
------------------------------------------------------
利用可能な駆動周波数(単位は MHz)
(--) S3: Maximum allowed dot-clock: 110MHz
------
帯域幅
(**) S3: Mode "1024x768": mode clock = 79.000, clock used = 79.000
(--) S3: Virtual resolution set to 1024x768
(--) S3: Using a banksize of 64k, line width of 1024
(--) S3: Pixmap cache:
(--) S3: Using 2 128-pixel 4 64-pixel and 8 32-pixel slots
(--) S3: Using 8 pages of 768x255 for font caching
SGCS や X/Inside の X の場合:
WGA: 86C911 (mem: 1024k clocks: 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71)
--- ------ ----- --------------------------------------------
| | | 利用可能な駆動周波数(MHz 単位)
| | +-- ボードに載っているフレームバッファ RAM の大きさ
| +-- チップの種類
+-- サーバの種類
注意: なるべくこの作業はマシンの負荷が低い時に行なってください。X はア
プリケーションですから、ディスクの動作と時間調節のループが衝突すると、
上記の数字は不正確になります。何回か繰り返し実行し、数字が大きく変動し
ないことを確かめてください。もし変動が大きい場合には、安定するまでプロ
セスを殺してみてください。もしマウスデーモンのプロセスをお使いであれ
ば、これは混乱の元になります(Linux では gpm, SVr4 では mousemgr が該当
します)。
このような不正確さを避けるため、得られたクロックの数字をそのまま
Clocks プロパティの値として Xconfig に取り込んでください。これは時間調
節のループを抑止し、X が試せるクロック値の正確な一覧を与えるためです。
上記の例のデータを使うと、次のようになります:
wga
Clocks 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71
高く変動する負荷がかかるシステムでは、この方法を使うと X の起動の不可
解な失敗を回避する助けになるでしょう。X が起動した時にシステムの負荷の
せいで間違った値を得てしまい、config データベースからちょうどよいドッ
トクロック値を見つけることができなかったり、間違った値を見つけてしまう
ことがあり得るのです。
5.4. これらの特性は何を制御するのか?
モニタの同期信号帯域幅は、ビデオアダプタのドットクロックと共に、表示で
きる最高の解像度を決定します。しかしハードウェアの性能を引き出すのはド
ライバです。どんなに優れたビデオアダプタやモニタでも、良いデバイスドラ
イバがなければ宝の持ち腐れになってしまいます。一方、有能なデバイスドラ
イバがあれば機能の低いハードでも十分役に立ちます。これが XFree86 の設
計哲学です。
使用するドットクロックはモニタのビデオ帯域幅に合わせるべきです。ただ
し、ここはかなり柔軟性がある部分です――モニタによっては名目上の帯域幅
の 30% 増しで動作します。これに伴うリスクは、モニタに記載されている垂
直同期周波数を超えることに関係します。これについては以降で詳しく説明し
ます。
帯域幅を知っていると、可能な設定の中から、より賢い選択ができるようにな
ります。これは、あなたのディスプレイの表示品質(特に高精細のためのシャ
ープさ)に影響するかもしれません。
6. 基本仕様の読み方
この節では上記の仕様の意味と、その他に知らなければならないことを説明し
ます。まず最初にいくつか定義をします。それぞれの隣には、計算をする時に
使う変数名を括弧内に示します。
水平同期周波数(horizontal sync frequency, HSF)
秒あたりの水平走査数 (上記参照)。
垂直同期周波数(vertical sync frequency, VSF)
毎秒の垂直走査数(上記参照)。主にリフレッシュレートの上限として重
要。
ドットクロック値(dot clock, DCF)
より正式には「駆動クロック周波数」だが、適当に「帯域幅」と呼ぶこ
とも。アダプタの発振子または VCO の周波数 --- 毎秒描画可能ドット
数の最大値。
ビデオ信号帯域幅(video bandwidth, VB)
モニタのビデオ入力に送り込んで、何か識別できるものが見えることを
期待できる最大の周波数。アダプタがオン/オフ切り替えのパターンを
生成した場合、最低の周波数は DCF の半分になります。したがって理
論的には帯域幅が意味を持ち始めるのは DCF の 1/2 からです。しか
し、詳細部分が我慢できる程度にくっきりと表示させるには、 DCF の
最高値よりずっと低いとよくないでしょう。できるなら高めにしておき
ましょう。
フレーム長(HFL, VFL)
水平フレーム長(HFL)はモニタの電子銃が 1 つの使われていない左右の
境界を含む水平線を走査するのに必要なドットクロックの数。垂直フレ
ーム長 (VFL)は使われていない上と下の境界を含む完全な画面の走査線
の数です。
リフレッシュレート(screen refresh rate, RR)
秒あたりの画面再描画回数(「フレームレート」とも呼ばれます)。高い
方が良い値で、ちらつきが少なくなります。60Hz は良い値ですし、
VESA 標準の 72Hz ならばなお良いでしょう。以下の計算で求めます:
RR = DCF / (HFL * VFL)
分母にある積はモニタに表示される解像度ではなく、これよりいくらか大
きいことに注意してください。これについては以降で詳しく説明します。
インタレースモードの周波数は普通、実際には半分のフレームの周波数で
(87Hz interlaced のように)指定します: 普通のディスプレイでは画面全
体でちらつきが出るような周波数ですが、全ての単一の線が半分の周期で
しか再描画されません。
計算のため、全フレームの再描画速度(リフレッシュレート)つまり 43.5Hz
でのインタレース表示を考えます。インタレースモードの表示品質は、同
じ全フレームレートの非インタレースモードの表示品質より良好です。し
かし、半フレームレートに対応する非インタレースモードの表示品質と比
べると明らかに劣ります。
6.1. 帯域幅について
モニタのメーカーは帯域幅の高さをよく宣伝文句にします。というのも、帯域
幅が光の強さと色変化のシャープさに制約を与えるからです。帯域幅が大きい
ほど、より細かい画像を表示することができます。
モニタは電気信号を用いて画像を表示します。信号は一度デジタルからアナロ
グへと変換されると、常にアナログ信号として取り扱われます。アナログ信号
は固定周波数の単純な波形をたくさん組み合わせたものと考えられ、それらの
多くは MHz あたりの範囲の周波数、例えば 20MHz、40MHz、さらに 70MHz
だったりします。モニタのビデオ信号帯域幅は、事実上歪みなしに扱える最も
高い周波数領域のアナログ信号です。
私達の目的のためには、ビデオ信号帯域幅は主に使用可能なドットクロックの
おおよその上限として重要です。
6.2. 同期周波数とリフレッシュレート:
画面上の水平走査線はフレーム長走査の中で実際に表示される部分です。それ
ぞれの瞬間に実際に輝いている点はたった一つだけですが、リフレッシュレー
トが十分速ければ、目には絶え間なく全ての画像が「見える」というわけで
す。
ここでいくつかの図で解説します:
_______________________
| | 水平同期周波数は、
|->->->->->->->->->->-> | モニタの電子ビームが
| )| このようなパターンを
|<-----<-----<-----<--- | 走査する、1 秒あたりの
| | 回数です。
| |
| |
| |
|_______________________|
_______________________
| ^ | 垂直同期周波数は、
| ^ | | モニタの電子ビームが
| | v | このようなパターンを
| ^ | | 走査する、1 秒あたりの
| | | | 回数です。
| ^ | |
| | v |
| ^ | |
|_______|_v_____________|
実際のラスタ走査はとても細かいジグザグ型のパターンをしていて、左右に電
子ビームが動いて同時に上下にも動いています。
これで、ドットクロックとフレームの大きさがどのようにリフレッシュレート
に関係しているかが分かります。定義によると、 1 ヘルツ(Hz)は 1 秒に 1
周期です。したがって、水平フレーム長を HFL とし垂直フレーム長を VFL と
した場合に全ての画面を覆うには (HFL * VFL) 回ドットクロックが必要で
す。定義によるとカードからは毎秒 DCF 回の信号が出ているので、モニタの
電子銃が左から右・戻る・下から上へ・戻るという走査を毎秒 DCF / (HFL *
VFL) 回行えるのは明らかです。これがリフレッシュレートです。なぜなら、
これは毎秒あたり何回画面を更新できるか (だからリフレッシュ)を示してい
るからです。
解像度とちらつきの関係がトレードオフの関係にあるので、自分の要求に応じ
て設定を行なうためにこの概念を理解する必要があります。
テキストよりは視覚に訴えた方が分かるので次に関係図を描きます:
RR VB
| min HSF max HSF |
| | R1 R2 | |
max VSF -+----|------------/----------/---|------+----- max VSF
| |:::::::::::/::::::::::/:::::\ |
| \::::::::::/::::::::::/:::::::\ |
| |::::::::/::::::::::/:::::::::| |
| |:::::::/::::::::::/::::::::::\ |
| \::::::/::::::::::/::::::::::::\ |
| \::::/::::::::::/::::::::::::::| |
| |::/::::::::::/:::::::::::::::| |
| \/::::::::::/:::::::::::::::::\|
| /\:::::::::/:::::::::::::::::::|
| / \:::::::/::::::::::::::::::::|\
| / |:::::/:::::::::::::::::::::| |
| / \::::/::::::::::::::::::::::| \
min VSF -+----/-------\--/-----------------------|--\--- min VSF
| / \/ | \
+--/----------/\------------------------+----\- DCF
R1 R2 \ | \
min HSF | max HSF
VB
これは一般的なモニタのモードダイアグラムです。ダイアグラムの x 軸はク
ロック周波数(DCF)、y 軸はリフレッシュレート(RR)を意味しています。ダイ
アグラムで塗り潰してある領域はモニタの表示可能な領域です。この領域のど
の点をとっても表示可能です。
`R1' と `R2' のラベルをつけた線は(640x480 のような)固定解像度を表して
います。つまり、複数の異なるドットクロックとリフレッシュレートの組み合
わせで一つの解像度をどのように実現できるかが図解されています。 R2 の線
は R1 の解像度より高いことを表しています。
許されている領域の上と下の境界線は、垂直同期周波数の限界値を表す単なる
水平線です。ビデオ信号帯域幅はクロック周波数の上限値で、したがって表示
可能な領域の右の境界にあたる垂直な線で表されます。
``モニタ性能をプロットする''には、個々のモニタに対してこのようなダイア
グラム(X graphics ではもっと役に立つでしょう)をプロットするのを助けて
くれるプログラムがあります。その節には興味深い議論もあります。すなわ
ち、水平同期周波数の上限からの境界値の導出です。
7. システムの設定におけるトレードオフ
前に示した公式は、このように変形できます:
DCF = RR * HFL * VFL
つまりドットクロックは固定です。この一秒当たりのドット数は、リフレッ
シュレート、水平解像度または垂直解像度に振り分けられます。これらの数字
のどれかを増やすと、別の数字を減らさなければなりません。
ただし、リフレッシュレートはモニタの最大垂直同期周波数を超えられないの
で注意してください。したがって、あるモニタの、あるドットクロックでは、
フレーム長の積に最小値があり、それより小さくすることはできません。
自分の設定を選ぶ時には覚えておいてください。リフレッシュレートが低すぎ
ると画面のちらつきに泣かされるはめになります。リフレッシュレートは
60Hz 以上にしましょう。VESA の人間工学的な標準値は 72Hz です。蛍光灯の
点滅のレートは 120Hz です。ちらつきに敏感な方は、リフレッシュレートを
これらの値より高くしましょう。
人間の目には慣れがありますし、人間の目のちらつきに対する耐性には個人差
がありますが、ちらつきは大変目に辛いものです。画面の 90% が見える角度
でモニタに向き合い、暗い背景と良いコントラストの色を前景色に使ってい
て、しかも輝度を低から中に調整しているならば、たぶん 45Hz 位に小さくて
も快適でしょう。
厳密なテストのやり方は次の通りです: xterm -bg white -fg black で真っ白
な背景色に黒の前景色の xterm を開いて、表示可能な領域全てを隠すぐらい
の大きさにしてください。そしてモニタの明るさを最大の設定値の 3/4 に設
定して、モニタから顔をそむけて、モニタを横目で覗いてみてください(これ
は、より敏感な視野周辺部の細胞を働かせるためです)。全くちらつきを感じ
ない場合、もしくはちらつきが許せる範囲ならば、あなたにとってそのリフ
レッシュレートはちょうど良い値です。もしそうでなかったら、リフレッシュ
レートをもっと高く設定してください。なぜなら、一見大丈夫なように見えて
も、明らかには分からないようなちらつきによって目がとても疲労して頭痛を
起こすからです。
インタレースモードでは、ちらつきの量は現在の仮想解像度と実際の画面の中
身に依存します。したがって実験が必要になります。半フレームの周波数は
85Hz あたりより低くしないほうがよいでしょう。
以上のようにして、ぎりぎり許容できるリフレッシュレートを選ぶことができ
ました。HFL と VFL の選択においては、多少の作戦を立てる余地があるで
しょう。
8. 要求されるメモリ量
カラーディスプレイやグレースケールディスプレイで実現できる解像度は使用
可能なフレームバッファメモリの量に制限されます。この制限は、2 色 (白
黒)でグレースケールでないディスプレイの場合は多分関係ありません。
256 色のディスプレイの場合は、ビデオメモリのバイト数は表示されるドット
の数だけ必要です。このバイト数は赤緑青から成る集合の点を 1 点とした数
です。必要なメモリ量を得るには、線 1 本当たりに表示される点の数に表示
される線の数を掛けてください。1024x768 の解像度を持つディスプレイの場
合は、ディスプレイに表示する点の数は 1024 x 768 = 786,432 になります。
また、 1 ドットが 1 バイトになるので、アダプタカードに同じバイト数のビ
デオメモリが必要です。
したがって、メモリ量は、一般に (HR * VR)/1024 をキロバイト単位に切り上
げた量が必要です(この例ではちょうど 768K になるでしょう)。例を挙げれ
ば、 (936 * 702)/1024 = 642K バイトとなります。したがって、1M バイトの
メモリがあれば、余った分を仮想スクリーンのスクロールに割り当てられま
す。
ところが、ビデオカードに 512K しかメモリがなければこの解像度は使えませ
ん。良いモニタを持っていたとしても、十分なビデオメモリがなければモニタ
の性能を活かすことはできません。その逆に、SVGA カードが 1M バイトのメ
モリを持っていたとしても、モニタが最高で 800x600 しか表示できないなら
ば、これ以上の高解像度はどうやっても無理というものです(可能な対策につ
いては ``インタレースモードを使用する''を見てください)。
必要量よりもメモリがたくさんあっても心配ありません。XFree86 は余ったメ
モリを利用して表示領域をスクロールできるようにします (仮想スクリーンの
大きさのパラメータに関する Xconfig ファイルの文書を参照してください)。
また、512K バイトのメモリを搭載したカードには 512,000 バイトではなく、
実は 512 x 1024 =524,288 バイトのメモリが搭載されていることを覚えてお
いてください。
S3 カードで X/Inside が動作していて、かつ 16 色(1 ピクセル当たり 4
ビット) の場合、Xconfig ファイルで 深度 4 と設定すれば、カードが扱える
解像度を倍にできます。例えば、S3 カードは通常 1024x768x256(1024x768 の
解像度で 256 色)ですが、深度 4 にすれば 1280x1024x16(1280x1024 の解像
度で 16 色) が使えるようになります。 [訳注: 深度(depth)とは色数やグレ
ースケールを表現するビット数です。]
9. フレームサイズの計算
警告: この方法はマルチシンクモニタのために開発しました。固定周波数のモ
ニタでもこの方法はうまく使えると思いますが保証はできません。
最初に最大の使用可能な HSF で DCF を割って、水平走査可能回数を計算して
ください。
例えば、65MHz のドットクロックの Sigma Legend SVGA カードと、55KHz の
水平走査周波数のモニタを使っていると仮定します。DCF / HSF を計算すると
1181 という量が得られます。
さて、ここでついに黒魔術が出てきます。この式の答えをもっとも近い 8 の
倍数に丸めてください。これは 8 ビットレジスタを持ち、左に 3 ビットずら
して 11 ビットの値を得るような SVGA と S3 の VGA 制御装置において有効
です。 ATI 8514/A のような他のカードではこのような要求はないかもしれま
せんが、我々は正確な知識を持ち合わせてはいませんし、丸めによって不都合
なことが生じることもありません。従って水平走査可能回数を 1176 に丸めま
す。
この数字(DCF / HSF を 8 の倍数に丸めたもの)は最小の HFL として使えま
す。 HSF がもっと低くなるように同期信号を設定すれば、HFL をもっと長く
できます (したがって、多分画面の水平方向のドット数を増やせます)。しか
し、その代わりに速度は遅くなり、目に付くちらつきも増えるでしょう。
経験的な法則では、水平フレーム長の 80% が水平解像度として使用可能で、
水平走査線の表示される部分(これは大体、境界と電子ビームが画面の右端か
ら次の走査線の左端へ戻ってくる時間を差し引いたもの)です。この例で
は、944 になります。
さて、通常の画面のアスペクト比(横縦比)4:3 を得るため、今計算した水平解
像度の 3/4 になるように垂直解像度を設定しましょう。この例では、708 に
なります。実際の VFL を得るには、1.05 を掛けて 743 になります。
4:3 という比率は技術的な魔法ではありません。別の比率を使う方が画面の表
示部分をうまく使えるのであれば、この値にこだわる理由はありません。これ
を使うとフレームの高さとフレームの幅を対角線の長さから求めるのが簡単に
なります。つまり対角線の長さに 0.8 を掛けた値が幅であり、0.6 を掛けた
値が高さです。
結局、HFL=1176 と VFL=743 としました。65MHz をこの 2 つの数字の積で割
ると、十分に高くて健康に良い 74.4Hz のリフレッシュレートが得られます。
素晴らしい! VESA 標準より立派でしょう! おまけに、おそらく予想していた
800x600 よりも高い 944x708 という解像度が得られたのです。本当に素晴ら
しい!
さらに(大体 76 Hz まで)リフレッシュレートを改良することも可能です。こ
れには、定格よりも 2 KHz くらい高い水平同期周波数でも動くモニタが多い
という事実と、VFL を幾らか下げる(つまり、上の例で言うと 944 の 75% よ
りも小さくする)ことを利用します。しかしこの「オーバードライブ」作戦を
試してみる前に、あなたのモニタの電子銃が垂直同期を 76 Hz 以上にできる
ことを確認してください。(例えば、人気のある NEC 4D ではこれはできませ
ん。これは 75 Hz までの VSF しか使えません。)
以上が、ラスタ表示についての単純な計算と基本的事項のほとんど全てです。
黒魔術というほどのものでもないですね!
10. 黒魔術と同期信号
さあ、自分で選んだドットクロック対応に計算した HFL/VFL の数字があり、
無難なリフレッシュレートが見つかり、十分な VRAM(ビデオメモリ)があるこ
とを確認しました。これからが本当の黒魔術です ―― いつどこで同期信号を
出すかを知る必要があります。
同期信号が実際にモニタの水平及び垂直の走査周波数を制御しています。仕様
表から引っぱり出してきた HSF と VSF は定格上の最大同期周波数の推定値で
す。アダプタカードからの信号の中の同期信号はモニタにどれくらい速く実際
に動作するか伝えます。
上記の 2 つの絵を思い出してください。目に見える画像(あなたの選んだ解像
度) を表示するために使われるのは、フレームをラスタ走査するために必要な
時間の一部だけです。
10.1. 水平同期:
前の定義によれば、 1 本の水平走査線をたどるのには HFL 分の時間掛かりま
す。表示される部分のクロック回数(水平スクリーン解像度)を HR と呼びま
しょう。その時は明らかに、定義から HR < HFL となります。具体的に両方が
同時に開始したと仮定して次に示します:
|___ __ __ __ __ __ __ __ __ __ __ __ __
|_ _ _ _ _ _ _ _ _ _ _ _ |
|_______________________|_______________|_____
0 ^ ^ 単位: 水平クロック
| ^ ^ |
HR | | HFL
| |<----->| |
|<->| HSP |<->|
HGT1 HGT2
ここで、上にあるように表示データのクロック終了とフレーム全体のクロック
終了の間に HSP の同期信号長を配置します。何故そうするのか？ それはこう
すると、画面表示が左右に移動しなくなるからです。表示をスクリーン上で表
示されるべき場所、つまりモニタの表示可能領域内にきっちりと収めるためで
す。
その上、同期信号の両側に "保護時間" として約 30 クロック必要です。HGT1
と HGT2 で表わしています。一般的には HGT1 は HGT2 と等しくありません
が、しかし真っさらの状態から設定を行うならば、2 つを等しくして実験を始
めたら良いでしょう(それは同期信号を中央に置くことになります)。
同期信号の置き違えの症状は、1 つの境界が極端に広くなって画像の他の側が
画面の端から回り込んだり、白い端の線と"お化け画像"の帯になったり、画面
の画像表示のずれとして現われます。垂直同期信号抜けは垂直保持が調節不備
になっている TV のように実際に縦スクロールします(事実、同じ現象が起こ
ります)。
幸運ならば、モニタの同期信号の幅がその仕様書に記載されているでしょう。
記載がなければ、本当の黒魔術を始めることになります…。
ここでは少し試行錯誤を行う必要があるでしょう。しかしほとんどの場合に
は、同期信号を約 3.5 から 4.0 マイクロ秒と仮定すれば安全です。
具体的には、HSP を 3.8 マイクロ秒にしましょう(この値は実験を始めるに当
たっては悪い値ではありません)。
さて、先ほど 65MHz をクロックに使いましたから、HSP を 247 クロック分と
等しくすればよいことがわかります。( 247 = 65x10**6 * 3.8 *10**(-6))
[メガ=10**6, マイクロ=10**(-6) である事を思い出してください]
メーカーによっては、ドット幅ではなく水平方向のフレームパラメータを好ん
で使います。次の用語をご覧ください:
稼働時間(active time, HAT)
ミリ秒に換算した HR に相当。HAT * DCF = HR
空白時間(blanking time, HBT)
ミリ秒に換算した (HFL - HR) に相当。HBT * DCF = (HFL - HR)
フロントポーチ(front porch, HFP)
まさしく HGT1 です.
同期時間(sync time)
まさしく HSP です。
バックポーチ(back porch, HBP)
まさしく HGT2 です.
10.2. 垂直同期:
前の絵に戻って、247 クロック分を絵の中でどのように置いたらいいでしょ
う?
この例では、HR は 944 で HFL は 1176 です。この 2 つの例の差は
1176-944=232 < 247です! 明らかにこの違いを調整しなければいけません。何
ができるでしょうか?
最初に 1176 は 1184 へ上げて、 944 は 936 へ下げてください。これで違い
が 1184-936= 248 になりました。うん、近づいてきましたね。
次は HSP を計算するのに 3.8 の代わりに、3.5 を使うようにすると、
65*3.5=227 となります。かなり良くなりました。しかし 248 は 227 よりそ
れほど大きくありません。HR と SP の開始点の間と SP の終了点と HFL の間
に 30 かそれぐらいあける必要があります。そして、それらは 8 の倍数にし
なければなりません! 我々はここで行き詰まってしまったのでしょうか?
いいえ、こうしてみましょう。936 % 8 = 0 ですし、 (936 + 32) % 8 = 0 で
す。しかし、936 + 32 = 968, 968 + 227 = 1195, 1195 + 32 = 1227 となり
ます。ふむふむ、そんなに悪くはありません。しかし、8 の倍数にはなってい
ないので、1232 に丸めてください。
しかし、同期信号を HR と HFL のちょうど真ん中に置けない問題が起こる可
能性があります。幸いにも、1232 - 32 = 1200 も 8 の倍数であることと、
(1232 - 32) - 968 = 232 は 3.57 マイクロ秒という妥当な長さの同期信号に
対応することが計算でわかります。
さらに、 936/1232 は大体 0.76 つまり 76%ですが、80% からそう遠くないの
でまあ大丈夫でしょう。
その上、現在の水平フレーム長を使うなら、基本的にはモニタがその能力内で
52.7KHz(=65MHz/1232)において同期が取れるかどうか調べましょう。問題は無
いでしょう。
経験則から、上記の 936*75%=702 を新しい垂直解像度にしましょう。
702*1.05=737 が新しい垂直フレーム長になります。
画面のリフレッシュレートは 65MHz/(737*1232)=71.6 Hz になります。それで
も十分素晴らしい値ですね。
同様に垂直同期信号の配置を図解します:
|___ __ __ __ __ __ __ __ __ __ __ __ __
|_ _ _ _ _ _ _ _ _ _ _ _ |
|_______________________|_______________|_____
0 VR VFL 単位: 垂直クロック
^ ^ ^
| | |
|<->|<----->|
VGT VSP
垂直表示データの終了時きっかりに同期信号を発信します。VGT は同期信号の
垂直保護時間です。ほとんどのモニタは VGT なし(保護時間なし)で快適に動
作し、例題でも保護時間なしです。2,3 クロックの保護時間が必要なものもあ
りますが、保護時間を入れて不都合が生じることは普通ありません。
例題に戻りましょう: フレーム長の定義から、垂直クロックは全水平フレーム
を辿る時間ですので、例題では 1232/65MHz=18.95 マイクロ秒になります。
実験によれば垂直同期のパルス幅は 50 マイクロ秒から 300 マイクロ秒の範
囲に設定すべきです。例題では 8 垂直クロック分、150 マイクロ秒を使用し
ます (150 マイクロ秒 / 18.95 マイクロ秒 8)。
メーカーによっては、ドット幅ではなく垂直方向のフレームパラメータを好ん
で使います。次の用語をご覧ください:
稼働時間(active time, VAT)
ミリ秒に換算した VR に相当。VAT * VSF = VR
空白時間(blanking time, VBT)
ミリ秒に換算した (VFL - VR) に相当。VBT * VSF = (VFL - VR)
フロントポーチ(front porch, VFP)
まさしく VGT です。
同期時間(sync time)
まさしく VSP です。
バックポーチ(back porch, VBP)
垂直同期信号の後の第 2 保護時間に似ています。しばしばゼロです。
11. 全体のまとめ
Xconfig ファイルのビデオモード(Video Modes)表は数行の数列でできてい
て、それぞれの行は X サーバが使用する 1 つのモードの完全な仕様を表わし
ています。その項目は名称セクション、ドットクロックセクション、水平セク
ション、垂直セクションの 4 つのセクションに分けられます。
名称セクションは 1 項目からなり、その行の残りでビデオモードの名称を指
定します。この名称は、Xconfig ファイルのグラフィックスドライバ設定セク
ションの "Modes" 行から参照されます。現在の行が前の行と同じ名称ならば
名称は省略できます。
ドットクロックセクションには、ビデオモード行の項目に DCF と呼んでいた
ドットクロックのみを書きます。次のセクションで作成する数字をドットク
ロックとしてこの項目に書きます。
水平セクションは 4 つの項目を含み、それぞれの水平線を画面の上でどのよ
うに作成するかを記述します。最初の項目は、光を発して映像を構成する線に
ついて、線ごとのドット数を示します(今まで HR と呼んでいたものです)。 2
番目の項目(SH1)はどのドットから水平同期信号が始まるかを示します。 3 番
目の項目(SH2)はどのドットで水平同期信号が終わるかを示します。 4 番目の
項目は全水平フレーム長(HFL)を指定します。
垂直セクションも 4 項目からなります。最初の項目には画面上に表示される
走査線の数を書きます (VR)。 2 番目の項目(SV1)には垂直同期信号が何番目
の線から始まるかを書きます。3 番目の項目(SV2)には垂直同期信号が何番目
の線で終わるかを書きます。 4 番目の項目には全垂直フレーム長を書きま
す(VFL)。
指定例:
#Modename clock horizontal timing vertical timing
"752x564" 40 752 784 944 1088 564 567 569 611
44.5 752 792 976 1240 564 567 570 600
(注意: 標準的な X11R5 そのままでは 小数のドットクロックは使えません。)
Xconfig では、線上で輝いているドットの数、輝いているドットから同期信号
の開始点までのドット数、同期信号の持続時間分のドット数と同期信号の終了
点から後のドット数、これらを足し合わせると 1 本当たりのドット数が計算
できます。水平方向のドット数は一律に 8 で割り切れる数値でなければいけ
ません。
水平方向の数値の例: 800 864 1024 1088
この例の数字は順に、輝いているドット数(800)、同期開始点のドット(864)、
同期終了点のドット(1024)、水平線の最後のドット(1088)となります。
全ての水平方向の数字(800, 864, 1024, 1088)は 8 で割り切れる事にもう一
度注意してください。これは垂直方向の数字には当てはまりません。
画面の上から下までの線の数がフレームを構成します。フレームの基本的な時
間調整は線で行ないます。線の多くは画像を表示するために使われます。最後
の発光する線を表示した後で、数本分遅延が挿入され、その後垂直同期信号が
生成されます。そして同期信号は数本分だけ持続し、フレームの最後に同期信
号の後で必要な遅延が生成されます。この動作モードを規定する数値は、次の
例のように入力します。
垂直方向の数値の例: 600 603 609 630
この例はディスプレイに 600 本の線が表示され、603 番目の線から垂直同期
が始まり 609 番目で終わる事、そして全部で 630 本の線を使用することを表
わしています。
垂直方向の数値は 8 で割り切れる値でなくても構いません。
例題に戻りましょう。上記によって、Xconfig へ書き込む必要な全ての値は以
下のようになります:
DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
ここで SH1 は水平同期信号の開始クロックで、SH2 はその終了クロックにな
り、同様に SV1 は垂直同期信号の開始クロックで、SV2 はその終了クロック
です。
ここで、前述の「黒魔術と同期信号」の章の説明を思い出してください。SH1
は 水平同期信号の先頭側の端で始まるドットです。したがって SH1 = HR +
HGT1 です。SH2 は末尾側の端です。したがって SH2 = SH1 + HSP です。同じ
ように、SV1 = VR + VGT (ただし VGT は普通は 0 です)、SV2 = SV1 + VSP
です。
#name clock horizontal timing vertical timing flag
936x702 65 936 968 1200 1232 702 702 710 737
特別なオプションは必要無く、これはノンインタレースモードで動作します。
これで完了しました。
12. モニタの仕様外使用
固定周波数型のモニタの場合、モニタの規定走査周波数を超えては絶対にいけ
ません。これをやってしまうと機器から煙が出てくるかもしれません! マルチ
シンクモニタでも、周波数を上げすぎると些細ながらいろいろな問題が出る可
能性がありますので、注意してください。
その逆に、モニタの最高周波数帯域より高いピクセルクロックを使っても比較
的安全です。問題を起こしやすいのは決められている最大同期周波数を超える
ことです。最近のモニタの中には走査周波数が危険な値だとモニタを消す保護
回路を装備しているものもありますが、これを過信してはなりません。特に、
水平同期用のトランスを一つしか持っていない(Multisync II のような)古い
マルチシンクモニタもあります。これらのモニタには仕様外使用に対する防御
機構はあまりありません。高電圧安定回路は確実に備わっていますが(固定周
波数のモニタにはないことがあります)、特に安いモニタでは、必ずしも考え
られる全ての周波数帯域がカバーされているとは限りません。このため、電子
回路が早く傷むだけでなく、画面の発光体も早く傷み、規定以上の(X 線を含
む)放射線がモニタから放出されることになります。
しかしながら、ここで問われている根本的な問題はビデオ出力ドライバ回路の
スルーレート(ビデオ信号の立ち上がりの傾斜)です。このスルーレートは実際
のピクセル周波数と普通は無関係ですが、(ボードのメーカーがこのような問
題に注意を払っていれば)ボードの最大ピクセル周波数と関係があります。
これらに注意しつつ作業をしましょう…。
13. インタレースモードを使用する
(この節はほとんど David Kastrup
によります)
固定のドットクロックでは、モニタの垂直同期回路が安定してサポートできる
なら、ノンインタレース画面よりもインタレース画面の方が目につくちらつき
がかなり少なくなります。インタレースモードが最初に開発されたのは、この
ためです。
インタレースモードは、同じ垂直走査周波数 すなわちVSF(通常広告に良く使
われています) のノンインタレースモードの同等品より劣るという悪評をかっ
ていました。しかし、インタレースモードは同じ水平走査周波数では確実に優
れていて、普通はそこでモニタやグラフィックスボードの明白な限界が見えて
くるものです。
固定のリフレッシュレート(すなわちフレーム周波数の半分、つまり VSF)で
は、インタレースのディスプレイはちらつきがより多く見えます。例え
ば、90Hz のインタレース表示は 90Hz の非インタレース表示より劣ります。
しかし、半分のビデオ信号帯域幅と半分の水平走査速度で済みます。同じドッ
トクロックと同じ走査速度でノンインタレース表示と比べたら、インタレース
表示の方がずっとよく見えるでしょう。45Hz の非インタレース表示などは、
お話になりません。私は、90Hz のインタレース(1024x768)で Multisync 3D
を何年も使っており、たいへん満足しています。同様な快適さを得るために
は、最低 70Hz の非インタレース表示が必要だと思います。
注意が必要なこともいくつかあります。インタレースモードは高解像度でだけ
使って、一本おきの輝線がお互いに近くなるようにします。最も安定した線の
位置を得るために、同期信号の幅と位置をいじる必要があるかもしれません。
一本おきに線が明暗すると、インタレース表示はぎらぎらして見えます。私
は、メニューの背景にそのようなドットパターンを選んだアプリケーションを
一つ持っています(XCept, 幸いなことに他の私の知っているアプリケーション
ではこのようなことをするものはありません)。私は、XCept を使うときには
800x600 に切り替えます。というのも、そうしないと目を痛めてしまうからで
す。
同じ理由で、最低 100dpi のフォントを使うこと、または他のフォントでも水
平方向の線に最低 2 行分の厚みがあるフォントを使いましょう(高解像度の場
合には、他のどんな方法でもだめでしょう)。
そしてもちろん、同じようなリフレッシュレートで非インタレースモードをサ
ポートしている機器の時は、決してインタレースモードを使ってはいけませ
ん。
しかしながら、もしある解像度でモニタかグラフィックスカードのどちらかの
上限に達してしまって不快なちらつきや色落ち(帯域幅を超えた時)表示が起
こったと思ったら、同じ解像度でインタレースモードを試してみるといいかも
しれません。もちろん、これはモニタの VSF がすでに上限に近い場合は使え
ません。
インタレースモデルの設計は簡単です。ノンインタレースモードと同じように
考えましょう。2 つだけ追加の検討が必要です。まず、垂直線の総数 (モード
行の最後の数値)を奇数にしなければなりません。次に、"interlace" フラグ
を指定した時、モニタに対する実際の垂直フレーム周波数が倍になることで
す。指定したモードが 45Hz のモードに見えるなら、"Interlace" フラグはさ
ておいて、モニタは 90Hz のフレーム周波数をサポートする必要があります。
例えば、1024x768 のインタレースモードのモード行の場合です。 Multisync
3D は 90Hz の垂直フレーム周波数と 38kHz の 水平フレーム周波数までサポ
ートします。
ModeLine "1024x768" 45 1024 1048 1208 1248 768 768 776 807 Interlace
両方のリミットは、このモードではほぼ限界です。同じモードを "Interlace"
オプションをつけないで指定しても、既にモニタの水平方向の能力のほとんど
上限です(厳密に言えば、垂直走査周波数の下限を少し下回ります)。しかし、
耐えられないほどのちらつきを生じます。
基本的な設計ルールです。モニタの垂直容量の半分以下でのモード設計したこ
とがあれば、垂直方向の線の合計を奇数にして "Interlace" オプションを追
加しましょう。ほとんどの場合、ディスプレイの品質は非常に向上するはずで
す。
モニタの最大以下の垂直走査周波数より 30% ほど低い垂直走査周波数で、モ
ニタの仕様を上回らないように、止むを得ずノンインタレースモードを使って
いる場合は、インタレースモードを手作りで設計すると(多分、いくぶん高い
解像度で)よりよい結果を得ることができるかもしれませんが、約束はできま
せん。
14. 質疑応答
Q. この文書の例は標準的な画面サイズではありませんが、使えますか？
A. 勿論です。640x480, 800x600 とか 1024x768 を使わなければならない理由
は全くありません。XFree86 のドライバはハードウェアを自由に設定できるよ
うになっています。普通は 2, 3 回試してみれば正しい設定を見つけられま
す。目指すべき重要なことは、高いリフレッシュレートで妥当な表示領域とな
ることです。涙目を誘うちらつきを代償にして高解像度を追求しないように!
Q. 65MHz のドットクロックと 55KHz の HSF で得られる解像度はこれだけで
すか？
A. 絶対そんなことはありません! 一般的な手順に従って作業を行い、本当に
好みの設定にたどり着くため、若干の試行の繰り返しをお勧めします。 実験
してみると結構楽しいものです。 ほとんどの設定ではビデオ表示が乱れてし
まうかもしれませんが、経験上最近のマルチシンクモニタは普通、簡単には壊
れません。しかし、長時間モニタを使う前に、モニタがあなたのモードのフレ
ーム周波数をサポートしていることを確認しましょう。
固定周波数のモニタには注意してください。この手のいじくりまわしは、モニ
タを結構早く傷めることがあります。実験するときは毎回有効なリフレッシュ
レート使っていることを確認しましょう。
Q. 二つの標準的な解像度を記載してますね。Xconfig の中では色々標準的な
解像度がありますが、時間調節の数値を調整する場合のポイントを教えてくだ
さい。
A. 勿論教えましょう! 現在の Xconfig にある「標準的」な640x480 を例題に
取り上げます。この場合、動作周波数が 25MHz 、フレーム長が 800 と 525
の時に約 59.5Hz の画面リフレッシュレートが使えます。 悪く無いでしょう?
しかし、28MHz は一般的に多くの SVGA ボードで使える動作周波数です。
28MHz で 640x480 を使う場合、以前に説明した手順に従えば、フレーム長は
812(808 に丸められます)や 505 が得られるでしょう。ここでリフレッシュレ
ートは 68MHz まで引き上げられ、標準値よりもずっと良い値になります。
Q. 今までの議論をまとめてもらえますか?
A. 要約します:
1. 任意の固定の動作周波数では、最高の解像度に高めればリフレッシュレー
トを下げなければならず、したがってちらつきが増えるでしょう。
2. 高解像度を希望しモニタがそれをサポートするときは、それに合うドット
クロック、つまり DCF を供給する SVGA カードを手に入れてください。
ドットクロックは高いに越したことはありません。
15. 画像表示の問題修正
さあ、 X の構成定義の数値を手に入れました。XF86Config に その数値をテ
スト中のコメントをつけて書きました。X を立ちあげ、ホットキーで新しいモ
ードに切り替えてみました…しかし画像が変です。こういう場合、どうすれば
いいのでしょう？ 一般的なビデオ画像歪みの問題と解決策をここに挙げま
す。
(小さな歪みの修正において xvidtune(1) が秀でています。)
同期パルスを調整して画像を移動してみてください。フレーム長を変えて画像
を拡大・縮小してください(相対的な位置をそのままに同期信号を移動する必
要があります。そうしないと拡大縮小と同時に画像の移動も起こってしまいま
す)。もう少し個別の対処方法を次に示します:
水平と垂直の表示位置は独立しています。これは画像を水平に移動させても垂
直位置には影響がなく、また逆も同じということです。ところが拡大・縮小で
は必ずしもそうではありません。水平方向の大きさを変えても垂直方向の大き
さには何も影響を与えず、逆も同じですが、縦横両方の変更量の合計は限定さ
れています。特に、縦横に大き過ぎた場合はより高いドットクロックに変更し
て修正する必要があるでしょう。使用可能な解像度を引き上げることになるた
め、これはめったに問題とはなりません。
15.1. 画像が左か右にずれている場合
これを修正するために水平同期信号を移動しましょう。すなわち、水平同期信
号の開始端と終了端を定義している水平調整部分の真ん中の 2 つの数値を (8
の倍数ずつ)増減させて行います。
画像が左にずれている(右の縁の部分が大きすぎて、右へ画像を移動したい)
時は、数値を増やしてください。画像が右にずれている(左の縁の部分が大き
すぎて、左へ画像を移動したい)時は、同期信号を減らしてください。
15.2. 画像が上下にずれている場合
これを修正するために垂直同期信号を移動してください。すなわち、垂直同期
信号の開始端と終了端を定義している垂直調整部分の真ん中の 2 つの数値を
増減させて行います。
画像が上にずれている(下の縁の部分が大きすぎて、下に画像を移動したい)
時は、数値を減らしてください。画像が下にずれている(上の縁の部分が大き
すぎて、上へ画像を移動したい)時は、数値を増やしてください。
15.3. 画像が垂直と水平の両方に膨らんでいる場合
より高いカードクロックに切り替えましょう。クロックファイルに複数のモー
ドがある場合、低い方の速度のモードに間違って作動させている可能性があり
ます。
15.4. 画像が水平方向に広すぎる(狭すぎる)場合
これを修正するためには水平フレーム長を増やし(減らし)てください。すなわ
ち、最初の調整部分の 4 番目の数値を変えて行います。画像が移動するのを
回避するため、同期信号(2 番目と 3 番目の数値)もその半分だけ移動し、同
じ相対位置を保存しておいてください。
15.5. 画像が垂直方向に膨らんでいる(細くなっている)場合
これを修正するためには垂直フレーム長を減らし(増やし)てください。それは
2 番目の調整部分の 4 番目の数値を変えて行います。画像が移動するのを回
避するため、同期信号(2 番目と 3 番目の数値で)もその半分だけ移動し、同
じ相対位置を保存しておいてください。
これらの技術の組合せでも取れない他の歪みは多分もっと基本的な部分が違っ
ている、例えば計算違いとかモニタで使えない高いドットクロックを使ってい
るような場合があります。
最後に、フレーム長のどちらかの数値を増やせばリフレッシュレートが低下し
てしまうこと、またその逆も言えることを覚えておいてください。
小さな歪みはモニタの画像制御をいじれば直ることもあります。この方法の短
所は、グラフィックスモードの問題を直すために自然な設定(工場出荷時の設
定)から離れすぎてしまうと、テキストモードの画面が変になってしまうこと
です。したがって、モード行を正しくする方がいいでしょう。
16. モニタの特性をプロットする
モニタモードダイアグラムをプロットするには、gnuplot パッケージ(UNIX の
ようなオペレーティングシステム用のフリーウェアのプロット言語)とコマン
ドラインから入力したモニタの特性から gnuplot で ダイアグラムをプロット
する shell スクリプトである modeplot ツールが必要です。
modeplot のリストを示します:
#!/bin/sh
#
# modeplot -- generate X mode plot of available monitor modes
#
# Do `modeplot -?' to see the control options.
#
# Monitor description. Bandwidth in MHz, horizontal frequencies in kHz
# and vertical frequencies in Hz.
TITLE="Viewsonic 21PS"
BANDWIDTH=185
MINHSF=31
MAXHSF=85
MINVSF=50
MAXVSF=160
ASPECT="4/3"
vesa=72.5 # VESA-recommended minimum refresh rate
while [ "$1" != "" ]
do
case $1 in
-t) TITLE="$2"; shift;;
-b) BANDWIDTH="$2"; shift;;
-h) MINHSF="$2" MAXHSF="$3"; shift; shift;;
-v) MINVSF="$2" MAXVSF="$3"; shift; shift;;
-a) ASPECT="$2"; shift;;
-g) GNUOPTS="$2"; shift;;
-?) cat <" name of monitor defaults to "Viewsonic 21PS"
-b bandwidth in MHz defaults to 185
-h min & max HSF (kHz) defaults to 31 85
-v min & max VSF (Hz) defaults to 50 160
-a aspect ratio defaults to 4/3
-g "" pass options to gnuplot
The -b, -h and -v options are required, -a, -t, -g optional. You can
use -g to pass a device type to gnuplot so that (for example) modeplot's
output can be redirected to a printer. See gnuplot(1) for details.
The modeplot tool was created by Eric S. Raymond based on
analysis and scratch code by Martin Lottermoser
This is modeplot $Revision: 1.7 $
EOF
exit;;
esac
shift
done
gnuplot $GNUOPTS < が書きまし
た。
Eric S. Raymond は、Chin Fang の元文書を分かり
やすくするために改訂と再編成、大幅な書き直しを行いました。この過程
で、Bob Crosson による別の HOWTO 文書の大部分を
取り込みました。
インタレースモードに関する資料は主として David Kastrup
によります。
Nicholas Bodley はディスプレイの動作に
関する章の訂正と整理をしてくれました。
Payne Freret はモニタの設計に関する小さな技術的な誤
りを訂正してくれました。
Martin Lottermoser は gnuplot を用いて
モードダイアグラムを作画するというアイディアを提案し、 modeplot の背景
にある数学的な解析を行いました。配布されている modeplot は、ある場合に
ついて書いた Martin のスクリプトを元に、ESR が再設計と一般化を行いまし
た。 [訳注: ESR とは Eric S. Raymond のことです。]
17.1. 日本語訳について
現在のバージョンは、岡本一幸さんと Hiro Sugawara さんの訳を元に Linux
Japanese FAQ Project が更新を行いました。翻訳に関するご意見は JF プロ
ジェクト 宛に連絡してください。
改訂履歴を以下に示します。
v3.0, 9 September 1997
翻訳:
o 岡本一幸
o Hiro Sugawara
コメント: 山崎康宏
v3.6j, 20 November 1999
翻訳: 藤原輝嘉
v4.1j, 21 January 2000
更新: 藤原輝嘉
v4.2j, 26 Feburary 2000
更新: 藤原輝嘉
v4.4j, 18 March 2000
更新: 藤原輝嘉
一覧に戻る
グリーンネット・トップページへ戻る
|
