<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">

<article>
<!--
<title>The Linux/m68k Frame Buffer Device
-->
<title>Linux/m68k のフレームバッファデバイスについて
<author>Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
<date>7 November 1998
<trans>The X Japanese Documentation Project
<tdate>16 March 1999
<toc>

<!--
<sect>Introduction
-->
<sect>はじめに
<p>
<!--
The frame buffer device provides an abstraction for the graphics hardware. It
represents the frame buffer of some video hardware and allows application
software to access the graphics hardware through a well-defined interface, so
the software doesn't need to know anything about the low-level (hardware
register) stuff.
-->
フレームバッファデバイスは、グラフィックスハードウェアの抽象化を行いま
す。このデバイスが何らかのビデオハードウェアのフレームバッファを表すこ
とによって、きちんと定義されたインタフェースを通してアプリケーションが
グラフィックスハードウェアにアクセスできるようにします。したがって、ソ
フトウェアは低レベル(ハードウェアレジスタ)の事象に関して何も知る必要は
ありません。

<!--
The device is accessed through special device nodes, usually located in the
/dev directory, i.e. <tt>/dev/fb*</tt>.
-->
デバイスへのアクセスは特殊デバイスノードを通して行います。デバイスノー
ドは通常 /dev ディレクトリに置かれ、フレームバッファデバイスに対応する
ものは <tt>/dev/fb*</tt> などとなります。

<!--
<sect>User's View of <tt>/dev/fb*</tt>
-->
<sect>ユーザから見た <tt>/dev/fb*</tt>
<p>
<!--
From the user's point of view, the frame buffer device looks just like any
other device in <tt>/dev</tt>. It's a character device using major 29, the
minor specifies the frame buffer number.
-->
ユーザの視点から見ると、フレームバッファデバイスは <tt>/dev</tt> にあ
る他のデバイスとほとんど同じに見えます。これはメジャー番号 29 を使うキャ
ラクタ型デバイスで、マイナー番号でフレームバッファの番号を指定します。

<!--
By convention, the following device nodes are used (numbers indicate the device
minor numbers):
-->
慣習により、以下のデバイスノードが使われます(数字はデバイスのマイナー
番号を示します):
<!--
<descrip>
<tag>  0 = <tt>/dev/fb0</tt></tag>First frame buffer
<tag> 32 = <tt>/dev/fb1</tt></tag>Second frame buffer
<tag>...</tag><p>
<tag>224 = <tt>/dev/fb7</tt></tag>8th frame buffer
</descrip>
-->
<descrip>
<tag>  0 = <tt>/dev/fb0</tt></tag>最初のフレームバッファ
<tag> 32 = <tt>/dev/fb1</tt></tag>2番目のフレームバッファ
<tag>...</tag><p>
<tag>224 = <tt>/dev/fb7</tt></tag>8番目のフレームバッファ
</descrip>

<!--
For backwards compatibility, you may want to create a symbolic link from
<tt>/dev/fb0current</tt> to <tt>fb0</tt>.
-->
後方互換性のため、<tt>/dev/fb0current</tt> から <tt>fb0</tt> にシンボ
リックリンクを作ることになるかもしれません。

<!--
The frame buffer devices are also `normal' memory devices, this means, you can
read and write their contents. You can, for example, make a screen snapshot by
-->
フレームバッファデバイスは「通常の」メモリデバイスでもあります。つまり、
内容を読み書きすることができます。例えば、以下のコマンドで画面のスナッ
プショットを取ることができます:

    <tscreen><verb>
    cp /dev/fb0 myfile
    </verb></tscreen>

<!--
There also can be more than one frame buffer at a time, e.g. if you have a
graphics card in addition to the built-in hardware. The corresponding frame
buffer devices (<tt>/dev/fb0</tt> and <tt>/dev/fb1</tt> etc.) work
independently.
-->
同時に複数のフレームバッファを持つこともできます。例えば、組込みのハー
ドウェア以外に追加のグラフィックスカードを持っている場合です。それぞれ
に対応するフレームバッファ(<tt>/dev/fb0</tt>、<tt>/dev/fb1</tt> など)
は独立して動作します。

<!--
Application software that uses the frame buffer device (e.g. the X server) will
use <tt>/dev/fb0</tt> by default (older software uses
<tt>/dev/fb0current</tt>). You can specify an alternative frame buffer device
by setting the environment variable <tt>&dollar;FRAMEBUFFER</tt> to the path
name of a frame buffer device, e.g. (for sh/bash users):
-->
フレームバッファデバイスを使うアプリケーションソフトウェア(例: X サー
バ)は、デフォルトで <tt>/dev/fb0</tt> を使います(古いソフトウェアは 
<tt>/dev/fb0current</tt> を使います)。環境変数 
<tt>&dollar;FRAMEBUFFER</tt> にフレームバッファデバイスのパス名を設定
することにより、別のフレームバッファデバイスを指定することができます。
例(sh/bash ユーザの場合):

    <tscreen><verb>
    export FRAMEBUFFER=/dev/fb1
    </verb></tscreen>

<!--
or (for csh users):
-->
または(csh ユーザの場合):

    <tscreen><verb>
    setenv FRAMEBUFFER /dev/fb1
    </verb></tscreen>

<!--
After this the X server will use the second frame buffer.
-->
これを設定した後は、X サーバは 2 番目のフレームバッファを使うようにな
ります。

<!--
<sect>Programmer's View of <tt>/dev/fb*</tt>
-->
<sect>プログラマから見た <tt>/dev/fb*</tt>
<p>
<!--
As you already know, a frame buffer device is a memory device like
<tt>/dev/mem</tt> and it has the same features. You can read it, write it, seek
to some location in it and <tt>mmap()</tt> it (the main usage). The difference
is just that the memory that appears in the special file is not the whole
memory, but the frame buffer of some video hardware.
-->
既に説明したように、フレームバッファデバイスは <tt>/dev/mem</tt> のよ
うなメモリデバイスであり、これと同じ機能を持っています。読み書きや、ど
こかの位置をシークすること、<tt>mmap()</tt> すること(これが主な使用方
法)ができます。唯一の違いは、特殊ファイルに現われるメモリは，全てのメ
モリを表しているのではなく、何らかのビデオハードウェアのフレームバッファ
を意味していることです。

<!--
<tt>/dev/fb*</tt> also allows several ioctls on it, by which lots of
information about the hardware can be queried and set. The color map handling
works via ioctls, too. Look into <tt>&lt;linux/fb.h&gt;</tt> for more
information on what ioctls exist and on which data structures they work. Here's
just a brief overview:
-->
<tt>/dev/fb*</tt> に対して使うことができる ioctl がいくつかあります。
これを使って、ハードウェアに関する情報をたくさん問い合わせることや設定
することができます。カラーマップ処理も ioctl 経由で行います。ヘッダ 
<tt>&lt;linux/fb.h&gt;</tt> を見れば、どんな ioctl があって、どんな構
造体が使われるのかという詳細がわかります。そこで、ここでは概要だけを簡
単に説明することにします:

    <itemize>
<!--
    <item>You can request unchangeable information about the hardware, like
    name, organization of the screen memory (planes, packed pixels, ...) and
    address and length of the screen memory.
-->
<item>ハードウェアに関する変更不可能な情報をリクエストすることができま
す。このような情報としては、名前やスクリーンメモリの構成(プレーン、
packed 形式ピクセル、...)、スクリーンメモリのアドレスや長さなどがあり
ます。

<!--
    <item>You can request and change variable information about the hardware,
    like visible and virtual geometry, depth, color map format, timing, and so
    on.  If you try to change that informations, the driver maybe will round up
    some values to meet the hardware's capabilities (or return <tt>EINVAL</tt>
    if that isn't possible).
-->
<item>ハードウェアに関する変更可能な情報をリクエストおよび変更することがで
きます。このような情報としては、可視ジオメトリや仮想ジオメトリ、色の深
さ、カラーマップのフォーマット、タイミング値などがあります。このような
情報を変更しようとした場合、ドライバはたぶんハードウェアの機能に合わせ
て値をいくらか丸めるでしょう(それが不可能ならば <tt>EINVAL</tt> を返し
ます)。

<!--
    <item>You can get and set parts of the color map. Communication is done
    with 16 bit per color part (red, green, blue, transparency) to support all
    existing hardware. The driver does all the computations needed to bring it
    into the hardware (round it down to less bits, maybe throw away
    transparency).
-->
<item>カラーマップの一部を取得・設定することができます。存在する全ての
ハードウェアをサポートするため、演算は色の各部分(赤、緑、青、透明度)に
ついて 16 ビットで行われます。ドライバはこれをハードウェアに与えるため
に全ての通信を行います(ビットを減らすために丸めが行われ、おそらく透明
度は破棄されます)。
    </itemize>

<!--
All this hardware abstraction makes the implementation of application programs
easier and more portable. E.g. the X server works completely on /dev/fb* and
thus doesn't need to know, for example, how the color registers of the concrete
hardware are organized. <em/XF68_FBDev/ is a general X server for bitmapped,
unaccelerated video hardware. The only thing that has to be built into
application programs is the screen organization (bitplanes or chunky pixels
etc.), because it works on the frame buffer image data directly.
-->
以上のような抽象化のおかげで、アプリケーションプログラムを実装するの
も移植するのも楽になるわけです。例えば、X サーバは /dev/fb* を使っ
て完全に動作するので、具体的なハードウェアの色レジスタがどのように構成
されているか等を知る必要がありません。<em/XF68_FBDev/ はビットマップを
使用し、アクセラレーションの無いビデオハードウェア用の汎用の X サーバ
です。アプリケーションプログラムに組み込まなければならないのは、画面の
構成(ビットプレーン、まとまったピクセル等)だけです。なぜなら、アプリケー
ションは直接フレームバッファのイメージデータを操作するからです。

<!--
For the future it is planned that frame buffer drivers for graphics cards and
the like can be implemented as kernel modules that are loaded at runtime. Such
a driver just has to call register_framebuffer() and supply some functions.
Writing and distributing such drivers independently from the kernel will save
much trouble...
-->
将来的には、グラフィックスカード等のフレームバッファドライバをカーネル
モジュールとして実装し、実行時にロードすることが考えられています。この
ようなドライバは、ただ register_framebuffer() を呼び出し、何らかの機能
を提供するだけでよくなります。このようなドライバを独立に作成・配布すれ
ば、カーネルがトラブルに巻き込まれることも少ないでしょう…。

<!--
<sect>Frame Buffer Resolution Maintenance
-->
<sect>フレームバッファの解像度の管理
<p>
<!--
Frame buffer resolutions are maintained using the utility <em/fbset/. It can
change the video mode properties of a frame buffer device. Its main usage is
to change the current video mode, e.g. during boot up in one of your
<tt>/etc/rc.*</tt> or <tt>/etc/init.d/*</tt> files.
-->
フレームバッファの解像度は <em/fbset/ というユーティリティを使って管理
します。このユーティリティを使ってフレームバッファデバイスのビデオモー
ドのプロパティを変更することができます。その主な使い方は、例えば起動時
に <tt>/etc/rc.*</tt> や <tt>/etc/init.d/*</tt> 等のファイル中で、現在
のビデオモードを変更することです。

<!--
Fbset uses a video mode database stored in a configuration file, so you can
easily add your own modes and refer to them with a simple identifier.
-->
fbset は、設定ファイル中に格納されているビデオモードのデータベースを使
います。したがって、独自のモードを簡単に追加することや、モードを簡単な
識別子で参照することができます。

<!--
<sect>The X Server
-->
<sect>X サーバ
<p>
<!--
The X server (XF68_FBDev) is the most notable application program for the frame
buffer device. Starting with XFree86 release 3.2, the X server is part of
XFree86 and has 2 modes:
-->
X サーバ(XF68_FBDev)は、フレームバッファデバイス用の最も有名なアプリケー
ションプログラムです。XFree86 リリース 3.2 以降、この X サーバは 
XFree86 の一部であり、2 つのモード値を持っています。

    <itemize>
<!--
    <item>If the <tt/Display/ subsection for the <tt/fbdev/ driver in the
    <tt>/etc/XF86Config</tt> file contains a
-->
<item><tt>/etc/XF86Config</tt>ファイル内の <tt/fbdev/ ドライバに対する
<tt/Display/ サブセクションが

	<tscreen><verb>
        Modes "default"
	</verb></tscreen>

<!--
    line, the X server will use the scheme discussed above, i.e. it will start
    up in the resolution determined by <tt>/dev/fb0</tt> (or
    <tt>&dollar;FRAMEBUFFER</tt>, if set). You still have to specify the color
    depth (using the <tt>Depth</tt> keyword) and virtual resolution (using the
    <tt>Virtual</tt> keyword) though. This is the default for the configuration
    file supplied with XFree86. It's the most simple configuration, but it has
    some limitations.
-->
という内容である場合、X サーバは前述の方法を使います。つまり、
<tt>/dev/fb0</tt> (設定されていれば <tt>&dollar;FRAMEBUFFER</tt>)によっ
て決められた解像度で起動します。その場合でも、色の深さ(<tt>Depth</tt> 
キーワードを使います)と仮想解像度(<tt>Virtual</tt> を使います)は指定し
なければなりません。これは XFree86 が用意している設定ファイルのデフォ
ルトです。これは最も簡単な設定ですが、制限がいくつかあります。

<!--
    <item>Therefore it's also possible to specify resolutions in the
    <tt>/etc/XF86Config</tt> file. This allows for on-the-fly resolution
    switching while retaining the same virtual desktop size. The frame buffer
    device that's used is still <tt>/dev/fb0</tt> (or
    <tt>&dollar;FRAMEBUFFER</tt>), but the available resolutions are defined by
    <tt>/etc/XF86Config</tt> now. The disadvantage is that you have to specify
    the timings in a different format (but <tt>fbset -x</tt> may help).
-->
<item>したがって、<tt>/etc/XF86Config</tt> ファイル内で解像度を指定す
ることもできます。これにより、仮想デスクトップの大きさを同じに保ったまま、
実行中に解像度の切り替えを行うことができます。この場合も使われるフレー
ムバッファデバイスは <tt>/dev/fb0</tt> (または 
<tt>&dollar;FRAMEBUFFER</tt>)のままですが、この場合は利用できる解像度
は <tt>/etc/XF86Config</tt> で定義されています。欠点としては、異なるフォー
マットでタイミング値を指定しなければならないことが挙げられます(しかし、
<tt>fbset -x</tt> が参考になるでしょう)。
    </itemize>

<!--
To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
work 100% with XF68_FBDev: the reported clock values are always incorrect.
-->
ビデオモードをチューンするために fbset や xvidtune が利用できます。 
xvidtune は XF68_FBDev では 100% 動作しない点に注意してください。報告
されるクロック値は必ず間違っています。

<!--
<sect>Video Mode Timings
-->
<sect>ビデオモードタイミング値
<p>
<!--
A monitor draws an image on the screen by using an electron beam (3 electron
beams for color models, 1 electron beam for monochrome monitors). The front of
the screen is covered by a pattern of colored phosphors (pixels). If a phosphor
is hit by an electron, it emits a photon and thus becomes visible.
-->
モニタは電子線を用いてイメージを画面に描画します(カラーモデルなら電子
線 3 つで、モノクロモニタなら電子線 1 つです)。スクリーンの前面は色付
きの蛍光体(ピクセル)のパターンで覆われています。蛍光体に電子が当たると
光子が出て、見えるようになります。

<!--
The electron beam draws horizontal lines (scanlines) from left to right, and
from the top to the bottom of the screen. By modifying the intensity of the
electron beam, pixels with various colors and intensities can be shown.
-->
電子線は水平な線(スキャンライン)を画面の左から右、上から下に向かって描
画します。電子線の強度を変えることにより、様々な色や明るさのピクセルを
描画することができます。

<!--
After each scanline the electron beam has to move back to the left side of the
screen and to the next line: this is called the horizontal retrace. After the
whole screen (frame) was painted, the beam moves back to the upper left corner:
this is called the vertical retrace. During both the horizontal and vertical
retrace, the electron beam is turned off (blanked).
-->
各スキャンラインの後には、電子線は画面の左側に戻り、次の行に移動しなけ
ればなりません。これは水平復帰(horizontal retrace)と呼ばれます。画面
(フレーム)全体を描いた後には、電子線は画面の左上隅に戻ります。これは垂
直復帰(vertical retrace)と呼ばれます。水平復帰や垂直復帰の間には、電子
線は止まります(ブランク状態になります)。

<!--
The speed at which the electron beam paints the pixels is determined by the
dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
of cycles per second), each pixel is 35242 ps (picoseconds) long:
-->
電子線がピクセルを描画する速度は、グラフィックスボードのドットクロック
値によって決まります。例えばドットクロック値が 28.37516 MHz(一秒あたり
数百万サイクル)の場合には、それぞれのピクセルあたりの長さは 35242 ps
(ピコ秒)です:

    <tscreen><verb>
    1/(28.37516E6 Hz) = 35.242E-9 s
    </verb></tscreen>

<!--
If the screen resolution is 640x480, it will take
-->
画面の解像度が 640x480 ならば、1 スキャンライン分の 640(xres)ピクセル
を描画するのにかかる時間は

    <tscreen><verb>
    640*35.242E-9 s = 22.555E-6 s
    </verb></tscreen>

<!--
to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
also takes time (e.g. 272 `pixels'), so a full scanline takes
-->
となります。ですが、水平復帰にも時間がかかる(例えば 272 「ピクセル」)
ので、1 スキャンライン全体でかかる時間は

    <tscreen><verb>
    (640+272)*35.242E-9 s = 32.141E-6 s
    </verb></tscreen>

<!--
We'll say that the horizontal scanrate is about 31 kHz:
-->
となります。ですから水平スキャンレートは約 31 kHz と言えます:

    <tscreen><verb>
    1/(32.141E-6 s) = 31.113E3 Hz
    </verb></tscreen>

<!--
A full screen counts 480 (yres) lines, but we have to consider the vertical
retrace too (e.g. 49 `pixels'). So a full screen will take
-->
画面全体では 480(yres)行ありますが、垂直復帰(例えば 49 「ピクセル」)も
考えなければなりません。ですから、画面全体では

    <tscreen><verb>
    (480+49)*32.141E-6 s = 17.002E-3 s
    </verb></tscreen>

かかります。
<!--
The vertical scanrate is about 59 Hz:
-->
垂直スキャンレートは約 50 Hz になります:

    <tscreen><verb>
    1/(17.002E-3 s) = 58.815 Hz
    </verb></tscreen>

<!--
This means the screen data is refreshed about 59 times per second. To have a
stable picture without visible flicker, VESA recommends a vertical scanrate of
at least 72 Hz. But the perceived flicker is very human dependent: some people
can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
-->
つまり、画面のデータは 1 秒あたり約 59 回書き直されるということです。
目に見えるようなちらつきを起こさずに安定したピクセルを得るために VESA 
が推奨している垂直スキャンレートは最低 72 Hz です。しかし、我慢できる
ちらつきというのは人それぞれです。50Hz で使っても全く問題ないという人
もいれば、筆者のように 80 Hz より小さいと気付いてしまうという人もいま
す。

<!--
Since the monitor doesn't know when a new scanline starts, the graphics board
will supply a synchronization pulse (horizontal sync or hsync) for each
scanline.  Similarly it supplies a synchronization pulse (vertical sync or
vsync) for each new frame. The position of the image on the screen is
influenced by the moments at which the synchronization pulses occur.
-->
新しいスキャンラインがいつ始まるかはモニタには分からないので、グラフィッ
クスボードはスキャンラインごとに同期信号(水平同期または hsync)を出しま
す。同様に、新しいフレームごとにも同期信号(垂直同期または vsync)を出し
ます。画面における画像の位置は、同期信号が発生するタイミングの影響を受
けます。

<!--
The following picture summarizes all timings. The horizontal retrace time is
the sum of the left margin, the right margin and the hsync length, while the
vertical retrace time is the sum of the upper margin, the lower margin and the
vsync length.
-->
全てのタイミングを以下の図にまとめました。水平復帰時間は左マージン
(left margin)、右マージン(right margin)、水平同期の長さ(hsync len)の合
計です。垂直復帰時間は上部マージン(upper_margin)、下部マージン
(lower_margin)、垂直同期の長さ(vsync_len)の合計です。

<tscreen><verb>
  +----------+---------------------------------------------+----------+-------+
  |          |                x                            |          |       |
  |          |                |upper_margin                |          |       |
  |          |                x                            |          |       |
  +----------###############################################----------+-------+
  |          #                x                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |   left   #                |                            #  right   | hsync |
  |  margin  #                |       xres                 #  margin  |  len  |
  |<-------->#<---------------+--------------------------->#<-------->|<----->|
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |yres                        #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                x                            #          |       |
  +----------###############################################----------+-------+
  |          |                x                            |          |       |
  |          |                |lower_margin                |          |       |
  |          |                x                            |          |       |
  +----------+---------------------------------------------+----------+-------+
  |          |                x                            |          |       |
  |          |                |vsync_len                   |          |       |
  |          |                x                            |          |       |
  +----------+---------------------------------------------+----------+-------+
</verb></tscreen>

<!--
The frame buffer device expects all horizontal timings in number of dotclocks
(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
-->
フレームバッファデバイスは、全ての水平タイミング値がドットクロック(ピ
コ秒(1E-12 秒)単位)の数であることと、全ての垂直タイミング値がスキャン
ラインの数であることを期待します。

<!--
<sect>Converting XFree86 timing values into frame buffer device timings
-->
<sect>XFree86 のタイミング値のフレームバッファデバイスのタイミング値への変換
<p>
<!--
An XFree86 mode line consists of the following fields:
-->
XFree86 のモードラインは以下のフィールドから構成されています:

    <tscreen><verb>
    "800x600"     50      800  856  976 1040    600  637  643  666
    < name >     DCF       HR  SH1  SH2  HFL     VR  SV1  SV2  VFL
    </verb></tscreen>

<!--
The frame buffer device uses the following fields:
-->
フレームバッファデバイスは以下のフィールドを使用します:

<!--
    <descrip>
    <tag>pixclock</tag> pixel clock in ps (pico seconds)
    <tag>left_margin</tag> time from sync to picture
    <tag>right_margin</tag> time from picture to sync
    <tag>upper_margin</tag> time from sync to picture
    <tag>lower_margin</tag> time from picture to sync
    <tag>hsync_len</tag> length of horizontal sync
    <tag>vsync_len</tag> length of vertical sync
    </descrip>
-->
    <descrip>
    <tag>pixclock</tag> ps (ピコ秒)単位のピクセルクロック値
    <tag>left_margin</tag> 同期から描画までの時間
    <tag>right_margin</tag> 描画から同期までの時間
    <tag>upper_margin</tag> 同期から描画までの時間
    <tag>lower_margin</tag> 描画から同期までの時間
    <tag>hsync_len</tag> 水平同期の長さ
    <tag>vsync_len</tag> 垂直同期の長さ
    </descrip>

    <descrip>
    <tag>Pixelclock</tag>
<!--
	<itemize>
	<item>xfree: in MHz
	<item>fb: In Picoseconds (ps)
	<item>pixclock = 1000000 / DCF
	</itemize>
-->
	<itemize>
	<item>xfree: MHz 単位
	<item>fb: ピコ秒(ps)単位
	<item>pixclock = 1000000 / DCF
	</itemize>

<!--
    <tag>Horizontal timings</tag>
-->
    <tag>水平タイミング値</tag>
	<itemize>
	<item>left_margin = HFL - SH2
	<item>right_margin = SH1 - HR
	<item>hsync_len = SH2 - SH1
	</itemize>

<!--
    <tag>Vertical timings</tag>
-->
    <tag>垂直タイミング値</tag>
	<itemize>
	<item>upper_margin = VFL - SV2
	<item>lower_margin = SV1 - VR
	<item>vsync_len = SV2 - SV1
	</itemize>
    </descrip>

<!--
Good examples for VESA timings can be found in the XFree86 source tree,
under <tt>xc/programs/Xserver/hw/xfree86/doc/modeDB.txt</tt>.
-->
VESA タイミング値の良い例は、XFree86 のソースツリーの
<tt>xc/programs/Xserver/hw/xfree86/doc/modeDB.txt</tt> にあります。

<!--
<sect>References
-->
<sect>参考文献
<p>
<!--
For more specific information about the frame buffer device and its
applications, please refer to the following documentation:
-->
フレームバッファデバイスと、その応用に関するより詳しい情報については、
以下の文書を参照してください:

<!--
    <itemize>
    <item>The manual pages for fbset: fbset(8), fb.modes(5)
    <item>The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
    <item>The mighty kernel sources:
	<itemize>
	<item>linux/drivers/video/
	<item>linux/include/linux/fb.h
	<item>linux/include/video/
	</itemize>
    </itemize>
-->
    <itemize>
    <item>fbset のオンラインマニュアル: fbset(8), fb.modes(5)
    <item>XFree86 のオンラインマニュアル: XF68_FBDev(1), XF86Config(4/5)
    <item>万能のカーネルソース:
	<itemize>
	<item>linux/drivers/video/
	<item>linux/include/linux/fb.h
	<item>linux/include/video/
	</itemize>
    </itemize>

<!--
<sect>Downloading
-->
<sect>ダウンロード
<p>
<!--
All necessary files can be found at
-->
必要なファイル全ては

    <tscreen><verb>
    ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
    </verb></tscreen>

<!--
and on its mirrors.
-->
またはそのミラーサイトにあります。

<!--
<sect>Credits
-->
<sect>クレジット
<p>
<!--
This readme was written by Geert Uytterhoeven, partly based on the original
<tt>X-framebuffer.README</tt> by Roman Hodek and Martin Schaller. Section
`Converting XFree86 timing values into frame buffer device timings' was
provided by Frank Neumann.
-->
この README 文書は Geert Uytterhoeven が書きました。内容の一部は、
Roman Hodek さんと Martin Schaller さんが書かれたオリジナルの
<tt>X-framebuffer.README</tt> に基づいています。
「XFree86 のタイミング値のフレームバッファデバイスのタイミング値への変換」
セクションは Frank Neumann さんに提供していただきました。

<!--
The frame buffer device abstraction was designed by Martin Schaller.
-->
フレームバッファデバイスによる抽象化層を設計したのは Martin Schaller 
さんです。

<verb>
$XFree86: xc/programs/Xserver/hw/xfree86/doc/Japanese/sgml/fbdev.sgml,v 1.1.2.2 1999/11/26 15:23:58 hohndel Exp $

</verb>

</article>
