JF Linux Kernel 3.x/2.6 Documentation: /usr/src/linux/Documentation/fb/framebuffer.txt


フレームバッファデバイスの説明 [プレインテキスト版]

linux-2.6.13-rc5/Documentation/fb/framebuffer.txt の和訳
翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
更新日 : 2005/8/28
原著作者: Geert Uytterhoeven <geert at linux-m68k dot org>
翻訳者 : Hiroshi.Suzuki < setter at reset dot jp >
校正者 : Masanori Kobayasi さん <zap03216 at nifty dot ne dot jp>
         Seiji Kaneko さん <skaneko at a2 dot mbn dot or dot jp>

			The Frame Buffer Device


Maintained by Geert Uytterhoeven <geert at linux-m68k dot org>
Last revised: May 10, 2001

0. Introduction


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. /dev/fb*.

デバイスは、通常、例えば /dev/fb* のような、/dev ディレクトリ以下に配置される特別な

1. User's View of /dev/fb*

1.  /dev/fb* のユーザからの見え方

From the user's point of view, the frame buffer device looks just like any
other device in /dev. It's a character device using major 29; the minor
specifies the frame buffer number.

ユーザ側から見た場合、フレームバッファデバイスは、/dev 内にある他のデバイスと同じに
見えます。それは、メジャー番号 29 を使う キャラクタデバイスで、マイナー番号には

By convention, the following device nodes are used (numbers indicate the device
minor numbers):

慣例により、以下のデバイスノードが使われます (番号はデバイスのマイナー番号を示します):

      0 = /dev/fb0	First frame buffer
      1 = /dev/fb1	Second frame buffer
     31 = /dev/fb31	32nd frame buffer

For backwards compatibility, you may want to create the following symbolic


    /dev/fb0current -> fb0
    /dev/fb1current -> fb1

and so on...


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


  cp /dev/fb0 myfile

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 (/dev/fb0 and /dev/fb1 etc.) work independently.

同時に 2つ以上のフレームバッファを使うこともできます。たとえば、内蔵ハードウェアに
対応するフレームバッファデバイス (/dev/fb0 と /dev/fb1 など) は独立で動作します。

Application software that uses the frame buffer device (e.g. the X server) will
use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
an alternative frame buffer device by setting the environment variable
$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash

(X サーバなどの) フレームバッファデバイスを使うアプリケーションソフトは、デフォルトで、
/dev/fb0 を使います (より古いソフトは /dev/fb0current を使います)。
代わりとなるフレームバッファデバイスは、例えば、環境変数 $FRAMEBUFFER に、フレーム
バッファデバイスのパス名をセットすることで指定できます (sh/bash ユーザ用):

    export FRAMEBUFFER=/dev/fb1

or (for csh users):

または (csh ユーザ用):

    setenv FRAMEBUFFER /dev/fb1

After this the X server will use the second frame buffer.

これ以降、X サーバは、2番目のフレームバッファを使います。

2. Programmer's View of /dev/fb*

2. /dev/fb* のプログラマからの見え方

As you already know, a frame buffer device is a memory device like /dev/mem and
it has the same features. You can read it, write it, seek to some location in
it and mmap() 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.

(ここまでの文書で)お分かりのように、フレームバッファデバイスは、/dev/mem と同じ特徴を
持つようなメモリデバイスです。それに対して、読むこと、書くこと、任意の位置に seek 
すること、および、(主な使いかた) mmap() できます。(/dev/mem と) 異なる点は、特別な

/dev/fb* 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 <linux/fb.h> for more information on what ioctls exist and on
which data structures they work. Here's just a brief overview:

/dev/fb* は、様々な ioctl も可能です。それによって、ハードウェアについてのたくさんの
情報を、照会・設定できます。カラーマップ操作も ioctl によって働きます。どのような 
ioctl が存在し、どのようなデータ構造で動作するかの詳細は、<linux/fb.h> の中身を見て

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

  - 名称、スクリーンメモリの構成 (面, パックトピクセル, ...)、および、アドレスと

  - 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 information, the driver maybe will round up some
    values to meet the hardware's capabilities (or return EINVAL if that isn't

  - 可視および仮想画面の範囲、色深度、カラーマップ形式、ビデオタイミングなどのハード
    (不可能な場合は、EINVAL を返します)。

  - You can get and set parts of the color map. Communication is done with 16
    bits per color part (red, green, blue, transparency) to support all 
    existing hardware. The driver does all the computations needed to apply 
    it to the hardware (round it down to less bits, maybe throw away 

  - カラーマップの一部をゲット/セットできます。すべての存在するハードウェアをサポート
    するため、交信は各色 (赤, 緑, 青, 透明度) 毎に16ビットで行われます。

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. 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* 上で
かは、X サーバは知る必要はありません。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() を呼び出し、いくつかの機能を供給しな

3. Frame Buffer Resolution Maintenance

3. フレームバッファ解像度の保守管理

Frame buffer resolutions are maintained using the utility `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 /etc/rc.*
or /etc/init.d/* files.

フレームバッファ解像度は、'fbset' ユーティリティを使って、保守管理されます。
(例として、起動中に /etc/rc.* または、/etc/init.d/* の中のひとつのファイルで)

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 は設定ファイルに保存されたビデオモードデータベースを使うので、

4. The X Server

4. X サーバ

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) は、もっとも有名なフレームバッファデバイスのためのアプリケー
ションプログラムです。X サーバは、XFree86 の一部として、XFree86 リリース 3.2 から

  - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
    file contains a

	Modes "default"

    line, the X server will use the scheme discussed above, i.e. it will start
    up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You
    still have to specify the color depth (using the Depth keyword) and virtual
    resolution (using the Virtual keyword) though. This is the default for the
    configuration file supplied with XFree86. It's the most simple
    configuration, but it has some limitations.

  - /etc/XF86Config ファイル内の `fbdev' ドライバ用 'Diisplay' サブセクションに、

    Modes "default"  

    行が含まれるなら、X サーバは上で述べたスキームを使います。例えば、/dev/fb0 
    (セットされていれば、 $FRAMEBUFFER) によって決められた解像度で起動します。
    色深度 (Depth キーワードを使う) や、仮想解像度 (Virtual キーワードを使う)
    を指定しなければならないなら、それらを指定してください。これは、XFree86 とともに

  - Therefore it's also possible to specify resolutions in the /etc/XF86Config
    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
    /dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
    defined by /etc/XF86Config now. The disadvantage is that you have to
    specify the timings in a different format (but `fbset -x' may help).

  - したがって、/etc/XF86Config ファイル内で解像度を指定することも可能です。
    ことを可能にします。使われるフレームバッファデバイスは /dev/fb0current 
    (または、$FRAMEBUFFER) のままですが、利用可能な解像度は、この場合は 
    /etc/XF86Config で指定されたものになります。短所は、異なる形でタイミングを指定
    しなければならないことです (ですが、`fbset -x' が助けになります)。

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% の動作をしません:通知されるクロック値は

5. Video Mode Timings

5. ビデオモードタイミング

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

それぞれの 走査線後、電子ビームは画面左側の次の行に戻ります:これを、水平帰線と呼びます。
画面全体 (フレーム) が描画されたあと、ビームは上部左隅に戻ります:これを垂直帰線と呼びます。
水平および垂直帰線それぞれの間、電子ビームは消えています (ブランク)。

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.37516MHz (1秒間に100万サイクル) のとき、それぞれの画素の
時間は、35242 ps (ピコ秒) になります:

    1/(28.37516E6 Hz) = 35.242E-9 s

If the screen resolution is 640x480, it will take

画面解像度が、640x480 なら、1つの 走査線 に 640 (xres) 画素を描くには

    640*35.242E-9 s = 22.555E-6 s

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


    (640+272)*35.242E-9 s = 32.141E-6 s

We'll say that the horizontal scanrate is about 31 kHz:

になります。水平走査周波数が、約 31kHz とすると、

    1/(32.141E-6 s) = 31.113E3 Hz

A full screen counts 480 (yres) lines, but we have to consider the vertical
retrace too (e.g. 49 `lines'). So a full screen will take

全画面で480 (yres) 行を数えますが、垂直帰線 (例えば 49 '行') も考える必要があります。

    (480+49)*32.141E-6 s = 17.002E-3 s

The vertical scanrate is about 59 Hz:

垂直走査周波数 は、約 59Hz です。

    1/(17.002E-3 s) = 58.815 Hz

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 は、垂直走査周波数を最低72Hzにすることを勧めています。
しかしちらつきの受け止め方は人それぞれです:私が 80Hz未満で気づいてしまう一方、
あるひとは、50Hz で問題無く使えています。

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.

次の図は、全タイミングの概要です。水平帰線時間は、左余白、右余白、および、hsync の長さ
の合計で、垂直帰線の時間は、上部余白、下部余白、および、vsync の長さの合計です。

  |          |                ^                            |          |       |
  |          |                |upper_margin                |          |       |
  |          |                ?                           |          |       |
  |          #                ^                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |   left   #                |                            #  right   | hsync |
  |  margin  #                |       xres                 #  margin  |  len  |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |yres                        #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                ?                           #          |       |
  |          |                ^                            |          |       |
  |          |                |lower_margin                |          |       |
  |          |                ?                           |          |       |
  |          |                ^                            |          |       |
  |          |                |vsync_len                   |          |       |
  |          |                ?                           |          |       |

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秒) での水平タイミングと、

6. Converting XFree86 timing values info frame buffer device timings

6. XFree86 タイミング値情報をフレームバッファデバイスタイミングに変換する

An XFree86 mode line consists of the following fields:
ひとつの XFree86 モード行は、次のフィールドからなります:

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

The frame buffer device uses the following fields:


  - pixclock: pixel clock in ps (pico seconds)
  - left_margin: time from sync to picture
  - right_margin: time from picture to sync
  - upper_margin: time from sync to picture
  - lower_margin: time from picture to sync
  - hsync_len: length of horizontal sync
  - vsync_len: length of vertical sync

  - pixclock: ps (ピコ秒) での 画素クロック
  - left_margin: 同期から画像までの時間
  - right_margin: 画像から同期までの時間
  - upper_margin: 同期から画像までの時間
  - lower_margin: 画像から同期までの時間
  - hsync_len: 水平同期の長さ
  - vsync_len: 垂直同期の長さ

1) Pixelclock:
   xfree: in MHz
   fb: in picoseconds (ps)

1) 画素クロック:
   xfree: MHz で
   fb: ピコ秒 (ps) で

   pixclock = 1000000 / DCF

2) horizontal timings:

2) 水平タイミング:

   left_margin = HFL - SH2
   right_margin = SH1 - HR
   hsync_len = SH2 - SH1

3) vertical timings:

3) 垂直タイミング:

   upper_margin = VFL - SV2
   lower_margin = SV1 - VR
   vsync_len = SV2 - SV1

Good examples for VESA timings can be found in the XFree86 source tree,
under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".

XFree86 ソースツリーの "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt" で、
VESA タイミングの良い例を見ることができます。

7. References

7. 参考文献

For more specific information about the frame buffer device and its
applications, please refer to the Linux-fbdev website:

Linux-fbdev のウェブサイトを参照してください。


and to the following documentation:


  - The manual pages for fbset: fbset(8), fb.modes(5)
  - The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
  - The mighty kernel sources:
      o linux/drivers/video/
      o linux/include/linux/fb.h
      o linux/include/video/

  - fbset: fbset(8), fb.modes(5) のマニュアルページ
  - XFree86: XF68_FBDev(1), XF86Config(4/5) のマニュアルページ
  - 偉大なるカーネルソース:
      o linux/drivers/video/
      o linux/include/linux/fb.h
      o linux/include/video/

8. Mailing list

8. メーリングリスト

There are several frame buffer device related mailing lists at SourceForge:
  - linux-fbdev-announce@lists.sourceforge.net, for announcements,
  - linux-fbdev-user@lists.sourceforge.net, for generic user support,
  - linux-fbdev-devel@lists.sourceforge.net, for project developers.

SourceForge にフレームバッファデバイスに関連するいくつかのメーリングリストがあります:
  - linux-fbdev-announce@lists.sourceforge.net, 告知用、
  - linux-fbdev-user@lists.sourceforge.net, 一般ユーザサポート用、
  - linux-fbdev-devel@lists.sourceforge.net, プロジェクト開発者用。

Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
subscription information and archive browsing.

http://sourceforge.net/projects/linux-fbdev/ を指定してください。

9. Downloading

9. ダウンロード

All necessary files can be found at



and on its mirrors.


The latest version of fbset can be found at

fbset の 最新版 は以下の場所にあります


10. Credits

10. 著作者
This readme was written by Geert Uytterhoeven, partly based on the original
`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
provided by Frank Neumann.

この readme は、Geert Uytterhoeven によって書かれ、部分的に、
原文書 `X-framebuffer.README' (Roman Hodek、 Martin Schaller 著) を元にしています。
6章は、Frank Neumann に提供されました。

The frame buffer device abstraction was designed by Martin Schaller.

フレームバッファデバイスの抽象化は、Martin Schaller によって設計されました。

Linux カーネル 3.x/2.6 付属文書一覧へ戻る