================================== これは、 linux-2.6.13-rc5/Documentation/fb/framebuffer.txt の和訳 です。 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > 更新日 : 2005/8/28 原著作者: Geert Uytterhoeven 翻訳者 : Hiroshi.Suzuki < setter at reset dot jp > 校正者 : Masanori Kobayasi さん Seiji Kaneko さん ================================== The Frame Buffer Device フレームバッファデバイス ----------------------- Maintained by Geert Uytterhoeven Last revised: May 10, 2001 0. Introduction 0.序論 --------------- 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 links: 古いものとの互換性のため、次のシンボリックリンクを作成したいと思うかも知れません: /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 users): (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 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 が存在し、どのようなデータ構造で動作するかの詳細は、 の中身を見て ください。 次に示すのは、単に概要です: - 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 possible). - 可視および仮想画面の範囲、色深度、カラーマップ形式、ビデオタイミングなどのハード ウェアについての可変情報を要求/変更できます。その情報を変更しようとするとき、 ドライバはハードウェアの能力にあわせていくつかの値を丸めるかもしれません (不可能な場合は、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 transparency). - カラーマップの一部をゲット/セットできます。すべての存在するハードウェアをサポート するため、交信は各色 (赤, 緑, 青, 透明度) 毎に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 から 実装され、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 のウェブサイトを参照してください。 http://linux-fbdev.sourceforge.net/ 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 すべての必要なファイルは次の場所にあります ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/ and on its mirrors. および、ミラーサイト。 The latest version of fbset can be found at fbset の 最新版 は以下の場所にあります http://home.tvd.be/cr26864/Linux/fbdev/ 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 によって設計されました。