XFree86 Video Timings HOWTO <author>Eric S. Raymond <esr@thyrsus.com> <date>Version 4.4, 13 Mar 2000 <trans>The Linux JF Project <JF@linux.or.jp> <date>Version 4.4j, 18 Mar 2000 <abstract> <!--O How to compose a mode line for your card/monitor combination under <idx>XFree86</idx>. The XFree86 distribution now includes good facilities for configuring most standard combinations; this document is mainly useful if you are tuning a custom mode line for a high-performance monitor or very unusual hardware. It may also help you in using kvideogen to generate mode lines, or xvidtune to tweak a standard mode that is not quite right for your monitor. --> <idx>XFree86</idx> において、お手元のカードやモニタの組み合わせに合わ せてモード行を作成する方法を説明します。現在の XFree86 の配布物は、 ほとんどの標準的な組み合わせに対応して設定できる素晴らしい機能を持って います。したがって、この文書は主に、モード行を高性能なモニタやとても変 わったハードウェア向けにカスタマイズして調整したい場合に役立ちます。 また、kvideogen を使ってモード行を作る場合や、標準的なモード行がお手元 のモニタにあまり適していない時に xvidtune を使ってモード行を変更する場 合にも役立つかもしれません。 </abstract> <toc> <!--O <sect>Disclaimer --> <sect>免責事項 <p> <!--O You use the material herein SOLELY AT YOUR OWN RISK. It is possible to harm both your monitor and yourself when driving it outside the manufacturer's specs. Read <ref id="overd" name="Overdriving Your Monitor"> for detailed cautions. Any damage to you or your monitor caused by overdriving it is your problem. --> この文書の情報はあなた自身の責任においてのみ使ってください。メーカーの 仕様外の使い方をした場合には、モニタとあなた自身の両方に障害を与える可 能性があります。 詳細な警告については <ref id="overd" name="モニタの仕様外使用"> を 読んでください。仕様外の使い方をした場合に読者の皆さんやモニタが受けた 被害は、全て読者の皆さん自身の問題です。 <!--O The most up-to-date version of this HOWTO can be found at the <url url="http://metalab.unc.edu/LDP" name="Linux Documentation Project"> web page. --> この HOWTO の最新版は <url url="http://sunsite.unc.edu/LDP" name="Linux Documentation Project"> のウェブページにあります。 <!--O Please direct comments, criticism, and suggestions for improvement to <htmlurl url="mailto:esr@thyrsus.com" name="esr@snark.thyrsus.com">. Please do <em>not</em> send email pleading for a magic solution to your special monitor problem, as doing so will only burn up my time and frustrate you -/- everything I know about the subject is already in here. --> 改良のための率直なご批評、ご批判やご提案は <htmlurl url="mailto:esr@thyrsus.com" name="esr@snark.thyrsus.com"> までお願いします。お使いのモニタの特殊な問題について魔法みたいな 解決法を期待する電子メールは送付<em>しない</em>でください。 そんなことをしても、私の時間は無駄になるし、あなたはいらいらするだけで す。私の知っていることは全部この文書に書いてあります。 <!--O <sect>Introduction<label id="intro"> --> <sect>はじめに<label id="intro"> <p> <!--O The XFree86 server allows users to configure their video subsystem and thus encourages best use of existing hardware. This document is intended to help you learn how to generate your own timing numbers to make optimum use of your video card and monitor. --> XFree86 サーバを使用すると、ユーザは自分のビデオサブシステムを設定して、 既存のハードウェアを最大限に利用できるようになります。 この文書の目的は、ビデオカードとモニタを最適に使用するための タイミング調節の数値の作り方を学ぶためのお手伝いをすることです。 <!--O We'll present a method for getting something that works, and then show you how you can experiment starting from that base to develop settings that optimize for your taste. --> この文書では、まず XFree86 サーバを何とか動かすための方法を提示し、 それを基礎に実験をしながら、自分の好みに合わせて設定を最適化する方法を 説明します。 <!--O If you already have a mode that almost works (in particular, if one of predefined VESA modes gives you a stable display but one that's displaced right or left, or too small, or too large) you can go straight to the section on <ref id="fixes" name="Fixing Problems with the Image">. This will enlighten you on ways to tweak the timing numbers to achieve particular effects. --> だいたい動作するモードが既にある場合(特に、予め設定されている VESA モードが安定しているものの、左右に片寄ったり、小さすぎたり、大きすぎる 場合)には、そのまま <ref id="fixes" name="画像表示の問題修正">の節まで 進んでください。この節を読めば、タイミング値を調整して良い結果を得る方 法がわかるでしょう。 <!--O Don't assume that you need to get all the way into mode tuning just because your X comes up with a scrambled display first time after installation; it may be that most of the factory mode lines are OK and you just happened to default to one that doesn't fit your hardware. Instead, cycle through all your installed modes with CTRL-ALT-KP+. If some of the modes look OK, try commenting out all but a 640x480 and check that that mode works. If it does then uncomment a couple of other modes, e.g. an 800x600 and a 1024x768 at a frequency that your monitor should be able to handle. --> X をインストール直後に起動した時に画面が乱れていたからといって、必ずし もモード調整の必要があると思い込まないでください。 出荷時のモード行のほとんどは正しく、あなたがデフォルト値として使った値 がたまたまハードウェアに合わなかっただけかもしれません。 ですから、調整を考えるよりも前に、用意されているモードを CTRL-ALT-KP+ を使って全て順番に試してください。うまく動作しているよう に見えるモードがいくつかあれば、640x480 のモードを除いて全てのモードを コメントアウトし、そのモードが動作するかどうかを確認します。これが動作 したら他のモード(例えば、解像度が 800x600 や 1024x768 で、あなたのモニ タが扱えるはずの周波数を持つモードなど)を有効にします。 <!--O More help is on the way. Many driver modules in the just-released XFree86 4.0 support DDC, the VESA Display Data Channel facility. When DDC is enabled, the monitor actually tells XFree86 what modelines it can support. So with 4.0 and any recently-manufactured monitor you are likely not to have to do any configuration at all. --> 他にも便利な方法ができてきました。リリースされたばかりの XFree86 4.0 に入っているドライバの多くは DDC(VESA Display Data Channel 機能)を サポートしています。DDC を有効にすると、モニタは対応しているモード行を 実際に XFree86 に教えます。したがって、XFree86 4.0 と最近のモニタを 一緒に使えば、設定を行う必要はたぶん全くないでしょう。 <!--O <sect>Tools for Automatic Computation --> <sect>自動計算のためのツール <p> <!--O If you have a relatively new monitor (1996 or later) that supports the PnP specification, there is a chance that you use the read-edid program to ask the monitor for its stastics and compute a mode line for you. See <url url="http://altern.org/vii/programs/linux/read-edid/">. --> PnP 仕様に対応している比較的新しいモニタ(1996 年以降の製品)をお使いで あれば、edid 読み取りプログラムを使ってモニタに基本特性値を問い合わせ、 モード行を自動的に計算できる可能性があります。詳しくは <url url="http://altern.org/vii/programs/linux/read-edid/"> をご覧ください。 <!--O Starting with XFree86 3.2, XFree86 provides an <bf>XF86Setup</bf>(1) program that makes it easy to generate a working monitor mode interactively, without messing with video timing number directly. So you shouldn't actually need to calculate a base monitor mode in most cases. Unfortunately, <bf>XF86Setup</bf>(1) has some limitations; it only knows about standard video modes up to 1280x1024. If you have a very high-performance monitor capable of 1600x1200 or more you will still have to compute your base monitor mode yourself. --> バージョン 3.2 以降の XFree86 には、ビデオのタイミング値を直接いじらず に、動作するモニタのモードを対話的に簡単に作成できる <bf>XF86Setup</bf>(1) プログラムが付属しています。したがってほとんどの 場合、基礎となるモニタのモードを実際に計算する必要はありません。 ただし残念ながら <bf>XF86Setup</bf>(1) にはいくつかの制限があります。 例えば、1280x1024 までの標準的なビデオのモードについてしか情報を持って いません。また、非常に高性能で 1600x1200 以上が使えるモニタを持ってい る場合はまだ、基礎となるモニタのモードを自分自身で計算しなければいけま せん。 <!--O There is a KDE tool called <url url="http://without.netpedia.net/kvideogen/" name="KVideoGen"> that computes modelines from basic monitor and card statistics. I've experimented with generating modelines from it, but haven't tried them live. Note that its horizontal and vertical `refresh rate' parameters are the same as the sync frequencies HSF and VSF we describe below. The `horizontal sync pulse' number seems to be a sync pulse width in microseconds, HSP (with the tool assuming fixed `front porch' HGT1 and `back porch' HGT2 values). If you don't know the `horizontal sync pulse' number it's safe to use the default.<P> --> KDE には、モニタとカードの基本特性値からモード行を計算する <url url="http://without.netpedia.net/kvideogen/" name="KVideoGen"> というツールがあります。筆者はこれを使ってモード行を作成するテストは行 いましたが、そのモード行を実際に試したことはありません。kvidegen の 水平と垂直の「リフレッシュレート(refresh rate)」パラメータは、後述の 同期周波数である HSF および VSF と同じです。 「水平同期信号(horizontal sync pulse, HSP)」数は、同期信号幅をマイクロ 秒単位で表したもののようです(このツールでは 「フロントポーチ(front porch)」 HGT1 値と 「バックポーチ(back porch)」 HGT2 値は定数としています)。 「水平同期信号」数がわからなければ、デフォルト値を使うのが安全でしょう。 <P> <!--O Recent versions of XFree86 provide a tool called <bf>xvidtune</bf>(1) which you will probably find quite useful for testing and tuning monitor modes. It begins with a gruesome warning about the possible consequences of mistakes with it. If you pay careful attention to this document and learn what is behind the pretty numbers in xvidtune's boxes, you will become able to use xvidtune effectively and with confidence. --> 最近の XFree86 には <bf>xvidtune</bf>(1) というツールが付属しています。 これはモニタのモード行のテストや調整に役立つことがお分かりいただけるで しょう。このツールは間違えて使った時の結果について恐ろしげな警告を出し て起動します。 この文書に書かれていることによく注意し、xvidtune のウィンドウに表示され るたくさんの数値の裏にある意味がわかるようになれば、自信を持って効率的 に xvidtune を使えるようになるはずです。 <!--O If you have <bf>xvidtune</bf>(1), you'll be able to test new modes on the fly, without modifying your X configuration files or even rebooting your X server. Otherwise, XFree86 allows you to hot-key between different modes defined in Xconfig (see XFree86.man for details). Use this capabilty to save yourself hassles! When you want to test a new mode, give it a unique mode label and add it to the <EM>end</EM> of your hot-key list. Leave a known-good mode as the default to fall back on if the test mode doesn't work. --> <bf>xvidtune</bf>(1) を持っている場合、X の設定ファイルを変更せずに、 あるいは X サーバの再起動さえ行わずに、そのままの状態で新しいモードを テストできます。<bf>xvidtune</bf> がなくても、XFree86 では XF86Config ファイルに定義されている複数のモードの間をホットキーを使っ て移動できます(詳しくは XF86Config.man を参照してください)。この機能 を使って面倒を避けましょう! 新しいモードをテストするときは、このモード に固有のラベルを与えて、ホットキーリストの <em>最後</em> に追加してく ださい。 新しいモードが動かなかったときの保険として、既に動いているモードは デフォルト値のままで残しておきましょう。 <!--O Towards the end of this document, we include a `modeplot' script that you can use to produce an analog graph of available modes. This is not directly helpful for generating modelines, but it may help you better understand the relationships that define them. --> 本文書の終わりの方に `modeplot' 用のスクリプトを載せています。このスク リプトを使うと、利用可能なモードのアナロググラフを作成できます。これは モード行の作成に直接役立つわけではありませんが、モード行を定義している 各数値の関係を理解する上で役に立つと思います。 <!--O <sect>How Video Displays Work<label id="video"> --> <sect>ビデオディスプレイの動作原理<label id="video"> <p> <!--O Knowing how the <idx>display</idx> works is essential to understanding what numbers to put in the various fields in the file Xconfig. Those values are used in the lowest levels of controlling the display by the XFree86 server. --> <idx>ディスプレイ</idx>の動作原理を知ることは、Xconfig ファイルの色々 な場所にどんな数字を入れるかを理解する上で重要です。これらの値は、 XFree86 サーバがディスプレイをハードウェアレベルで制御するのに使用しま す。 <!--O The display generates a picture from what you could consider to be a series of raster dots. The dots are arranged from left to right to form lines. The lines are arranged from top to bottom to form the picture. The dots emit light when they are struck by the electron beams inside the display, one for each primary color. To make the beams strike each dot for an equal amount of time, the beams are swept across the display in a constant pattern, called a raster. --> ディスプレイは、ラスタドットの集まりと考えられるものを使って画像を 表示します。このドットを左から右へ並べて線を作ります。そして、この線を 上から下へ並べて画像を作ります。ドットはディスプレイ内部で電子ビームを 当てられたとき発光します。それぞれのドットは自分の色を持っています。 それぞれのドットに均一に電子ビームを当てるために、電子ビームは ラスタと呼ばれる一定のパターンでディスプレイ上を走査します。 <!--O We say "what you could consider to be a series of dots" because these raster dots don't actually correspond to physical phosphor dots. The physical phosphor dots are much smaller than raster dots -/- they have to be, otherwise the display would suffer from severe moiré-pattern effects. The raster dots are really samples of the analog driver signal, and display as a grid of dots only because the peaks and valleys in the signal are quite regularly and finely spaced. --> 最初に「ドットの集まりと考えられるもの」と書いたのは、これらのラスタドット は実は物理的な発光体のドットと対応していないからです。物理的な発光体 のドットはラスタのドットよりもずっと小さいのです――ラスタのドットの方 が小さくなければなりません。もしそうでなければ、ディスプレイにはモアレ 効果が出てひどいことになってしまいます。ラスタドットは実際にはドライバ から来るアナログ信号をサンプリングしたものであり、これがドットの格子と して表示されるのは、信号の山と谷が非常に規則的であり、かつうまく間隔が 取られているからに過ぎません。 <!--O The pattern starts at the top left of the screen, goes across the screen to the right in a straight line, moving ever so slightly "downhill" (the downhill slope is too small to be perceptible). Then the beams are swept back to the left side of the display, starting at a new line. The new line is swept from left to right just as the first line was. This pattern is repeated until the bottom line on the display has been swept. Then the beams are moved from the bottom right corner of the display (sweeping back and forth a few times) to the top left corner, and the pattern is started over again. --> このパターンはスクリーンの左上から始まり、ごくわずかな「下り坂」(この 下り坂は非常に緩やかで人にはわからないくらいです)を下りながら右方向へ まっすぐにスクリーンを横切ります。そして電子ビームはディスプレイの 左端に戻って新しい線を開始します。新しい線は、最初の線の時と同じように ディスプレイを左から右へ走査します。このパターンはディスプレイの一番下 の線を走査するまで繰り返されます。それから電子ビームは(数回画面を往復 して走査しながら)ディスプレイの右下から左上まで移動し、それから最初か ら全ての動作を繰り返します。 <!--O There is one variation of this scheme known as <idx>interlacing</idx>: here only every second line is swept during one half-frame and the others are filled in during a second half-frame. --> 走査には <idx>インタレース</idx>と呼ばれる別種類の方法があります。 インタレースとは、最初の半フレームでは一つおきの線しか走査せず、二回目 の半フレームで残りの線を走査するという方法です。 <!--O Starting the beams at the top left of the display is called the beginning of a frame. The frame ends when the beams reach the the top left corner again as they come from the bottom right corner of the display. A frame is made up of all of the lines the beams traced from the top of the display to the bottom. --> ディスプレイの左上の電子ビームの開始点はフレームの始まりと呼ばれます。 フレームは、電子ビームがディスプレイの右下隅まで届いてから左上隅に再び戻って きたときに終了します。フレームはディスプレイの一番上から一番下までの全ての 電子ビームの線でできています。 <!--O If the electron beams were on all of the time they were sweeping through the frame, all of the dots on the display would be illuminated. There would be no black border around the edges of the display. At the edges of the display the picture would become distorted because the beams are hard to control there. To reduce the distortion, the dots around the edges of the display are not illuminated by the beams (because they're turned off) even though the beams, if they were turned on, would be pointing at them. The viewable area of the display is reduced this way. --> もし電子ビームがフレームを移動している間ずっと「オン」だったら、 ディスプレイの全てのドットは点灯してしまい、ディスプレイの縁には黒い部 分はなくなるでしょう。そしてディスプレイの縁では、電子ビームの制御が難 しいので画像が歪んでしまうでしょう。この歪みを減らすため、ディスプレイ の縁のドットは、電子ビームが届いても(「オフ」になっているため)ドットが 輝かないようになっています。ディスプレイの実際に表示される領域が小さく なっているのは、こういうわけなのです。 <!--O Another important thing to understand is what becomes of the beams when no spot is being painted on the visible area. The time the beams would have been illuminating the side borders of the display is used for sweeping the beams back from the right edge to the left. The time the beams would have been illuminating the top and bottom borders of the display is used for moving the beams from the bottom-right corner of the display to the top-left corner. --> 理解すべきもう一つの重要なことは、表示する領域を描画していない時に電子 ビームがどうなっているかということです。ディスプレイの両端を描画するた めに使われるはずだった時間は、電子ビームを右端から左端まで戻すために使 われます。ディスプレイの上端および下端を描画するためにかかるはずだった 時間は、電子ビームをディスプレイの右下隅から左上隅まで移動させるために 使われます。 <!--O The adapter card generates the signals which cause the display to turn on the electron beams (according to the desired color) at each dot to generate a picture. The card also controls when the display moves the beams from the right side back to the left by generating a signal called the horizontal sync (for synchronization) pulse. One horizontal sync pulse occurs at the end of every line. The adapter also generates a vertical sync pulse which signals the display to move the beams to the top-left corner of the display. A vertical sync pulse is generated near the end of every frame. --> アダプタカードは信号を生成し、絵を描くのに使うそれぞれのドットの位置で (表示させたい色に従って)ディスプレイの電子銃を点灯させます。また、 アダプタカードは水平同期信号と呼ばれる信号を生成し、電子ビームが右端か ら左端に戻るタイミングを制御します。水平同期信号は、全ての行の最後でひ とつ発生します。さらに、アダプタカードは電子ビームをディスプレイの左上 隅に移動させるための垂直同期信号も生成します。垂直同期信号は全ての フレームの終わり近くに生成されます。 <!--O The display requires that there be short time periods both before and after the horizontal and vertical sync pulses so that the position of the electron beams can stabilize. If the beams can't stabilize, the picture will not be steady. --> ディスプレイは電子ビームの位置を安定させるため、水平同期信号と 垂直同期信号の前後に短い時間を必要とします。電子ビームの安定化ができな いと画像が安定しません。 <!--O For more information, see <url url="http://fribble.cie.rpi.edu/~repairfaq/REPAIR/F_deflfaq.html" name="TV and Monitor Deflection Systems">. --> 詳しくは <url url="http://fribble.cie.rpi.edu/~repairfaq/REPAIR/F_deflfaq.html" name="TV and Monitor Deflection Systems"> のページをご覧ください。 <!--O In a later section, we'll come back to these basics with definitions, formulas and examples to help you use them. --> 後の節では、定義と公式、例題を使えるようにするため、再びこれらの基本事 項に触れます。 <!--O <sect>Basic Things to Know about your Display and Adapter<label id="basic"> --> <sect> ディスプレイとアダプタについての基礎知識<label id="basic"> <p> <!--O There are some fundamental things you need to know before hacking an Xconfig entry. These are: --> Xconfig の設定項目をいじる前に、次の基礎的な事項を知っておく必要があり ます: <itemize> <!--O <item>your monitor's horizontal and vertical sync frequency options <item>your monitor's bandwidth <item>your video adapter's driving clock frequencies, or "dot clocks" --> <item> 使用できるモニタの水平同期信号と垂直同期信号の周波数 <item> モニタの周波数帯幅 <item> ビデオアダプタの動作クロック周波数、すなわち「ドットクロック」 </itemize> <!--O <sect1>The monitor sync frequencies --> <sect1>モニタの同期周波数 <p> <!--O The <idx>horizontal sync frequency</idx> is just the number of times per second the monitor can write a horizontal scan line; it is the single most important statistic about your monitor. The vertical sync frequency is the number of times per second the monitor can traverse its beam vertically. --> モニタの<idx>水平同期周波数</idx>とは、そのモニタが 1 秒間に描ける水平走 査線の数のことで、これはモニタの最も重要な特性です。垂直同期周波数は、 そのモニタが 1 秒間に電子ビームを縦方向に行き来させられる回数のことです。 <!--O Sync frequencies are usually listed on the specifications page of your monitor manual. The <idx>vertical sync frequency</idx> number is typically calibrated in Hz (cycles per second), the horizontal one in KHz (kilocycles per second). The usual ranges are between 50 and 150Hz vertical, and between 31 and 135KHz horizontal. --> 同期周波数は普通、モニタのマニュアルの仕様のページに載っています。 <idx>垂直同期周波数</idx>の数値は一般的に Hz(秒当たりの回数)で、 水平同期周波数は KHz(秒当たりの千回数)で計測されています。通常の範囲 は、垂直で 50Hz から 150Hz 程度、水平で 31KHz から 135KHz 程度です。 <!--O If you have a multisync monitor, these frequencies will be given as ranges. Some monitors, especially lower-end ones, have multiple fixed frequencies. These can be configured too, but your options will be severely limited by the built-in monitor characteristics. Choose the highest frequency pair for best resolution. And be careful -/-/- trying to clock a fixed-frequency monitor at a higher speed than it's designed for can easily damage it. --> マルチシンクモニタの場合、その周波数は幅のある値として表示されています。 ローエンドの製品に多いのですが、複数の固定した周波数を持っているモニタも あります。このようなモニタも普通のモニタと同様に設定はできますが、モニ タの持つ特性に厳しく制限されてしまうでしょう。できるだけ高い解像度で、 できるだけ高い水平同期と垂直同期周波数の組み合わせを選択してください。 また、固定周波数モニタでは設計値より高い周波数を与えるとモニタを傷める おそれがあるので注意してください。 <!--O Earlier versions of this guide were pretty cavalier about overdriving multisync monitors, pushing them past their nominal highest vertical sync frequency in order to get better performance. We have since had more reasons pointed out to us for caution on this score; we'll cover those under <ref id="overd" name="Overdriving Your Monitor"> below. --> この文書の初期の版では、マルチシンクモニタの仕様外使用にかなり無頓着で あり、より良い性能を得るために垂直同期周波数の名目上の最高値を超えさせて いました。その後、この状況への警告である、さらに多くの指摘を受けました。 後述の <ref id="overd" name="モニタの仕様外使用"> で説明します。 <!--O <sect1>The monitor's video bandwidth --> <sect1>モニタのビデオ信号帯域幅: <p> <!--O Your monitor's video bandwidth should be included on the manual's spec page. If it's not, look at the monitor's higest rated resolution. As a rule of thumb, here's how to translate these into bandwidth estimates (and thus into rough upper bounds for the dot clock you can use): --> モニタのビデオ信号帯域幅はマニュアルの仕様に関するページに載っています。 これが無かった場合は、モニタの最も高い解像度のところを見てください。 解像度から帯域幅(つまり使用できるドットクロックの大まかな上限値)を推定 するための経験則を以下に示します: <!--O <tscreen><verb> 640x480 25 800x600 36 1024x768 65 1024x768 interlaced 45 1280x1024 110 1600x1200 185 </verb></tscreen> --> <tscreen><verb> 640x480 25 800x600 36 1024x768 65 1024x768 インタレース 45 1280x1024 110 1600x1200 185 </verb></tscreen> <!--O BTW, there's nothing magic about this table; these numbers are just the lowest dot clocks per resolution in the standard XFree86 Modes database (except for the last, which I extrapolated). The bandwidth of your monitor may actually be higher than the minimum needed for its top resolution, so don't be afraid to try a dot clock a few MHz higher. --> ところで、この表に載っているのは謎の数字ではありません。これらの数字は、 XFree86 標準のモード値データベースから各解像度の最も低いドットクロック 値を集めただけのものです(最後の値だけは別です。これは外挿して求めまし た)。モニタの帯域幅は、一番上の解像度で必要な最低限の帯域幅よりも実際 には高いでしょうから、恐れずに数 MHz 高めのドットクロックを試してみて ください。 <!--O Also note that bandwidth is seldom an issue for dot clocks under 65MHz or so. With an SVGA card and most hi-res monitors, you can't get anywhere near the limit of your monitor's video bandwidth. The following are examples: --> また、65MHz あたり以下のドットクロックでは帯域幅はほとんど問題にならな いことに注意してください。SVGA やほとんどの高解像度のモニタでは、これ はモニタのビデオ信号帯域幅の限界よりもはるかに低い周波数だからです。 以下に例を示します: <!--O <tscreen><verb> Brand Video Bandwidth ---------- --------------- 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 </verb></tscreen> --> <tscreen><verb> ブランド名 ビデオ信号帯域幅 ---------- --------------- 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 </verb></tscreen> <!--O Even low-end monitors usually aren't terribly bandwidth-constrained for their rated resolutions. The NEC Multisync II makes a good example -/-/- it can't even display 800x600 per its spec. It can only display 800x560. For such low resolutions you don't need high dot clocks or a lot of bandwidth; probably the best you can do is 32Mhz or 36Mhz, both of them are still not too far from the monitor's rated video bandwidth of 30Mhz. --> 一番下のクラスのモニタでも、解像度に関してビデオ信号帯域幅から厳しい 制約を受けることはありません。NEC Multisync II が良い例です。このディ スプレイは仕様によると 800x600 は表示できず、800x560 しか表示できませ ん。このような低解像度の場合は、高いドットクロックや大きなビデオ信号帯 域幅は必要ありません。多分 32MHz か 36MHz で十分で、両方の周波数とも モニタの公称のビデオ信号帯域幅である30MHz からそれほど離れた値ではあり ません。 <!--O At these two driving frequencies, your screen image may not be as sharp as it should be, but definitely of tolerable quality. Of course it would be nicer if NEC Multisync II had a video bandwidth higher than, say, 36Mhz. But this is not critical for common tasks like text editing, as long as the difference is not so significant as to cause severe image distortion (your eyes would tell you right away if this were so). --> これら 2 つの動作周波数では、ディスプレイが持っているはずの性能よりも 画面がくっきりと映らないかもしれませんが、それでもかなりの品質だと言っ てもいいでしょう。もちろん、NEC Multisync II がもっと高い、例えば 36MHz のビデオ信号帯域幅を持っているに越したことはありません。しかし、 大きく画像が歪む程周波数がかけ離れていなければ、文章を編集する等の一般 的な作業には問題はありません。(もし画像の歪みがあまりにも大きい場合に は、目で見てすぐわかるでしょう)。 <!--O <sect1>The card's dot clock --> <sect1>カードのドットクロック値 <p> <!--O Your video adapter manual's spec page will usually give you the card's maximum <idx>dot clock</idx> (that is, the total number of pixels per second it can write to the screen). --> ビデオアダプタの仕様書には普通、カードの最大<idx>ドットクロック</idx> 値が書かれています(ドットクロックとは画面へ 1 秒間に表示できる点の総数 です)。 <!--O If you don't have this information, the X server will get it for you. Recent versions of the X servers all support a -/-probeonly option that prints out this information and exits without actually starting up X or changing the video mode. --> ドットクロックの情報を与えなかった場合は、X サーバが自力でそれを取得し ます。最近の全ての X サーバ は、X の実際の起動やビデオモードの変更を行 わずにドットクロックの情報の出力だけを行う --probeonly オプションを サポートしています。 <!--O If you don't have -probeonly, don't depair. Even if your X locks up your monitor, it will emit a line of clock and other info to standard error. If you redirect this to a file, it should be saved even if you have to reboot to get your console back. --> <!-- fujiwara: depair って知らない言葉だ… --> -probeonly オプションが無くても気にしないでください。X がモニタを固ま らせても、クロック値やその他の情報に関する行が標準エラー出力に書き出さ れます。これをファイルにリダイレクトすれば、たとえコンソールに戻るため に再起動が必要な場合でも、記録を残すことができます。 <!--O The probe result or startup message should look something like one of the following examples: --> 検出の結果や起動メッセージは、以下の例のようになります: <!--O If you're using XFree86: --> XFree86 の場合: <verb> 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 </verb> <!--O If you're using SGCS or X/Inside X: --> SGCS や X/Inside の X の場合: <verb> WGA: 86C911 (mem: 1024k clocks: 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71) --- ------ ----- -------------------------------------------- | | | 利用可能な駆動周波数(MHz 単位) | | +-- ボードに載っているフレームバッファ RAM の大きさ | +-- チップの種類 +-- サーバの種類 </verb> <!--O Note: do this with your machine unloaded (if at all possible). Because X is an application, its timing loops can collide with disk activity, rendering the numbers above inaccurate. Do it several times and watch for the numbers to stabilize; if they don't, start killing processes until they do. Your mouse daemon process, if you have one, is particularly likely to trip you up (that's gpm for Linux users, mousemgr for SVr4 users). --> 注意: なるべくこの作業はマシンの負荷が低い時に行なってください。X はアプリケ ーションですから、ディスクの動作と時間調節のループが衝突すると、上記の数字 は不正確になります。何回か繰り返し実行し、数字が大きく変動しないことを確か めてください。もし変動が大きい場合には、安定するまでプロセスを殺してみてくだ さい。もしマウスデーモンのプロセスをお使いであれば、これは混乱の元になり ます(Linux では gpm, SVr4 では mousemgr が該当します)。 <!--O In order to avoid the clock-probe inaccuracy, you should clip out the clock timings and put them in your Xconfig as the value of the Clocks property -/-/- this suppresses the timing loop and gives X an exact list of the clock values it can try. Using the data from the example above: --> このような不正確さを避けるため、得られたクロックの数字をそのまま Clocks プ ロパティの値として Xconfig に取り込んでください。これは時間調節のループを抑 止し、X が試せるクロック値の正確な一覧を与えるためです。 上記の例のデータを使うと、次のようになります: <verb> wga Clocks 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71 </verb> <!--O On systems with a highly variable load, this may help you avoid mysterious X startup failures. It's possible for X to come up, get its timings wrong due to system load, and then not be able to find a matching dot clock in its config database -/-/- or find the wrong one! --> 高く変動する負荷がかかるシステムでは、この方法を使うと X の起動の不可 解な失敗を回避する助けになるでしょう。X が起動した時にシステムの負荷の せいで間違った値を得てしまい、config データベースからちょうどよい ドットクロック値を見つけることができなかったり、間違った値を見つけてし まうことがあり得るのです。 <!--O <sect1>What these basic statistics control --> <sect1>これらの特性は何を制御するのか? <p> <!--O The sync frequency ranges of your monitor, together with your video adapter's dot clock, determine the ultimate resolution that you can use. But it's up to the driver to tap the potential of your hardware. A superior hardware combination without an equally competent device driver is a waste of money. On the other hand, with a versatile device driver but less capable hardware, you can push the hardware's envelope a little. This is the design philosophy of XFree86. --> モニタの同期信号帯域幅は、ビデオアダプタのドットクロックと共に、表示でき る最高の解像度を決定します。しかしハードウェアの性能を引き出すのはドライバ です。どんなに優れたビデオアダプタやモニタでも、良いデバイスドライバ がなければ宝の持ち腐れになってしまいます。一方、有能なデバイスドライバ があれば機能の低いハードでも十分役に立ちます。これが XFree86 の設計哲学です。 <!--O You should match the dot clock you use to the monitor's video bandwidth. There's a lot of give here, though -/-/- some monitors can run as much as 30% over their nominal bandwidth. The risks here have to do with exceeding the monitor's rated vertical-sync frequency; we'll discuss them in detail below. --> 使用するドットクロックはモニタのビデオ帯域幅に合わせるべきです。 ただし、ここはかなり柔軟性がある部分です――モニタによっては名目 上の帯域幅の 30% 増しで動作します。これに伴うリスクは、モニタに記載さ れている垂直同期周波数を超えることに関係します。 これについては以降で詳しく説明します。 <!--O Knowing the bandwidth will enable you to make more intelligent choices between possible configurations. It may affect your display's visual quality (especially sharpness for fine details). --> 帯域幅を知っていると、可能な設定の中から、より賢い選択ができるようにな ります。これは、あなたのディスプレイの表示品質(特に高精細のための シャープさ)に影響するかもしれません。 <!--O <sect>Interpreting the Basic Specifications<label id="specs"> --> <sect>基本仕様の読み方<label id="specs"> <p> <!--O This section explains what the specifications above mean, and some other things you'll need to know. First, some definitions. Next to each in parens is the variable name we'll use for it when doing calculations --> この節では上記の仕様の意味と、その他に知らなければならないことを 説明します。まず最初にいくつか定義をします。それぞれの隣には、計算をす る時に使う変数名を括弧内に示します。 <descrip> <!--O <tag/horizontal sync frequency (HSF)/ Horizontal scans per second (see above). --> <tag/水平同期周波数(horizontal sync frequency, HSF)/ 秒あたりの水平走査数 (上記参照)。 <!--O <tag/vertical sync frequency (VSF) / Vertical scans per second (see above). Mainly important as the upper limit on your refresh rate. --> <tag/垂直同期周波数(vertical sync frequency, VSF)/ 毎秒の垂直走査数(上記参照)。主にリフレッシュレートの上限として重要。 <!--O <tag/dot clock (DCF)/ More formally, `driving clock frequency'; The frequency of the crystal or VCO on your adaptor -/-/- the maximum dots-per-second it can emit. --> <tag/ドットクロック値(dot clock, DCF)/ より正式には「駆動クロック周波数」だが、適当に「帯域幅」と呼ぶことも。 アダプタの発振子または VCO の周波数 --- 毎秒描画可能ドット数の最大値。 <!--O <tag/video bandwidth (VB)/ The highest frequency you can feed into your monitor's video input and still expect to see anything discernible. If your adaptor produces an alternating on/off pattern, its lowest frequency is half the DCF, so in theory bandwidth starts making sense at DCF/2. For tolerately crisp display of fine details in the video image, however, you don't want it much below your highest DCF, and preferably higher. --> <tag/ビデオ信号帯域幅(video bandwidth, VB)/ モニタのビデオ入力に送り込んで、何か識別できるものが見えること を期待できる最大の周波数。アダプタがオン/オフ切り替えのパターン を生成した場合、最低の周波数は DCF の半分になります。したがっ て理論的には帯域幅が意味を持ち始めるのは DCF の 1/2 からです。 しかし、詳細部分が我慢できる程度にくっきりと表示させるには、 DCF の最高値よりずっと低いとよくないでしょう。できるなら高めに しておきましょう。 <!--O <tag/frame length (HFL, VFL)/ Horizontal frame length (HFL) is the number of dot-clock ticks needed for your monitor's electron gun to scan one horizontal line, <em>including the inactive left and right borders</em>. Vertical frame length (VFL) is the number of scan lines in the <em>entire</em> image, including the inactive top and bottom borders. --> <tag/フレーム長(HFL, VFL)/ 水平フレーム長(HFL)はモニタの電子銃が 1 つの<em>使われていない左右 の境界を含む</em>水平線を走査するのに必要なドットクロックの数。 垂直フレーム長 (VFL)は使われていない上と下の境界を含む <em>完全な</em>画面の走査線の数です。 <!--O <tag/screen refresh rate (RR)/ The number of times per second your screen is repainted (this is also called "frame rate"). Higher frequencies are better, as they reduce flicker. 60Hz is good, VESA-standard 72Hz is better. Compute it as --> <tag/リフレッシュレート(screen refresh rate, RR)/ 秒あたりの画面再描画回数(「フレームレート」とも呼ばれます)。高 い方が良い値で、ちらつきが少なくなります。60Hz は良い値ですし、 VESA 標準の 72Hz ならばなお良いでしょう。 以下の計算で求めます: <tscreen><verb> RR = DCF / (HFL * VFL) </verb></tscreen> <!--O Note that the product in the denominator is <em>not</em> the same as the monitor's visible resolution, but typically somewhat larger. We'll get to the details of this below. --> 分母にある積はモニタに表示される解像度では<em>なく</em>、これ よりいくらか大きいことに注意してください。これについては以降で 詳しく説明します。 <!--O The rates for which interlaced modes are usually specified (like 87Hz interlaced) are actually the half-frame rates: an entire screen seems to have about that flicker frequency for typical displays, but every single line is refreshed only half as often. --> インタレースモードの周波数は普通、実際には半分のフレームの周波数で (87Hz interlaced のように)指定します: 普通のディスプレイでは画面全体 でちらつきが出るような周波数ですが、全ての単一の線が半分の周期でしか 再描画されません。 <!--O For calculation purposes we reckon an interlaced display at its full-frame (refresh) rate, i.e. 43.5Hz. The quality of an interlaced mode is better than that of a non-interlaced mode with the same full-frame rate, but definitely worse then the non-interlaced one corresponding to the half-frame rate. --> 計算のため、全フレームの再描画速度(リフレッシュレート)つまり 43.5Hz でのインタレース表示を考えます。 インタレースモードの表示品質は、同じ全フレームレートの非インタレース モードの表示品質より良好です。しかし、 半フレームレートに対応する非インタレースモードの表示品質と比べると 明らかに劣ります。 </descrip> <!--O <sect1>About Bandwidth --> <sect1>帯域幅について <p> <!--O Monitor makers like to advertise high bandwidth because it constrains the sharpness of intensity and color changes on the screen. A high bandwidth means smaller visible details. --> モニタのメーカーは帯域幅の高さをよく宣伝文句にします。というのも、 帯域幅が光の強さと色変化のシャープさに制約を与えるからです。 帯域幅が大きいほど、より細かい画像を表示することができます。 <!--O Your monitor uses electronic signals to present an image to your eyes. Such signals always come in in wave form once they are converted into analog form from digitized form. They can be considered as combinations of many simpler wave forms each one of which has a fixed frequency, many of them are in the Mhz range, eg, 20Mhz, 40Mhz, or even 70Mhz. Your monitor video bandwidth is, effectively, the highest-frequency analog signal it can handle without distortion. --> モニタは電気信号を用いて画像を表示します。信号は一度デジタルからアナログ へと変換されると、常にアナログ信号として取り扱われます。アナログ信号は 固定周波数の単純な波形をたくさん組み合わせたものと考えられ、それらの多 くは MHz あたりの範囲の周波数、例えば 20MHz、40MHz、さらに 70MHz だっ たりします。モニタのビデオ信号帯域幅は、事実上歪みなしに扱える最も高い 周波数領域のアナログ信号です。 <!--O For our purposes, <idx>video bandwidth</idx> is mainly important as an approximate cutoff point for the highest dot clock you can use. --> 私達の目的のためには、<idx>ビデオ信号帯域幅</idx>は主に使用可能なドッ トクロックのおおよその上限として重要です。 <!--O <sect1>Sync Frequencies and the Refresh Rate: --> <sect1>同期周波数とリフレッシュレート: <p> <!--O Each horizontal scan line on the display is just the visible portion of a frame-length scan. At any instant there is actually only one dot active on the screen, but with a fast enough refresh rate your eye's persistence of vision enables you to "see" the whole image. --> 画面上の水平走査線はフレーム長走査の中で実際に表示される部分です。それぞれ の瞬間に実際に輝いている点はたった一つだけですが、リフレッシュレートが 十分速ければ、目には絶え間なく全ての画像が「見える」というわけです。 <!--O Here are some pictures to help: --> ここでいくつかの図で解説します: <verb> _______________________ | | 水平同期周波数は、 |->->->->->->->->->->-> | モニタの電子ビームが | )| このようなパターンを |<-----<-----<-----<--- | 走査する、1 秒あたりの | | 回数です。 | | | | | | |_______________________| _______________________ | ^ | 垂直同期周波数は、 | ^ | | モニタの電子ビームが | | v | このようなパターンを | ^ | | 走査する、1 秒あたりの | | | | 回数です。 | ^ | | | | v | | ^ | | |_______|_v_____________| </verb> <!--O Remember that the actual raster scan is a very tight zigzag pattern; that is, the beam moves left-right and at the same time up-down. --> 実際のラスタ走査はとても細かいジグザグ型のパターンをしていて、左右に電子 ビームが動いて同時に上下にも動いています。 <!--O Now we can see how the dot clock and frame size relates to refresh rate. By definition, one hertz (hz) is one cycle per second. So, if your horizontal frame length is HFL and your vertical frame length is VFL, then to cover the entire screen takes (HFL * VFL) ticks. Since your card emits DCF ticks per second by definition, then obviously your monitor's electron gun(s) can sweep the screen from left to right and back and from bottom to top and back DCF / (HFL * VFL) times/sec. This is your screen's refresh rate, because it's how many times your screen can be updated (thus <em>refreshed</em>) per second! --> これで、ドットクロックとフレームの大きさがどのようにリフレッシュレート に関係しているかが分かります。定義によると、 1 ヘルツ(Hz)は 1 秒に 1 周期です。したがって、水平フレーム長を HFL とし垂直フレーム長を VFL と した場合に全ての画面を覆うには (HFL * VFL) 回ドットクロックが必要です。 定義によるとカードからは毎秒 DCF 回の信号が出ているので、モニタの電子 銃が左から右・戻る・下から上へ・戻るという走査を毎秒 DCF / (HFL * VFL) 回行えるのは明らかです。これがリフレッシュレートです。 なぜなら、これは毎秒あたり何回画面を更新できるか (だから<em>リフレッシュ</em>)を示しているからです。 <!--O You need to understand this concept to design a configuration which trades off resolution against flicker in whatever way suits your needs. --> 解像度とちらつきの関係がトレードオフの関係にあるので、自分の要求に応じて設 定を行なうためにこの概念を理解する必要があります。 <!--O For those of you who handle visuals better than text, here is one: --> テキストよりは視覚に訴えた方が分かるので次に関係図を描きます: <verb> RR VB | min HSF max HSF | | | R1 R2 | | max VSF -+----|------------/----------/---|------+----- max VSF | |:::::::::::/::::::::::/:::::\ | | \::::::::::/::::::::::/:::::::\ | | |::::::::/::::::::::/:::::::::| | | |:::::::/::::::::::/::::::::::\ | | \::::::/::::::::::/::::::::::::\ | | \::::/::::::::::/::::::::::::::| | | |::/::::::::::/:::::::::::::::| | | \/::::::::::/:::::::::::::::::\| | /\:::::::::/:::::::::::::::::::| | / \:::::::/::::::::::::::::::::|\ | / |:::::/:::::::::::::::::::::| | | / \::::/::::::::::::::::::::::| \ min VSF -+----/-------\--/-----------------------|--\--- min VSF | / \/ | \ +--/----------/\------------------------+----\- DCF R1 R2 \ | \ min HSF | max HSF VB </verb> <!--O This is a generic monitor mode diagram. The x axis of the diagram shows the clock rate (DCF), the y axis represents the refresh rate (RR). The filled region of the diagram describes the monitor's capabilities: every point within this region is a possible video mode. --> これは一般的なモニタのモードダイアグラムです。ダイアグラムの x 軸は クロック周波数(DCF)、y 軸はリフレッシュレート(RR)を意味しています。 ダイアグラムで塗り潰してある領域はモニタの表示可能な領域です。 この領域のどの点をとっても表示可能です。 <!--O The lines labeled `R1' and `R2' represent a fixed resolutions (such as 640x480); they are meant to illustrate how one resolution can be realized by many different combinations of dot clock and refresh rate. The R2 line would represent a higher resolution than R1. --> `R1' と `R2' のラベルをつけた線は(640x480 のような)固定解像度を表して います。つまり、複数の異なるドットクロックとリフレッシュレートの組み合 わせで一つの解像度をどのように実現できるかが図解されています。 R2 の線は R1 の解像度より高いことを表しています。 <!--O The top and bottom boundaries of the permitted region are simply horizontal lines representing the limiting values for the vertical sync frequency. The video bandwidth is an upper limit to the clock rate and hence is represented by a vertical line bounding the capability region on the right. --> 許されている領域の上と下の境界線は、垂直同期周波数の限界値を表す単なる 水平線です。ビデオ信号帯域幅はクロック周波数の上限値で、したがって 表示可能な領域の右の境界にあたる垂直な線で表されます。 <!--O Under <ref id="cplot" name="Plotting Monitor Capabilities">) you'll find a program that will help you plot a diagram like this (but much nicer, with X graphics) for your individual monitor. That section also discusses the interesting part; the derivation of the boundaries resulting from the limits on the horizontal sync frequency. --> <ref id="cplot" name="モニタ性能をプロットする">には、個々のモニタに対 してこのようなダイアグラム(X graphics ではもっと役に立つでしょう)を プロットするのを助けてくれるプログラムがあります。その節には興味深い 議論もあります。すなわち、水平同期周波数の上限からの境界値の導出です。 <!--O <sect>Tradeoffs in Configuring your System<label id="trade"> --> <sect>システムの設定におけるトレードオフ<label id="trade"> <p> <!--O Another way to look at the formula we derived above is --> 前に示した公式は、このように変形できます: <tscreen><verb> DCF = RR * HFL * VFL </verb></tscreen> <!--O That is, your dot clock is fixed. You can use those dots per second to buy either refresh rate, horizontal resolution, or vertical resolution. If one of those increases, one or both of the others must decrease. --> つまりドットクロックは固定です。この一秒当たりのドット数は、リフレッシュ レート、水平解像度または垂直解像度に振り分けられます。 これらの数字のどれかを増やすと、別の数字を減らさなければなりません。 <!--O Note, though, that your refresh rate cannot be greater than the maximum vertical sync frequency of your monitor. Thus, for any given monitor at a given dot clock, there is a minimum product of frame lengths below which you can't force it. --> ただし、リフレッシュレートはモニタの最大垂直同期周波数を超えられないの で注意してください。したがって、あるモニタの、あるドットクロックでは、 フレーム長の積に最小値があり、それより小さくすることはできません。 <!--O In choosing your settings, remember: if you set RR too low, you will get mugged by screen flicker. Keep it above 60Hz. 72Hz is the VESA ergonomic standard. 120Hz is the flicker rate of fluorescent lights; if you're sensitive to those, you need to keep it above that. --> 自分の設定を選ぶ時には覚えておいてください。リフレッシュレートが低すぎ ると画面のちらつきに泣かされるはめになります。リフレッシュレートは 60Hz 以上にしましょう。VESA の人間工学的な標準値は 72Hz です。蛍光灯の 点滅のレートは 120Hz です。ちらつきに敏感な方は、リフレッシュレートを これらの値より高くしましょう。 <!--O Flicker is very eye-fatiguing, though human eyes are adaptable and peoples' tolerance for it varies widely. If you face your monitor at a 90% viewing angle, are using a dark background and a good contrasting color for foreground, and stick with low to medium intensity, you *may* be comfortable at as little as 45Hz. --> 人間の目には慣れがありますし、人間の目のちらつきに対する耐性には個人差 がありますが、ちらつきは大変目に辛いものです。 画面の 90% が見える角度でモニタに向き合い、暗い背景と良いコントラスト の色を前景色に使っていて、しかも輝度を低から中に調整しているならば、 <em>たぶん</em> 45Hz 位に小さくても快適でしょう。 <!--O The acid test is this: open a xterm with pure white back-ground and black foreground using <tt>xterm -bg white -fg black</tt> and make it so large as to cover the entire viewable area. Now turn your monitor's intensity to 3/4 of its maximum setting, and turn your face away from the monitor. Try peeking at your monitor sideways (bringing the more sensitive peripheral-vision cells into play). If you don't sense any flicker or if you feel the flickering is tolerable, then that refresh rate is fine with you. Otherwise you better configure a higher refresh rate, because that semi-invisible flicker is going to fatigue your eyes like crazy and give you headaches, even if the screen looks OK to normal vision. --> 厳密なテストのやり方は次の通りです: xterm -bg white -fg black で真っ白 な背景色に黒の前景色の xterm を開いて、表示可能な領域全てを隠すぐらい の大きさにしてください。そしてモニタの明るさを最大の設定値の 3/4 に設 定して、モニタから顔をそむけて、モニタを横目で覗いてみてください(これ は、より敏感な視野周辺部の細胞を働かせるためです)。全くちらつきを感じ ない場合、もしくはちらつきが許せる範囲ならば、あなたにとってその リフレッシュレートはちょうど良い値です。もしそうでなかったら、 リフレッシュレートをもっと高く設定してください。なぜなら、一見大丈夫な ように見えても、明らかには分からないようなちらつきによって目がとても疲 労して頭痛を起こすからです。 <!--O For interlaced modes, the amount of flicker depends on more factors such as the current vertical resolution and the actual screen contents. So just experiment. You won't want to go much below about 85Hz half frame rate, though. --> インタレースモードでは、ちらつきの量は現在の仮想解像度と実際の画面の 中身に依存します。したがって実験が必要になります。半フレームの周波数は 85Hz あたりより低くしないほうがよいでしょう。 <!--O So let's say you've picked a minimum acceptable refresh rate. In choosing your HFL and VFL, you'll have some room for maneuver. --> 以上のようにして、ぎりぎり許容できるリフレッシュレートを選ぶことができ ました。HFL と VFL の選択においては、多少の作戦を立てる余地があるでしょう。 <!--O <sect>Memory Requirements<label id="sizes"> --> <sect>要求されるメモリ量<label id="sizes"> <p> <!--O Available frame-buffer RAM may limit the resolution you can achieve on color or gray-scale displays. It probably isn't a factor on displays that have only two colors, white and black with no shades of gray in between. --> カラーディスプレイやグレースケールディスプレイで実現できる解像度は 使用可能なフレームバッファメモリの量に制限されます。この制限は、2 色 (白黒)でグレースケールでないディスプレイの場合は多分関係ありません。 <!--O For 256-color displays, a byte of video memory is required for each visible dot to be shown. This byte contains the information that determines what mix of red, green, and blue is generated for its dot. To get the amount of memory required, multiply the number of visible dots per line by the number of visible lines. For a display with a resolution of 1024x768, this would be 1024 x 768 = 786432, which is the number of visible dots on the display. This is also, at one byte per dot, the number of bytes of video memory that will be necessary on your adapter card. --> 256 色のディスプレイの場合は、ビデオメモリのバイト数は表示されるドット の数だけ必要です。このバイト数は赤緑青から成る集合の点を 1 点とした数 です。必要なメモリ量を得るには、線 1 本当たりに表示される点の数に表示 される線の数を掛けてください。1024x768 の解像度を持つディスプレイの場 合は、ディスプレイに表示する点の数は 1024 x 768 = 786,432 になります。 また、 1 ドットが 1 バイトになるので、アダプタカードに同じバイト数のビ デオメモリが必要です。 <!--O Thus, your memory requirement will typically be (HR * VR)/1024 Kbytes of VRAM, rounded up (it would come to 768K exactly in this example). If you have more memory than strictly required, you'll have extra for virtual-screen panning. --> したがって、メモリ量は、一般に (HR * VR)/1024 をキロバイト単位に切り上 げた量が必要です(この例ではちょうど 768K になるでしょう)。例を挙げれば、 (936 * 702)/1024 = 642K バイトとなります。したがって、1M バイトのメモ リがあれば、余った分を仮想スクリーンのスクロールに割り当てられます。 <!--O However, if you only have 512K on board yor video card, then you won't be able to use this resolution. Even if you have a good monitor, without enough video RAM, you can't take advantage of your monitor's potential. On the other hand, if your SVGA has one meg, but your monitor can display at most 800x600, then high resolution is beyond your reach anyway (see <ref id="inter" name="Using Interlaced Modes"> for a possible remedy). --> ところが、ビデオカードに 512K しかメモリがなければこの解像度は使えませ ん。良いモニタを持っていたとしても、十分なビデオメモリがなければモニタ の性能を活かすことはできません。その逆に、SVGA カードが 1M バイトのメ モリを持っていたとしても、モニタが最高で 800x600 しか表示できないなら ば、これ以上の高解像度はどうやっても無理というものです(可能な対策につ いては <ref id="inter" name="インタレースモードを使用する">を見てくだ さい)。 <!--O Don't worry if you have more memory than required; XFree86 will make use of it by allowing you to scroll your viewable area (see the Xconfig file documentation on the virtual screen size parameter). Remember also that a card with 512K bytes of memory really doesn't have 512,000 bytes installed, it has 512 x 1024 = 524,288 bytes. --> 必要量よりもメモリがたくさんあっても心配ありません。XFree86 は余った メモリを利用して表示領域をスクロールできるようにします (仮想スクリーン の大きさのパラメータに関する Xconfig ファイルの文書を参照してください)。 また、512K バイトのメモリを搭載したカードには 512,000 バイトではなく、 実は 512 x 1024 =524,288 バイトのメモリが搭載されていることを覚えてお いてください。 <!--O If you're running X/Inside using an S3 card, and are willing to live with 16 colors (4 bits per pixel), you can set depth 4 in Xconfig and effectively double the resolution your card can handle. S3 cards, for example, normally do 1024x768x256. You can make them do 1280x1024x16 with depth 4. --> S3 カードで X/Inside が動作していて、かつ 16 色(1 ピクセル当たり 4 ビット) の場合、Xconfig ファイルで 深度 4 と設定すれば、カードが扱える解像度を 倍にできます。例えば、S3 カードは通常 1024x768x256(1024x768 の解像度で 256 色)ですが、深度 4 にすれば 1280x1024x16(1280x1024 の解像度で 16 色) が使えるようになります。 [訳注: 深度(depth)とは色数やグレースケールを表現するビット数です。] <!--O <sect>Computing Frame Sizes<label id="frame"> --> <sect>フレームサイズの計算<label id="frame"> <p> <!--O Warning: this method was developed for multisync monitors. It will probably work with fixed-frequency monitors as well, but no guarantees! --> 警告: この方法はマルチシンクモニタのために開発しました。固定周波数の モニタでもこの方法はうまく使えると思いますが保証はできません。 <!--O Start by dividing DCF by your highest available HSF to get a horizontal frame length. --> 最初に最大の使用可能な HSF で DCF を割って、水平走査可能回数を 計算してください。 <!--O For example; suppose you have a Sigma Legend SVGA with a 65MHz dot clock, and your monitor has a 55KHz horizontal scan frequency. The quantity (DCF / HSF) is then 1181 (65MHz = 65000KHz; 65000/55 = 1181). --> 例えば、65MHz のドットクロックの Sigma Legend SVGA カードと、55KHz の 水平走査周波数のモニタを使っていると仮定します。DCF / HSF を計算すると 1181 という量が得られます。 <!--O Now for our first bit of black magic. You need to round this figure to the nearest multiple of 8. This has to do with the VGA hardware controller used by SVGA and S3 cards; it uses an 8-bit register, left-shifted 3 bits, for what's really an 11-bit quantity. Other card types such as ATI 8514/A may not have this requirement, but we don't know and the correction can't hurt. So round the usable horizontal frame length figure down to 1176. --> さて、ここでついに黒魔術が出てきます。この式の答えをもっとも近い 8 の倍数に丸めてください。これは 8 ビットレジスタを持ち、左に 3 ビットずらして 11 ビットの値を得るような SVGA と S3 の VGA 制御装置において有効です。 ATI 8514/A のような他のカードではこのような要求はないかもしれませんが、我々は 正確な知識を持ち合わせてはいませんし、丸めによって不都合なことが生じること もありません。従って水平走査可能回数を 1176 に丸めます。 <!--O This figure (DCF / HSF rounded to a multiple of 8) is the minimum HFL you can use. You can get longer HFLs (and thus, possibly, more horizontal dots on the screen) by setting the sync pulse to produce a lower HSF. But you'll pay with a slower and more visible flicker rate. --> この数字(DCF / HSF を 8 の倍数に丸めたもの)は最小の HFL として使えます。 HSF がもっと低くなるように同期信号を設定すれば、HFL をもっと長くできます (したがって、多分画面の水平方向のドット数を増やせます)。しかし、その代 わりに速度は遅くなり、目に付くちらつきも増えるでしょう。 <!--O As a rule of thumb, 80% of the horizontal frame length is available for horizontal resolution, the visible part of the horizontal scan line (this allows, roughly, for borders and sweepback time -/- that is, the time required for the beam to move from the right screen edge to the left edge of the next raster line). In this example, that's 944 ticks. --> <!-- fujiwara: この先は岡本さんの元の訳をチェックしきれていません。 --> 経験的な法則では、水平フレーム長の 80% が水平解像度として使用可能で、水平 走査線の表示される部分(これは大体、境界と電子ビームが画面の右端から次の走 査線の左端へ戻ってくる時間を差し引いたもの)です。この例では、944 になりま す。 <!--O Now, to get the normal 4:3 screen aspect ratio, set your vertical resolution to 3/4ths of the horizontal resolution you just calculated. For this example, that's 708 ticks. To get your actual VFL, multiply that by 1.05 to get 743 ticks. --> さて、通常の画面のアスペクト比(横縦比)4:3 を得るため、今計算した水平解像 度の 3/4 になるように垂直解像度を設定しましょう。この例では、708 になりま す。実際の VFL を得るには、1.05 を掛けて 743 になります。 <!--O The 4:3 is not technically magic; nothing prevents you from using a different ratio if that will get the best use out of your screen real estate. It does make figuring frame height and frame width from the diagonal size convenient, you just multiply the diagonal by by 0.8 to get width and 0.6 to get height. --> 4:3 という比率は技術的な魔法ではありません。別の比率を使う方が画面の表 示部分をうまく使えるのであれば、この値にこだわる理由はありません。 これを使うとフレームの高さとフレームの幅を対角線の長さから求めるのが簡 単になります。つまり対角線の長さに 0.8 を掛けた値が幅であり、0.6 を掛 けた値が高さです。 <!--O So, HFL=1176 and VFL=743. Dividing 65MHz by the product of the two gives us a nice, healthy 74.4Hz refresh rate. Excellent! Better than VESA standard! And you got 944x708 to boot, more than the 800 by 600 you were probably expecting. Not bad at all! --> 結局、HFL=1176 と VFL=743 としました。65MHz をこの 2 つの数字の積で割ると、 十分に高くて健康に良い 74.4Hz のリフレッシュレートが得られます。素晴らしい! VESA 標準より立派でしょう! おまけに、おそらく予想していた 800x600 よりも 高い 944x708 という解像度が得られたのです。本当に素晴らしい! <!--O You can even improve the refresh rate further, to almost 76 Hz, by using the fact that monitors can often sync horizontally at 2khz or so higher than rated, and by lowering VFL somewhat (that is, taking less than 75% of 944 in the example above). But before you try this "overdriving" maneuver, if you do, make <em>sure</em> that your monitor electron guns can sync up to 76 Hz vertical. (the popular NEC 4D, for instance, cannot. It goes only up to 75 Hz VSF). (See <ref id="overd" name="Overdriving Your Monitor"> for more general discussion of this issue. ) --> さらに(大体 76 Hz まで)リフレッシュレートを改良することも可能です。 これには、定格よりも 2 KHz くらい高い水平同期周波数でも動くモニタが多 いという事実と、VFL を幾らか下げる(つまり、上の例で言うと 944 の 75% よりも小さくする)ことを利用します。しかしこの「オーバードライブ」作戦 を試してみる前に、あなたのモニタの電子銃が垂直同期を 76 Hz 以上にでき ることを<em>確認</em>してください。(例えば、人気のある NEC 4D ではこれ はできません。これは 75 Hz までの VSF しか使えません。) <!--O So far, most of this is simple arithmetic and basic facts about raster displays. Hardly any black magic at all! --> 以上が、ラスタ表示についての単純な計算と基本的事項のほとんど全てです。 黒魔術というほどのものでもないですね! <!--O <sect>Black Magic and Sync Pulses<label id="magic"> --> <sect> 黒魔術と同期信号 <p> <!--O OK, now you've computed HFL/VFL numbers for your chosen dot clock, found the refresh rate acceptable, and checked that you have enough VRAM. Now for the real black magic -/- you need to know when and where to place synchronization pulses. --> さあ、自分で選んだドットクロック対応に計算した HFL/VFL の数字があり、 無難なリフレッシュレートが見つかり、十分な VRAM(ビデオメモリ)があるこ とを確認しました。これからが本当の黒魔術です ―― いつどこで同期信号を出 すかを知る必要があります。 <!--O The sync pulses actually control the horizontal and vertical scan frequencies of the monitor. The HSF and VSF you've pulled off the spec sheet are nominal, approximate maximum sync frequencies. The sync pulse in the signal from the adapter card tells the monitor how fast to actually run. --> 同期信号が実際にモニタの水平及び垂直の走査周波数を制御しています。仕様表 から引っぱり出してきた HSF と VSF は定格上の最大同期周波数の推定値です。ア ダプタカードからの信号の中の同期信号はモニタにどれくらい速く実際に動作す るか伝えます。 <!--O Recall the two pictures above? Only part of the time required for raster-scanning a frame is used for displaying viewable image (ie. your resolution). --> 上記の 2 つの絵を思い出してください。目に見える画像(あなたの選んだ解像度) を表示するために使われるのは、フレームをラスタ走査するために必要な時間の 一部だけです。 <!--O <sect1>Horizontal Sync: --> <sect1>水平同期: <p> <!--O By previous definition, it takes HFL ticks to trace the a horizontal scan line. Let's call the visible tick count (your horizontal screen resolution) HR. Then Obviously, HR < HFL by definition. For concreteness, let's assume both start at the same instant as shown below: --> 前の定義によれば、 1 本の水平走査線をたどるのには HFL 分の時間掛かりま す。表示される部分のクロック回数(水平スクリーン解像度)を HR と呼びましょ う。その時は明らかに、定義から HR < HFL となります。具体的に両方が 同時に開始したと仮定して次に示します: <verb> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 ^ ^ 単位: 水平クロック | ^ ^ | HR | | HFL | |<----->| | |<->| HSP |<->| HGT1 HGT2 </verb> <!--O Now, we would like to place a sync pulse of length HSP as shown above, ie, between the end of clock ticks for display data and the end of clock ticks for the entire frame. Why so? because if we can achieve this, then your screen image won't shift to the right or to the left. It will be where it supposed to be on the screen, covering squarely the monitor's viewable area. --> ここで、上にあるように表示データのクロック終了とフレーム全体のクロック終了 の間に HSP の同期信号長を配置します。何故そうするのか？ それはこうすると、 画面表示が左右に移動しなくなるからです。表示をスクリーン上で表示されるべき 場所、つまりモニタの表示可能領域内にきっちりと収めるためです。 <!--O Furthermore, we want about 30 ticks of "guard time" on either side of the sync pulse. This is represented by HGT1 and HGT2. In a typical configuration HGT1 != HGT2, but if you're building a configuration from scratch, you want to start your experimentation with them equal (that is, with the sync pulse centered). --> その上、同期信号の両側に "保護時間" として約 30 クロック必要です。HGT1 と HGT2 で表わしています。一般的には HGT1 は HGT2 と等しくありませんが、しか し真っさらの状態から設定を行うならば、2 つを等しくして実験を始めたら良いで しょう(それは同期信号を中央に置くことになります)。 <!--O The symptom of a misplaced sync pulse is that the image is displaced on the screen, with one border excessively wide and the other side of the image wrapped around the screen edge, producing a white edge line and a band of "ghost image" on that side. A way-out-of-place vertical sync pulse can actually cause the image to roll like a TV with a mis-adjusted vertical hold (in fact, it's the same phenomenon at work). --> 同期信号の置き違えの症状は、1 つの境界が極端に広くなって画像の他の側が画面 の端から回り込んだり、白い端の線と"お化け画像"の帯になったり、画面の画像表 示のずれとして現われます。垂直同期信号抜けは垂直保持が調節不備になっている TV のように実際に縦スクロールします(事実、同じ現象が起こります)。 <!--O If you're lucky, your monitor's sync pulse widths will be documented on its specification page. If not, here's where the real black magic starts... --> 幸運ならば、モニタの同期信号の幅がその仕様書に記載されているでしょう。記 載がなければ、本当の黒魔術を始めることになります…。 <!--O You'll have to do a little trial and error for this part. But most of the time, we can safely assume that a sync pulse is about 3.5 to 4.0 microsecond in length. --> ここでは少し試行錯誤を行う必要があるでしょう。しかしほとんどの場合には、同 期信号を約 3.5 から 4.0 マイクロ秒と仮定すれば安全です。 <!--O For concretness again, let's take HSP to be 3.8 microseconds (which btw, is not a bad value to start with when experimenting). --> 具体的には、HSP を 3.8 マイクロ秒にしましょう(この値は実験を始めるに当た っては悪い値ではありません)。 <!--O Now, using the 65Mhz clock timing above, we know HSP is equivalent to 247 clock ticks (= 65 * 10**6 * 3.8 * 10^-6) [recall M=10^6, micro=10^-6] --> さて、先ほど 65MHz をクロックに使いましたから、HSP を 247 クロック分と等し くすればよいことがわかります。( 247 = 65x10**6 * 3.8 *10**(-6)) [メガ=10**6, マイクロ=10**(-6) である事を思い出してください] <!--O Some makers like to quote their horizontal framing parameters as timings rather than dot widths. You may see the following terms: --> メーカーによっては、ドット幅ではなく水平方向のフレームパラメータを好ん で使います。次の用語をご覧ください: <descrip> <!--O <tag/active time (HAT)/ Corresponds to HR, but in milliseconds. HAT * DCF = HR.<p> --> <tag/稼働時間(active time, HAT)/ ミリ秒に換算した HR に相当。HAT * DCF = HR<p> <!--O <tag/blanking time (HBT)/ Corresponds to (HFL - HR), but in milliseconds. HBT * DCF = (HFL - HR).<p> --> <tag/空白時間(blanking time, HBT)/ ミリ秒に換算した (HFL - HR) に相当。HBT * DCF = (HFL - HR)<p> <!--O <tag/front porch (HFP)/ This is just HGT1.<p> --> <tag/フロントポーチ(front porch, HFP)/ まさしく HGT1 です.<p> <!--O <tag/sync time/ This is just HSP.<p> --> <tag/同期時間(sync time)/ まさしく HSP です。<p> <!--O <tag/back porch (HBP)/ This is just HGT2.<p> --> <tag/バックポーチ(back porch, HBP)/ まさしく HGT2 です. </descrip> <!--O <sect1>Vertical Sync: --> <sect1>垂直同期: <p> <!--O Going back to the picture above, how do we place the 247 clock ticks as shown in the picture? --> 前の絵に戻って、247 クロック分を絵の中でどのように置いたらいいでしょう? <!--O Using our example, HR is 944 and HFL is 1176. The difference between the two is 1176 - 944=232 < 247! Obviously we have to do some adjustment here. What can we do? --> この例では、HR は 944 で HFL は 1176 です。この 2 つの例の差は 1176-944=232 < 247です! 明らかにこの違いを調整しなければいけません。何が できるでしょうか? <!--O The first thing is to raise 1176 to 1184, and lower 944 to 936. Now the difference = 1184-936= 248. Hmm, closer. --> 最初に 1176 は 1184 へ上げて、 944 は 936 へ下げてください。これで違い が 1184-936= 248 になりました。うん、近づいてきましたね。 <!--O Next, instead using 3.8, we use 3.5 for calculating HSP; then, we have 65*3.5=227. Looks better. But 248 is not much higher than 227. It's normally necessary to have 30 or so clock ticks between HR and the start of SP, and the same for the end of SP and HFL. AND they have to be multiple of eight! Are we stuck? --> 次は HSP を計算するのに 3.8 の代わりに、3.5 を使うようにすると、 65*3.5=227 となります。かなり良くなりました。しかし 248 は 227 よりそれほ ど大きくありません。HR と SP の開始点の間と SP の終了点と HFL の間に 30 か それぐらいあける必要があります。そして、それらは 8 の倍数にしなければなり ません! 我々はここで行き詰まってしまったのでしょうか? <!--O No. Let's do this, 936 % 8 = 0, (936 + 32) % 8 = 0 too. But 936 + 32 = 968, 968 + 227 = 1195, 1195 + 32 = 1227. Hmm.. this looks not too bad. But it's not a multiple of 8, so let's round it up to 1232. --> いいえ、こうしてみましょう。936 % 8 = 0 ですし、 (936 + 32) % 8 = 0 です。 しかし、936 + 32 = 968, 968 + 227 = 1195, 1195 + 32 = 1227 となります。 ふむふむ、そんなに悪くはありません。しかし、8 の倍数にはなっていないの で、1232 に丸めてください。 <!--O But now we have potential trouble, the sync pulse is no longer placed right in the middle between h and H any more. Happily, using our calculator we find 1232 - 32 = 1200 is also a multiple of 8 and (1232 - 32) - 968 = 232 corresponding using a sync pulse of 3.57 microseconds long, still reasonable. --> しかし、同期信号を HR と HFL のちょうど真ん中に置けない問題が起こる可 能性があります。幸いにも、1232 - 32 = 1200 も 8 の倍数であることと、 (1232 - 32) - 968 = 232 は 3.57 マイクロ秒という妥当な長さの同期信号に 対応することが計算でわかります。 <!--O In addition, 936/1232 ~ 0.76 or 76%, still not far from 80%, so it should be all right. --> さらに、 936/1232 は大体 0.76 つまり 76%ですが、80% からそう 遠くないのでまあ大丈夫でしょう。 <!--O Furthermore, using the current horizontal frame length, we basically ask our monitor to sync at 52.7khz (= 65Mhz/1232) which is within its capability. No problems. --> その上、現在の水平フレーム長を使うなら、基本的にはモニタがその能力内で 52.7KHz(=65MHz/1232)において同期が取れるかどうか調べましょう。問題は無い でしょう。 <!--O Using rules of thumb we mentioned before, 936*75%=702, This is our new vertical resolution. 702 * 1.05 = 737, our new vertical frame length. --> 経験則から、上記の 936*75%=702 を新しい垂直解像度にしましょう。 702*1.05=737 が新しい垂直フレーム長になります。 <!--O Screen refresh rate = 65Mhz/(737*1232)=71.6 Hz. This is still excellent. --> 画面のリフレッシュレートは 65MHz/(737*1232)=71.6 Hz になります。 それでも十分素晴らしい値ですね。 <!--O Figuring the vertical sync pulse layout is similar: --> 同様に垂直同期信号の配置を図解します: <verb> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 VR VFL 単位: 垂直クロック ^ ^ ^ | | | |<->|<----->| VGT VSP </verb> <!--O We start the sync pulse just past the end of the vertical display data ticks. VGT is the vertical guard time required for the sync pulse. Most monitors are comfortable with a VGT of 0 (no guard time) and we'll use that in this example. A few need two or three ticks of guard time, and it usually doesn't hurt to add that. --> 垂直表示データの終了時きっかりに同期信号を発信します。VGT は同期信号の垂直 保護時間です。ほとんどのモニタは VGT なし(保護時間なし)で快適に動作し、 例題でも保護時間なしです。2,3 クロックの保護時間が必要なものもありますが、 保護時間を入れて不都合が生じることは普通ありません。 <!--O Returning to the example: since by the defintion of frame length, a vertical tick is the time for tracing a complete HORIZONTAL frame, therefore in our example, it is 1232/65Mhz=18.95us. --> 例題に戻りましょう: フレーム長の定義から、垂直クロックは全<em>水平</em>フレー ムを辿る時間ですので、例題では 1232/65MHz=18.95 マイクロ秒になります。 <!--O Experience shows that a vertical sync pulse should be in the range of 50us and 300us. As an example let's use 150us, which translates into 8 vertical clock ticks (150us/18.95us~8). --> 実験によれば垂直同期のパルス幅は 50 マイクロ秒から 300 マイクロ秒の範囲に 設定すべきです。例題では 8 垂直クロック分、150 マイクロ秒を使用します (150 マイクロ秒 / 18.95 マイクロ秒 ~ 8)。 <!--O Some makers like to quote their vertical framing parameters as timings rather than dot widths. You may see the following terms: --> メーカーによっては、ドット幅ではなく垂直方向のフレームパラメータを好ん で使います。次の用語をご覧ください: <descrip> <!--O <tag/active time (VAT)/ Corresponds to VR, but in milliseconds. VAT * VSF = VR. <tag/blanking time (VBT)/ Corresponds to (VFL - VR), but in milliseconds. VBT * VSF = (VFL - VR). <tag/front porch (VFP)/ This is just VGT. <tag/sync time/ This is just VSP. <tag/back porch (VBP)/ This is like a second guard time after the vertical sync pulse. It is often zero. --> <tag/稼働時間(active time, VAT)/ ミリ秒に換算した VR に相当。VAT * VSF = VR <tag/空白時間(blanking time, VBT)/ ミリ秒に換算した (VFL - VR) に相当。VBT * VSF = (VFL - VR) <tag/フロントポーチ(front porch, VFP)/ まさしく VGT です。 <tag/同期時間(sync time)/ まさしく VSP です。 <tag/バックポーチ(back porch, VBP)/ 垂直同期信号の後の第 2 保護時間に似ています。しばしばゼロです。 </descrip> <!--O <sect>Putting it All Together<label id="synth"> --> <sect>全体のまとめ<label id="synth"> <p> <!--O The Xconfig file Table of Video Modes contains lines of numbers, with each line being a complete specification for one mode of X-server operation. The fields are grouped into four sections, the name section, the clock frequency section, the horizontal section, and the vertical section. --> Xconfig ファイルのビデオモード(Video Modes)表は数行の数列でできていて、 それぞれの行は X サーバが使用する 1 つのモードの完全な仕様を表わしていま す。その項目は名称セクション、ドットクロックセクション、水平セクション、 垂直セクションの 4 つのセクションに分けられます。 <!--O The name section contains one field, the name of the video mode specified by the rest of the line. This name is referred to on the "Modes" line of the Graphics Driver Setup section of the Xconfig file. The name field may be omitted if the name of a previous line is the same as the current line. --> 名称セクションは 1 項目からなり、その行の残りでビデオモードの名称を指 定します。この名称は、Xconfig ファイルのグラフィックスドライバ設定セク ションの "Modes" 行から参照されます。 現在の行が前の行と同じ名称ならば名称は省略できます。 <!--O The dot clock section contains only the dot clock (what we've called DCF) field of the video mode line. The number in this field specifies what dot clock was used to generate the numbers in the following sections. --> ドットクロックセクションには、ビデオモード行の項目に DCF と呼んでいた ドットクロックのみを書きます。次のセクションで作成する数字をドットクロッ クとしてこの項目に書きます。 <!--O The horizontal section consists of four fields which specify how each horizontal line on the display is to be generated. The first field of the section contains the number of dots per line which will be illuminated to form the picture (what we've called HR). The second field of the section (SH1) indicates at which dot the horizontal sync pulse will begin. The third field (SH2) indicates at which dot the horizontal sync pulse will end. The fourth field specifies the toal horzontal frame length (HFL). --> 水平セクションは 4 つの項目を含み、それぞれの水平線を画面の上でどのよ うに作成するかを記述します。最初の項目は、光を発して映像を構成する線 について、線ごとのドット数を示します(今まで HR と呼んでいたものです)。 2 番目の項目(SH1)はどのドットから水平同期信号が始まるかを示します。 3 番目の項目(SH2)はどのドットで水平同期信号が終わるかを示します。 4 番目の項目は全水平フレーム長(HFL)を指定します。 <!--O The vertical section also contains four fields. The first field contains the number of visible lines which will appear on the display (VR). The second field (SV1) indicates the line number at which the vertical sync pulse will begin. The third field (SV2) specifies the line number at which the vertical sync pulse will end. The fourth field contains the total vertical frame length (VFL). --> 垂直セクションも 4 項目からなります。最初の項目には画面上に表示される 走査線の数を書きます (VR)。 2 番目の項目(SV1)には垂直同期信号が何番目 の線から始まるかを書きます。3 番目の項目(SV2)には垂直同期信号が何番目 の線で終わるかを書きます。 4 番目の項目には全垂直フレーム長を書きます(VFL)。 <!--O Example: --> 指定例: <tscreen><verb> #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 </verb></tscreen> <!--O (Note: stock X11R5 doesn't support fractional dot clocks.) --> (注意: 標準的な X11R5 そのままでは 小数のドットクロックは使えません。) <!--O For Xconfig, all of the numbers just mentioned - the number of illuminated dots on the line, the number of dots separating the illuminated dots from the beginning of the sync pulse, the number of dots representing the duration of the pulse, and the number of dots after the end of the sync pulse - are added to produce the number of dots per line. The number of horizontal dots must be evenly divisible by eight. --> Xconfig では、線上で輝いているドットの数、輝いているドットから同期信号の開 始点までのドット数、同期信号の持続時間分のドット数と同期信号の終了点から後 のドット数、これらを足し合わせると 1 本当たりのドット数が計算できます。水平 方向のドット数は一律に 8 で割り切れる数値でなければいけません。 <!--O Example horizontal numbers: 800 864 1024 1088 --> 水平方向の数値の例: 800 864 1024 1088 <!--O This sample line has the number of illuminated dots (800) followed by the number of the dot when the sync pulse starts (864), followed by the number of the dot when the sync pulse ends (1024), followed by the number of the last dot on the horizontal line (1088). --> この例の数字は順に、輝いているドット数(800)、 同期開始点のドット(864)、 同期終了点のドット(1024)、 水平線の最後のドット(1088)となります。 <!--O Note again that all of the horizontal numbers (800, 864, 1024, and 1088) are divisible by eight! This is not required of the vertical numbers. --> 全ての水平方向の数字(800, 864, 1024, 1088)は 8 で割り切れる事にもう一 度注意してください。これは垂直方向の数字には当てはまりません。 <!--O The number of lines from the top of the display to the bottom form the frame. The basic timing signal for a frame is the line. A number of lines will contain the picture. After the last illuminated line has been displayed, a delay of a number of lines will occur before the vertical sync pulse is generated. Then the sync pulse will last for a few lines, and finally the last lines in the frame, the delay required after the pulse, will be generated. The numbers that specify this mode of operation are entered in a manner similar to the following example. --> 画面の上から下までの線の数がフレームを構成します。フレームの基本的な時間調 整は線で行ないます。線の多くは画像を表示するために使われます。最後の発光す る線を表示した後で、数本分遅延が挿入され、その後垂直同期信号が生成されます。 そして同期信号は数本分だけ持続し、フレームの最後に同期信号の後で必要な遅延 が生成されます。この動作モードを規定する数値は、次の例のように入力します。 <!--O Example vertical numbers: 600 603 609 630 --> 垂直方向の数値の例: 600 603 609 630 <!--O This example indicates that there are 600 visible lines on the display, that the vertical sync pulse starts with the 603rd line and ends with the 609th, and that there are 630 total lines being used. --> この例はディスプレイに 600 本の線が表示され、603 番目の線から垂直同期 が始まり 609 番目で終わる事、そして全部で 630 本の線を使用することを表 わしています。 <!--O Note that the vertical numbers don't have to be divisible by eight! --> 垂直方向の数値は 8 で割り切れる値でなくても構いません。 <!--O Let's return to the example we've been working. According to the above, all we need to do from now on is to write our result into Xconfig as follows: --> 例題に戻りましょう。上記によって、Xconfig へ書き込む必要な全ての値 は以下のようになります: <tscreen><verb> <name> DCF HR SH1 SH2 HFL VR SV1 SV2 VFL </verb></tscreen> <!--O where SH1 is the start tick of the horizontal sync pulse and SH2 is its end tick; similarly, SV1 is the start tick of the vertical sync pulse and SV2 is its end tick. --> ここで SH1 は水平同期信号の開始クロックで、SH2 はその終了クロックになり、 同様に SV1 は垂直同期信号の開始クロックで、SV2 はその終了クロックです。 <!--O To place these, recall the discussion of black magic and sync pulses given above. SH1 is the dot that begins the leading edge of the horiziontal sync pulse; thus, SH1 = HR + HGT1. SH2 is the trailing edge; thus, SH2 = SH1 + HSP. Similarly, SV1 = VR + VGT (but VGT is usually zero) and SV2 = SV1 + VSP. --> ここで、前述の「黒魔術と同期信号」の章の説明を思い出してください。SH1 は 水平同期信号の先頭側の端で始まるドットです。したがって SH1 = HR + HGT1 です。SH2 は末尾側の端です。したがって SH2 = SH1 + HSP です。同じように、SV1 = VR + VGT (ただし VGT は普通は 0 です)、SV2 = SV1 + VSP です。 <tscreen><verb> #name clock horizontal timing vertical timing flag 936x702 65 936 968 1200 1232 702 702 710 737 </verb></tscreen> <!--O No special flag necessary; this is a non-interlaced mode. Now we are really done. --> 特別なオプションは必要無く、これはノンインタレースモードで動作します。 これで完了しました。 <!--O <sect>Overdriving Your Monitor<label id="overd"> --> <sect>モニタの仕様外使用<label id="overd"> <p> <!--O You should absolutely <EM>not</EM> try exceeding your monitor's scan rates if it's a fixed-frequency type. You can smoke your hardware doing this! There are potentially subtler problems with overdriving a multisync monitor which you should be aware of. --> 固定周波数型のモニタの場合、モニタの規定走査周波数を超えては絶対に <EM>いけません</EM>。これをやってしまうと機器から煙が出てくるかもしれ ません! マルチシンクモニタでも、周波数を上げすぎると些細ながらいろいろ な問題が出る可能性がありますので、注意してください。 <!--O Having a pixel clock higher than the monitor's maximum bandwidth is rather harmless, in contrast. It's exceeding the rated maximum sync frequencies that's problematic. Some modern monitors might have protection circuitry that shuts the monitor down at dangerous scan rates, but don't rely on it. In particular there are older multisync monitors (like the Multisync II) which use just one horizontal transformer. These monitors will not have much protection against overdriving them. While you necessarily have high voltage regulation circuitry (which can be absent in fixed frequency monitors), it will not necessarily cover every conceivable frequency range, especially in cheaper models. This not only implies more wear on the circuitry, it can also cause the screen phosphors to age faster, and cause more than the specified radiation (including X-rays) to be emitted from the monitor. --> その逆に、モニタの最高周波数帯域より高いピクセルクロックを使っても比較 的安全です。問題を起こしやすいのは決められている最大同期周波数を超える ことです。最近のモニタの中には走査周波数が危険な値だとモニタを消す保護 回路を装備しているものもありますが、これを過信してはなりません。特に、 水平同期用のトランスを一つしか持っていない(Multisync II のような)古い マルチシンクモニタもあります。これらのモニタには仕様外使用に対する防御 機構はあまりありません。高電圧安定回路は確実に備わっていますが(固定周 波数のモニタにはないことがあります)、特に安いモニタでは、必ずしも考え られる全ての周波数帯域がカバーされているとは限りません。 このため、電子回路が早く傷むだけでなく、画面の発光体も早く傷み、規定以 上の(X 線を含む)放射線がモニタから放出されることになります。 <!-- (Note: the theoretical limit of discernable features is reached when the pixel clock reaches double the monitor's bandwidth. This is a straightforward application of Nyquist's Theorem: consider the pixels as a spatially distributed series of samples of the drive signals and you'll see why.) (注意: ピクセルクロックがモニタの帯域幅の倍になると、認識可能機能の 理論的な限界に達してしまいます。これは Nyquist の理論の単純な応用です: ピクセルを空間軸上に離散した駆動信号の標本系列と考えると、理由が分かる と思います。) Payne Freret wrote: Only if the monitor's video passband has the characteristic of a brick-wall filter with a cutoff frequency of one half the pixel rate would alternating black-and-white pixels merge to grey. The video passband of monitors is deliberately not a brick-wall filter (such a passband would produced undesirable ringing), and so pixels can still be discerned even when the pixel clock is twice the monitor's "bandwidth." An alternating black-white pixel stream would, for the most part, be filtered to a sine wave, but the individual pixels would still be discernible. Nyquist theory doesn't apply here, since we're talking video bandwidth and the continuous video signal was constructed before it got to the monitor. While one might argue that the CRT color-triads sample the video signal, this is a different issue. Moreover, the triad sampling rate is comparable to pixel spatial frequency, not to one-half the pixel spatial frequency. This empirical relationship is why, I suspect, one finds very high resolutions only on very big monitors. The practical limit of 0.23 to 0.28 triads/mm blurs very high resolution on small CRTs. Another importance of the bandwidth is that the monitor's input impedance is specified only for that range, and using higher frequencies can cause reflections probably causing minor screen interferences, and radio disturbance. 帯域についてもうひとつ大切なことは、モニタの入力インピーダンスはモニタの 帯域内だけで規定されているので、高い周波数を使うと反射が起こり、軽い 画面上の干渉と電波障害が起こる可能性があります。 Payne Freret wrote: From my experience as a designer monitors usually have a pretty constant input impedance comprising a simple resistive termination and some small unavoidable capacitance. The reason higher pixel rates seem to produce distortion is that higher pixel rates usually arise from operating at high screen resolution rather than operating at high refresh rates. When the monitor is operated at high screen resolution, the screen details are finer and reflections that arise from cable-monitor impedance mismatches or from lousy cables, and which were present even at lower screen resolutions, produce echos that constitute larger proportion of the finest detail. Consequently they are more conspicuous. --> <!--O However, the basic problematic magnitude in question here is the slew rate (the steepness of the video signals) of the video output drivers, and that is usually independent of the actual pixel frequency, but (if your board manufacturer cares about such problems) related to the maximum pixel frequency of the board. --> しかしながら、ここで問われている根本的な問題はビデオ出力ドライバ回路の スルーレート(ビデオ信号の立ち上がりの傾斜)です。このスルーレートは実際 のピクセル周波数と普通は無関係ですが、(ボードのメーカーがこのような問 題に注意を払っていれば)ボードの最大ピクセル周波数と関係があります。 <!--O So be careful out there... --> これらに注意しつつ作業をしましょう…。 <!--O <sect>Using Interlaced Modes<label id="inter"> --> <sect>インタレースモードを使用する<label id="inter"> <p> <!--O (This section is largely due to David Kastrup <dak@pool.informatik.rwth-aachen.de>) --> (この節はほとんど David Kastrup <dak@pool.informatik.rwth-aachen.de> によります) <!--O At a fixed dot clock, an interlaced display is going to have considerably less noticable flicker than a non-interlaced display, if the vertical circuitry of your monitor is able to support it stably. It is because of this that interlaced modes were invented in the first place. --> 固定のドットクロックでは、モニタの垂直同期回路が安定してサポート できるなら、ノンインタレース画面よりもインタレース画面 の方が目につくちらつきがかなり少なくなります。 インタレースモードが最初に開発されたのは、このためです。 <!--O Interlaced modes got their bad repute because they are inferior to their non-interlaced companions at the same vertical scan frequency, VSF (which is what is usually given in advertisements). But they are definitely superior at the same horizontal scan rate, and that's where the decisive limits of your monitor/graphics card usually lie. --> インタレースモードは、同じ垂直走査周波数 すなわちVSF(通常広告に良く使われて います) のノンインタレースモードの同等品より劣るという悪評をかっていました。 しかし、インタレースモードは同じ水平走査周波数では確実に優れていて、 普通はそこでモニタやグラフィックスボードの明白な限界が見えてくるものです。 <!--O At a fixed <EM>refresh rate</EM> (or half frame rate, or VSF) the interlaced display will flicker more: a 90Hz interlaced display will be inferior to a 90Hz non-interlaced display. It will, however, need only half the video bandwidth and half the horizontal scan rate. If you compared it to a non-interlaced mode with the same dot clock and the same scan rates, it would be vastly superior: 45Hz non-interlaced is intolerable. With 90Hz interlaced, I have worked for years with my Multisync 3D (at 1024x768) and am very satisfied. I'd guess you'd need at least a 70Hz non-interlaced display for similar comfort. --> 固定の<EM>リフレッシュレート</EM>(すなわちフレーム周波数の半分、つまり VSF)では、インタレースのディスプレイはちらつきがより多く見えます。 例えば、90Hz のインタレース表示は 90Hz の非インタレース表示より劣りま す。しかし、半分のビデオ信号帯域幅と半分の水平走査速度で済みます。 同じドットクロックと同じ走査速度でノンインタレース表示と比べたら、 インタレース表示の方がずっとよく見えるでしょう。45Hz の非インタレース 表示などは、お話になりません。私は、90Hz のインタレース(1024x768)で Multisync 3D を何年も使っており、たいへん満足しています。 同様な快適さを得るためには、最低 70Hz の非インタレース表示が必要だと思 います。 <!--O You have to watch a few points, though: use interlaced modes only at high resolutions, so that the alternately lighted lines are close together. You might want to play with sync pulse widths and positions to get the most stable line positions. If alternating lines are bright and dark, interlace will <EM>jump</EM> at you. I have one application that chooses such a dot pattern for a menu background (XCept, no other application I know does that, fortunately). I switch to 800x600 for using XCept because it really hurts my eyes otherwise. --> 注意が必要なこともいくつかあります。インタレースモードは高解像度でだけ使って、 一本おきの輝線がお互いに近くなるようにします。最も安定した線の位置を得るため に、同期信号の幅と位置をいじる必要があるかもしれません。 一本おきに線が明暗すると、インタレース表示は<EM>ぎらぎら</EM>して見えます。 私は、メニューの背景にそのようなドットパターンを選んだアプリケーション を一つ持っています(XCept, 幸いなことに他の私の知っているアプリケーション ではこのようなことをするものはありません)。私は、XCept を 使うときには 800x600 に切り替えます。というのも、そうしないと目を痛めて しまうからです。 <!--O For the same reason, use at least 100dpi fonts, or other fonts where horizontal beams are at least two lines thick (for high resolutions, nothing else will make sense anyhow). --> 同じ理由で、最低 100dpi のフォントを使うこと、または他のフォントでも 水平方向の線に最低 2 行分の厚みがあるフォントを使いましょう(高解像度の 場合には、他のどんな方法でもだめでしょう)。 <!--O And of course, never use an interlaced mode when your hardware would support a non-interlaced one with similar refresh rate. --> そしてもちろん、同じようなリフレッシュレートで非インタレースモードをサ ポートしている機器の時は、決してインタレースモードを使ってはいけません。 <!--O If, however, you find that for some resolution you are pushing either monitor or graphics card to their upper limits, and getting dissatisfactorily flickery or outwashed (bandwidth exceeded) display, you might want to try tackling the same resolution using an interlaced mode. Of course this is useless if the VSF of your monitor is already close to its limits. --> しかしながら、もしある解像度でモニタかグラフィックスカードのどちらか の上限に達してしまって不快なちらつきや色落ち(帯域幅を超えた時)表示 が起こったと思ったら、同じ解像度でインタレースモードを試してみるといいかも しれません。もちろん、これはモニタの VSF がすでに上限に近い場合は使えません。 <!--O Design of interlaced modes is easy: do it like a non-interlaced mode. Just two more considerations are necessary: you need an odd total number of vertical lines (the last number in your mode line), and when you specify the "interlace" flag, the actual vertical frame rate for your monitor doubles. Your monitor needs to support a 90Hz frame rate if the mode you specified looks like a 45Hz mode apart from the "Interlace" flag. --> インタレースモデルの設計は簡単です。ノンインタレースモードと同じように 考えましょう。2 つだけ追加の検討が必要です。まず、垂直線の総数 (モード行の最後の数値)を奇数にしなければなりません。 次に、"interlace" フラグを指定した時、 モニタに対する実際の垂直フレーム周波数が倍になることです。指定した モードが 45Hz のモードに見えるなら、"Interlace" フラグはさておいて、 モニタは 90Hz のフレーム周波数をサポートする必要があります。 <!--O As an example, here is my modeline for 1024x768 interlaced: my Multisync 3D will support up to 90Hz vertical and 38kHz horizontal. --> 例えば、1024x768 のインタレースモードのモード行の場合です。 Multisync 3D は 90Hz の垂直フレーム周波数と 38kHz の 水平フレーム 周波数までサポートします。 <tscreen><verb> ModeLine "1024x768" 45 1024 1048 1208 1248 768 768 776 807 Interlace </verb></tscreen> <!--O Both limits are pretty much exhausted with this mode. Specifying the same mode, just without the "Interlace" flag, still is almost at the limit of the monitor's horizontal capacity (and strictly speaking, a bit under the lower limit of vertical scan rate), but produces an intolerably flickery display. --> 両方のリミットは、このモードではほぼ限界です。同じモードを "Interlace" オプションをつけないで指定しても、既にモニタの水平 方向の能力のほとんど上限です(厳密に言えば、垂直走査周波数の下限を 少し下回ります)。しかし、耐えられないほどのちらつきを生じます。 <!--O Basic design rules: if you have designed a mode at less than half of your monitor's vertical capacity, make the vertical total of lines odd and add the "Interlace" flag. The display's quality should vastly improve in most cases. --> 基本的な設計ルールです。モニタの垂直容量の半分以下でのモード設計したことがあ れば、 垂直方向の線の合計を奇数にして "Interlace" オプションを追加 しましょう。ほとんどの場合、ディスプレイの品質は非常に向上するはずです。 <!--O If you have a non-interlaced mode otherwise exhausting your monitor's specs where the vertical scan rate lies about 30% or more under the maximum of your monitor, hand-designing an interlaced mode (probably with somewhat higher resolution) could deliver superior results, but I won't promise it. --> モニタの最大以下の垂直走査周波数より 30% ほど低い垂直走査周波数で、 モニタの仕様を上回らないように、止むを得ず ノンインタレースモードを使っている場合は、インタレースモードを手作りで 設計すると(多分、いくぶん高い解像度で)よりよい結果を得る ことができるかもしれませんが、約束はできません。 <!--O <sect>Questions and Answers<label id="answe"> --> <sect>質疑応答<label id="answe"> <p> <!--O Q. The example you gave is not a standard screen size, can I use it? --> Q. この文書の例は標準的な画面サイズではありませんが、使えますか？ <!--O A. Why not? There is NO reason whatsover why you have to use 640x480, 800x600, or even 1024x768. The XFree86 servers let you configure your hardware with a lot of freedom. It usually takes two to three tries to come up the right one. The important thing to shoot for is high refresh rate with reasonable viewing area. not high resolution at the price of eye-tearing flicker! --> A. 勿論です。640x480, 800x600 とか 1024x768 を使わなければならない理由 は全くありません。XFree86 のドライバはハードウェアを自由に設定できるよ うになっています。普通は 2, 3 回試してみれば正しい設定を見つけられます。 目指すべき重要なことは、高いリフレッシュレートで妥当な表示領域となるこ とです。涙目を誘うちらつきを代償にして高解像度を追求しないように! <!--O Q. It this the only resolution given the 65Mhz dot clock and 55Khz HSF? --> Q. 65MHz のドットクロックと 55KHz の HSF で得られる解像度はこれだけ ですか？ <!--O A. Absolutely not! You are encouraged to follow the general procedure and do some trial-and-error to come up a setting that's really to your liking. Experimenting with this can be lots of fun. Most settings may just give you nasty video hash, but in practice a modern multi-sync monitor is usually not damaged easily. Be sure though, that your monitor can support the frame rates of your mode before using it for longer times. --> A. 絶対そんなことはありません! 一般的な手順に従って作業を行い、本当に 好みの設定にたどり着くため、若干の試行の繰り返しをお勧めします。 実験 してみると結構楽しいものです。 ほとんどの設定ではビデオ表示が乱れてし まうかもしれませんが、経験上最近のマルチシンクモニタは普通、簡単には 壊れません。しかし、長時間モニタを使う前に、モニタがあなたのモードの フレーム周波数をサポートしていることを確認しましょう。 <!--O Beware fixed-frequency monitors! This kind of hacking around can damage them rather quickly. Be sure you use valid refresh rates for <EM>every</EM> experiment on them. --> 固定周波数のモニタには注意してください。この手のいじくりまわしは、 モニタを結構早く傷めることがあります。実験するときは<EM>毎回</EM> 有効なリフレッシュレート使っていることを確認しましょう。 <!--O Q. You just mentioned two standard resolutions. In Xconfig, there are many standard resolutions available, can you tell me whether there's any point in tinkering with timings? --> Q. 二つの標準的な解像度を記載してますね。Xconfig の中では色々標準的な 解像度がありますが、時間調節の数値を調整する場合のポイントを教えてくだ さい。 <!--O A. Absolutely! Take, for example, the "standard" 640x480 listed in the current Xconfig. It employes 25Mhz driving frequency, frame lengths are 800 and 525 => refresh rate ~ 59.5Hz. Not too bad. But 28Mhz is a commonly available driving frequency from many SVGA boards. If we use it to drive 640x480, following the procedure we discussed above, you would get frame lengths like 812 (round down to 808) and 505. Now the refresh rate is raised to 68Hz, a quite significant improvement over the standard one. --> A. 勿論教えましょう! 現在の Xconfig にある「標準的」な640x480 を例題 に取り上げます。この場合、動作周波数が 25MHz 、フレーム長が 800 と 525 の時に約 59.5Hz の画面リフレッシュレートが使えます。 悪く無いでしょう? しかし、28MHz は一般的に多くの SVGA ボードで使える動作周波数です。 28MHz で 640x480 を使う場合、以前に説明した手順に従えば、フレーム長は 812(808 に丸められます)や 505 が得られるでしょう。ここでリフレッシュレート は 68MHz まで引き上げられ、標準値よりもずっと良い値になります。 <!--O Q. Can you summarize what we have discussed so far? --> Q. 今までの議論をまとめてもらえますか? <!--O A. In a nutshell: --> A. 要約します: <enum> <item> <!--O for any fixed driving frequency, raising max resolution incurs the penalty of lowering refresh rate and thus introducing more flicker. --> 任意の固定の動作周波数では、最高の解像度に高めればリフレッシュレートを 下げなければならず、したがってちらつきが増えるでしょう。 <item> <!--O if high resolution is desirable and your monitor supports it, try to get a SVGA card that provides a matching dot clock or DCF. The higher, the better! --> 高解像度を希望しモニタがそれをサポートするときは、それに合うドッ トクロック、つまり DCF を供給する SVGA カードを手に入れてください。 ドットクロックは高いに越したことはありません。 </enum> <!--O <sect>Fixing Problems with the Image.<label id="fixes"> --> <sect>画像表示の問題修正<label id="fixes"> <p> <!--O OK, so you've got your X configuration numbers. You put them in Xconfig with a test mode label. You fire up X, hot-key to the new mode, ... and the image doesn't look right. What do you do? Here's a list of common <idx>video image distortions</idx> and how to fix them. --> さあ、 X の構成定義の数値を手に入れました。XF86Config に その数値をテスト 中のコメントをつけて書きました。X を立ちあげ、ホットキーで新しいモード に切り替えてみました…しかし画像が変です。こういう場合、どうすればいい のでしょう？ 一般的な<idx>ビデオ画像歪みの問題</idx>と解決策をここに挙 げます。 <!--O (Fixing these minor distortions is where <bf>xvidtune</bf>(1) really shines.) --> (小さな歪みの修正において <bf>xvidtune</bf>(1) が秀でています。) <!--O You <em>move</em> the image by changing the sync pulse timing. You <em>scale</em> it by changing the frame length (you need to move the sync pulse to keep it in the same relative position, otherwise scaling will move the image as well). Here are some more specific recipes: --> 同期パルスを調整して画像を<EM>移動</EM>してみてください。フレーム長を変え て画像を<EM>拡大・縮小</EM>してください(相対的な位置をそのままに同期信号を移動 する必要があります。そうしないと拡大縮小と同時に画像の移動も起こってし まいます)。もう少し個別の対処方法を次に示します: <!--O The horizontal and vertical positions are independent. That is, moving the image horizontally doesn't affect placement vertically, or vice-versa. However, the same is not quite true of scaling. While changing the horizontal size does nothing to the vertical size or vice versa, the total change in both may be limited. In particular, if your image is too large in both dimensions you will probably have to go to a higher dot clock to fix it. Since this raises the usable resolution, it is seldom a problem! --> 水平と垂直の表示位置は独立しています。これは画像を水平に移動させても垂 直位置には影響がなく、また逆も同じということです。ところが拡大・縮小では 必ずしもそうではありません。水平方向の大きさを変えても垂直方向の大きさ には何も影響を与えず、逆も同じですが、縦横両方の変更量の合計は限定され ています。特に、縦横に大き過ぎた場合はより高いドットクロックに変更して 修正する必要があるでしょう。使用可能な解像度を引き上げることになるた め、これはめったに問題とはなりません。 <!--O <sect1>The image is displaced to the left or right --> <sect1>画像が左か右にずれている場合 <p> <!--O To fix this, move the horizontal sync pulse. That is, increment or decrement (by a multiple of 8) the middle two numbers of the horizontal timing section that define the leading and trailing edge of the horizontal sync pulse. --> これを修正するために水平同期信号を移動しましょう。すなわち、水平同期信号の 開始端と終了端を定義している水平調整部分の真ん中の 2 つの数値を (8 の倍数ずつ)増減させて行います。 <!--O If the image is shifted left (right border too large, you want to move the image to the right) decrement the numbers. If the image is shifted right (left border too large, you want it to move left) increment the sync pulse. --> 画像が左にずれている(右の縁の部分が大きすぎて、右へ画像を移動したい) 時は、数値を増やしてください。画像が右にずれている(左の縁の部分が大き すぎて、左へ画像を移動したい)時は、同期信号を減らしてください。 <!--O <sect1>The image is displaced up or down --> <sect1>画像が上下にずれている場合 <p> <!--O To fix this, move the vertical sync pulse. That is, increment or decrement the middle two numbers of the vertical timing section that define the leading and trailing edge of the vertical sync pulse. --> これを修正するために垂直同期信号を移動してください。すなわち、垂直同期信号 の開始端と終了端を定義している垂直調整部分の真ん中の 2 つの数値 を増減させて行います。 <!--O If the image is shifted up (lower border too large, you want to move the image down) decrement the numbers. If the image is shifted down (top border too large, you want it to move up) increment the numbers. --> 画像が上にずれている(下の縁の部分が大きすぎて、下に画像を移動したい) 時は、数値を減らしてください。画像が下にずれている(上の縁の部分が大き すぎて、上へ画像を移動したい)時は、数値を増やしてください。 <!--O <sect1>The image is too large both horizontally and vertically --> <sect1>画像が垂直と水平の両方に膨らんでいる場合 <p> <!--O Switch to a higher card clock speed. If you have multiple modes in your clock file, possibly a lower-speed one is being activated by mistake. --> より高いカードクロックに切り替えましょう。クロックファイルに複数の モードがある場合、低い方の速度のモードに間違って作動させている 可能性があります。 <!--O <sect1>The image is too wide (too narrow) horizontally --> <sect1>画像が水平方向に広すぎる(狭すぎる)場合 <p> <!--O To fix this, increase (decrease) the horizontal frame length. That is, change the fourth number in the first timing section. To avoid moving the image, also move the sync pulse (second and third numbers) half as far, to keep it in the same relative position. --> これを修正するためには水平フレーム長を増やし(減らし)てください。すなわち、 最初の調整部分の 4 番目の数値を変えて行います。画像が移動するのを回 避するため、同期信号(2 番目と 3 番目の数値)もその半分だけ移動し、同 じ相対位置を保存しておいてください。 <!--O <sect1>The image is too deep (too shallow) vertically --> <sect1>画像が垂直方向に膨らんでいる(細くなっている)場合 <p> <!--O To fix this, increase (decrease) the vertical frame length. That is, change the fourth number in the second timing section. To avoid moving the image, also move the sync pulse (second and third numbers) half as far, to keep it in the same relative position. --> これを修正するためには垂直フレーム長を減らし(増やし)てください。それ は 2 番目の調整部分の 4 番目の数値を変えて行います。画像が移動するのを 回避するため、同期信号(2 番目と 3 番目の数値で)もその半分だけ移動 し、同じ相対位置を保存しておいてください。 <!--O Any distortion that can't be handled by combining these techniques is probably evidence of something more basically wrong, like a calculation mistake or a faster dot clock than the monitor can handle. --> これらの技術の組合せでも取れない他の歪みは多分もっと基本的な部分が違っ ている、例えば計算違いとかモニタで使えない高いドットクロックを使って いるような場合があります。 <!--O Finally, remember that increasing either frame length will decrease your refresh rate, and vice-versa. --> 最後に、フレーム長のどちらかの数値を増やせばリフレッシュレートが低下し てしまうこと、またその逆も言えることを覚えておいてください。 <!--O Occasionally you can fix minor distortions by fiddling with the picture controls on your monitor. The disadvantage is that if you take your controls too far off the neutral (factory) setting to fix graphics-mode problems, you may end up with a wacky image in text mode. It's better to get your modeline right. --> 小さな歪みはモニタの画像制御をいじれば直ることもあります。この方法の短 所は、グラフィックスモードの問題を直すために自然な設定(工場出荷時の設 定)から離れすぎてしまうと、テキストモードの画面が変になってしまうこと です。したがって、モード行を正しくする方がいいでしょう。 <!--O <sect>Plotting Monitor Capabilities<label id="cplot"> --> <sect>モニタの特性をプロットする<label id="cplot"> <p> <!--O To plot a monitor mode diagram, you'll need the gnuplot package (a freeware plotting language for UNIX-like operating systems) and the tool <TT>modeplot</TT>, a shell/gnuplot script to plot the diagram from your monitor characteristics, entered as command-line options. --> モニタモードダイアグラムをプロットするには、gnuplot パッケージ(UNIX のようなオペレーティングシステム用のフリーウェアのプロット言語)と コマンドラインから入力したモニタの特性から gnuplot で ダイアグラムを プロットする shell スクリプトである <TT>modeplot</TT> ツールが必要です。 <!--O Here is a copy of <tt>modeplot</tt>: --> modeplot のリストを示します: <verb> #!/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 <<EOF modeplot control switches: -t "<description>" name of monitor defaults to "Viewsonic 21PS" -b <nn> bandwidth in MHz defaults to 185 -h <min> <max> min & max HSF (kHz) defaults to 31 85 -v <min> <max> min & max VSF (Hz) defaults to 50 160 -a <aspect ratio> aspect ratio defaults to 4/3 -g "<options>" 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 <esr@thyrsus.com> based on analysis and scratch code by Martin Lottermoser <Martin.Lottermoser@mch.sni.de> This is modeplot $Revision: 1.7 $ EOF exit;; esac shift done gnuplot $GNUOPTS <<EOF set title "$TITLE Mode Plot" # Magic numbers. Unfortunately, the plot is quite sensitive to changes in # these, and they may fail to represent reality on some monitors. We need # to fix values to get even an approximation of the mode diagram. These come # from looking at lots of values in the ModeDB database. F1 = 1.30 # multiplier to convert horizontal resolution to frame width F2 = 1.05 # multiplier to convert vertical resolution to frame height # Function definitions (multiplication by 1.0 forces real-number arithmetic) ac = (1.0*$ASPECT)*F1/F2 refresh(hsync, dcf) = ac * (hsync**2)/(1.0*dcf) dotclock(hsync, rr) = ac * (hsync**2)/(1.0*rr) resolution(hv, dcf) = dcf * (10**6)/(hv * F1 * F2) # Put labels on the axes set xlabel 'DCF (MHz)' set ylabel 'RR (Hz)' 6 # Put it right over the Y axis # Generate diagram set grid set label "VB" at $BANDWIDTH+1, ($MAXVSF + $MINVSF) / 2 left set arrow from $BANDWIDTH, $MINVSF to $BANDWIDTH, $MAXVSF nohead set label "max VSF" at 1, $MAXVSF-1.5 set arrow from 0, $MAXVSF to $BANDWIDTH, $MAXVSF nohead set label "min VSF" at 1, $MINVSF-1.5 set arrow from 0, $MINVSF to $BANDWIDTH, $MINVSF nohead set label "min HSF" at dotclock($MINHSF, $MAXVSF+17), $MAXVSF + 17 right set label "max HSF" at dotclock($MAXHSF, $MAXVSF+17), $MAXVSF + 17 right set label "VESA $vesa" at 1, $vesa-1.5 set arrow from 0, $vesa to $BANDWIDTH, $vesa nohead # style -1 plot [dcf=0:1.1*$BANDWIDTH] [$MINVSF-10:$MAXVSF+20] \ refresh($MINHSF, dcf) notitle with lines 1, \ refresh($MAXHSF, dcf) notitle with lines 1, \ resolution(640*480, dcf) title "640x480 " with points 2, \ resolution(800*600, dcf) title "800x600 " with points 3, \ resolution(1024*768, dcf) title "1024x768 " with points 4, \ resolution(1280*1024, dcf) title "1280x1024" with points 5, \ resolution(1600*1280, dcf) title "1600x1200" with points 6 pause 9999 EOF </verb> <!--O Once you know you have <tt>modeplot</tt> and the gnuplot package in place, you'll need the following monitor characteristics: --> <TT>modeplot</TT> を持っていることと gnuplot パッケージがある場所を 確認したら、次に述べるモニタの特性値が必要です: <!--O <itemize> <item> video bandwidth (VB) <item> range of horizontal sync frequency (HSF) <item> range of vertical sync frequency (VSF) </itemize> --> <itemize> <item> ビデオ帯域幅 (VB) <item> 水平同期周波数の範囲 (HSF) <item> 垂直同期周波数の範囲 (VSF) </itemize> <!--O The plot program needs to make some simplifying assumptions which are not necessarily correct. This is the reason why the resulting diagram is only a rough description. These assumptions are: --> プロットプログラムは、必ずしも正確とは限らない簡素化のための幾つかの仮説を 必要とします。得られたダイアグラムが大まかな記述しかないのはこのためです。 これらの仮定とは: <enum> <!--O <item> All resolutions have a single fixed aspect ratio AR = HR/VR. Standard resolutions have AR = 4/3 or AR = 5/4. The <TT>modeplot</TT> programs assumes 4/3 by default, but you can override this. --> <item> 全ての解像度は、たった一つの固定された縦横比 AR = HR/VR を使ってい ます。 標準的な解像度では AR = 4/3 または AR = 5/4です。<TT>modeplot</TT> プログラムは標準で 4/3 を仮定していますが、変更可能です。 <!--O <item> For the modes considered, horizontal and vertical frame lengths are fixed multiples of horizontal and vertical resolutions, respectively: --> <item> 考慮されたモードでは、水平と垂直のフレーム長は水平と垂直の解像度の 固定の倍数に調整されていますので、それぞれ次のようになります: <tscreen><verb> HFL = F1 * HR VFL = F2 * VR </verb></tscreen> </enum> <!--O As a rough guide, take F1 = 1.30 and F2 = 1.05 (see <ref id=frame> "Computing Frame Sizes"). --> 大まかな規準として、F1 = 1.30 と F2 = 1.05 としてください (<label id=frame>"フレームサイズの計算"を参照してください)。 <!--O Now take a particular sync frequency, HSF. Given the assumptions just presented, every value for the clock rate DCF already determines the refresh rate RR, i.e. for every value of HSF there is a function RR(DCF). This can be derived as follows. --> さて、ある特定の同期周波数すなわち HSF を取り上げてみます。現在の仮定 では、それぞれのドットクロック DCF の値が既にリフレッシュレート RR を 決定しています。すなわち、HSF の全ての値に対して、関数 RR(DCF)が存在す るということです。これば次のようにして得られます。 <!--O The refresh rate is equal to the clock rate divided by the product of the frame sizes: --> リフレッシュレートはフレームサイズの積でドットクロックを割ったものです: <tscreen><verb> RR = DCF / (HFL * VFL) (*) </verb></tscreen> <!--O On the other hand, the horizontal frame length is equal to the clock rate divided by the horizontal sync frequency: --> 一方、水平フレーム長はドットクロックを水平同期周波数で割ったものに等しくなり ます: <tscreen><verb> HFL = DCF / HSF (**) </verb></tscreen> <!--O VFL can be reduced to HFL be means of the two assumptions above: --> 前述の 2 つの仮定に基づけば、VFL の値は HFL の値まで減らせます: <tscreen><verb> VFL = F2 * VR = F2 * (HR / AR) = (F2/F1) * HFL / AR (***) </verb></tscreen> <!--O Inserting (**) and (***) into (*) we obtain: --> (**) と (***) を (*) に代入すると以下の結果が得られます: <tscreen><verb> RR = DCF / ((F2/F1) * HFL**2 / AR) = (F1/F2) * AR * DCF * (HSF/DCF)**2 = (F1/F2) * AR * HSF**2 / DCF </verb></tscreen> <!--O For fixed HSF, F1, F2 and AR, this is a hyperbola in our diagram. Drawing two such curves for minimum and maximum horizontal sync frequencies we have obtained the two remaining boundaries of the permitted region. --> HSF, F1, F2 と AR を固定すると、ダイアグラムは双曲線になります。この曲線 の中の最小と最大の水平同期周波数で許容領域の残りの境界線が得られます。 <!--O The straight lines crossing the capability region represent particular resolutions. This is based on (*) and the second assumption: --> 特性領域と直線の交線が特定の解像度を表します。これは (*) 式と 2 番目の仮定に基づきます: <tscreen><verb> RR = DCF / (HFL * VFL) = DCF / (F1 * HR * F2 * VR) </verb></tscreen> <!--O By drawing such lines for all resolutions one is interested in, one can immediately read off the possible relations between resolution, clock rate and refresh rate of which the monitor is capable. Note that these lines do not depend on monitor properties, but they do depend on the second assumption. --> 使いたい全ての解像度でこのような線を描くことによって、解像度、 クロック周波数とモニタがサポートできるリフレッシュレートの間に関係があ るだろうということがすぐにわかります。これらの線はモニタの特性には依存 していませんが、2 つ目の仮定には依存しています。 <!--O The <TT>modeplot</TT> tool provides you with an easy way to do this. Do <TT>modeplot -?</TT> to see its control options. A typical invocation looks like this: --> <TT>modeplot</TT> ツールはこの作業を簡単にします。<TT>modeplot -?</TT> と入力して制御オプションを見てください。典型的な実行形式は以下のように なります: <tscreen><verb> modeplot -t "Swan SW617" -b 85 -v 50 90 -h 31 58 </verb></tscreen> <!--O The -b option specifies video bandwidth; -v and -h set horizontal and vertical sync frequency ranges. --> -b オプションはビデオの帯域幅を指定します。-v と -h は水平と垂直同期 周波数の範囲を指定します。 <!--O When reading the output of <TT>modeplot</TT>, always bear in mind that it gives only an approximate description. For example, it disregards limitations on HFL resulting from a minimum required sync pulse width, and it can only be accurate as far as the assumptions are. It is therefore no substitute for a detailed calculation (involving some black magic) as presented in <ref id="synth" name="Putting it All Together">. However, it should give you a better feeling for what is possible and which tradeoffs are involved. --> <TT>modeplot</TT> の出力を読むときは、近似表現のみであることを常に 覚えておいてください。例えば、最小同期信号幅から得られた HFL の上限を 無視しますし、仮定が正しい限りにおいてしか正確ではありません。従って <ref id="synth" name="全体のまとめ"> に示してある(いくつかの黒魔術を含んだ)詳細な計算式の代わりにはなりません。 しかしながら、何が可能であるか、あるいはどんなトレードオフがあるかにつ いてはすっきりするはずです。 <!--O <sect>Credits<label id="credi"> --> <sect>協力者、提供者について<label id="credi"> <p> <!--O The original ancestor of this document was by Chin Fang <fangchin@leland.stanford.edu>. --> この文書の原型は Chin Fang <fangchin@leland.stanford.edu> が書き ました。 <!--O Eric S. Raymond <esr@snark.thyrsus.com> reworked, reorganized, and massively rewrote Chin Fang's original in an attempt to understand it. In the process, he merged in most of a different how-to by Bob Crosson <crosson@cam.nist.gov>. --> Eric S. Raymond <esr@snark.thyrsus.com> は、Chin Fang の元文書を 分かりやすくするために改訂と再編成、大幅な書き直しを行いました。 この過程で、Bob Crosson <crosson@cam.nist.gov> による別の HOWTO 文書の大部分を取り込みました。 <!--O The material on interlaced modes is largely by David Kastrup <dak@pool.informatik.rwth-aachen.de> --> インタレースモードに関する資料は主として David Kastrup <dak@pool.informatik.rwth-aachen.de> によります。 <!--O Nicholas Bodley <nbodley@alumni.princeton.edu> corrected and clarified the section on how displays work. --> Nicholas Bodley <nbodley@alumni.princeton.edu> はディスプレイ の動作に関する章の訂正と整理をしてくれました。 <!--O Payne Freret <payne@freret.org> corrected some minor technical errors about monitor design. --> Payne Freret <payne@freret.org> はモニタの設計に関する小さな技術 的な誤りを訂正してくれました。 <!--O Martin Lottermoser <Martin.Lottermoser@mch.sni.de> contributed the idea of using gnuplot to make mode diagrams and did the mathematical analysis behind <TT>modeplot</TT>. The distributed <TT>modeplot</TT> was redesigned and generalized by ESR from Martin's original gnuplot code for one case. --> Martin Lottermoser <Martin.Lottermoser@mch.sni.de> は gnuplot を用いてモードダイアグラムを作画するというアイディアを提案し、 <TT>modeplot</TT> の背景にある数学的な解析を行いました。 配布されている <TT>modeplot</TT> は、ある場合について書いた Martin の スクリプトを元に、ESR が再設計と一般化を行いました。 [訳注: ESR とは Eric S. Raymond のことです。] <sect1>日本語訳について <p> 現在のバージョンは、岡本一幸さんと Hiro Sugawara さんの訳を元に Linux Japanese FAQ Project が更新を行いました。翻訳に関するご意見は JF プロジェクト <JF@linux.or.jp> 宛に連絡してください。 改訂履歴を以下に示します。 <descrip> <tag>v3.0, 9 September 1997</tag> 翻訳: <itemize> <item>岡本一幸 <ikko-@pacific.rim.or.jp> <item>Hiro Sugawara <hiro@arkusa.com> </itemize> コメント: 山崎康宏 <hiro@koneeko.linux.or.jp><newline> <tag>v3.6j, 20 November 1999</tag> 翻訳: 藤原輝嘉 <fujiwara@linux.or.jp> <tag>v4.1j, 21 January 2000</tag> 更新: 藤原輝嘉 <fujiwara@linux.or.jp> </descrip> <tag>v4.2j, 26 Feburary 2000</tag> 更新: 藤原輝嘉 <fujiwara@linux.or.jp> </descrip> <tag>v4.4j, 18 March 2000</tag> 更新: 藤原輝嘉 <fujiwara@linux.or.jp> </descrip> </article>