Linux でフレームバッファ デバイスを使用するソフトウェアの作成方法に関するドキュメントはありますか? 基本的に「開いて、mmap して、マップされた領域にピクセルを書き込む」という単純な例をいくつか見てきました。しかし、さまざまな IOCTLS を使用する方法に関する包括的なドキュメントはありません。「パン」やその他の機能についての言及を見たことがありますが、「グーグルで検索」すると役に立たない情報が多すぎます。
編集：「fbを使用するようにシステムを構成するユーザーの方法」コードではなく、プログラミングの観点からの唯一のドキュメントですか？
Linux フレームバッファを使用する画像ビューアーである fbi のソース コードを見ることができます。ここで入手できます：http://linux.bytesex.org/fbida/
MPlayerソースを確認します。
/libvoディレクトリの下には、Mplayer がマルチメディアを表示するために使用する多くのビデオ出力プラグインがあります。そこには、Linux フレーム バッファを使用するfbdev (vo_fbdev* ソース) プラグインがあります。
次のコードを含む ioctl 呼び出しが多数あります。
良いドキュメントとは言えませんが、これは確かに良いアプリケーションの実装です。
-- デスクトップ上のユーザー スペースから fb を使用してプログラミングできるオプションは、あなたが言及した以上に多くないようです。これが、一部のドキュメントが非常に古い理由の 1 つかもしれません。デバイス ドライバ作成者向けのこのハウツーを見てください。これは、いくつかの公式の Linux ドキュメントから参照されています: www.linux-fbdev.org [slash] HOWTO [slash] index.html 。あまりにも多くのインターフェースを参照していません..Linuxソースツリーを見ると、より大きなコード例が提供されます.
-- opentom.org [スラッシュ] Hardware_Framebuffer はデスクトップ環境向けではありません。それは主な方法論を強化しますが、それが言及する「高速な」ダブルバッファスイッチングを行うために必要なすべての要素を説明することを避けているようです. 別のデバイス用の別のもので、いくつかの重要なバッファリングの詳細が省略されていますdevice.. デスクトップの場合、fb1 は使用できないか、別のハードウェアにアクセスする可能性があります)、volatile キーワードを使用することが適切であり、vsync に注意を払う必要があることを確認してください。
-- asm.sourceforge.net [スラッシュ] 記事 [スラッシュ] fb.html アセンブリ言語ルーチン (?) クエリの基本、開く、いくつかの基本を設定する、mmap、ピクセル値をストレージに描画する、およびfbメモリにコピーします（長いアプローチではなく、短いstosbループを使用するようにしてください）。
-- Linux フレーム バッファをグーグル検索するときは、16 bpp のコメントに注意してください。X セッション中に fbgrab と fb2png を使用しましたが、役に立ちませんでした。これらはそれぞれ、デスクトップの写真が非常に悪いカメラを使用して水中で撮影され、暗い部屋で露出オーバーになったかのように、デスクトップ画面のスナップショットを示唆する画像をレンダリングしました。画像は色、サイズが完全に壊れており、多くの詳細が欠落しています (属していないピクセルの色が全体に点在しています)。私が使用したコンピューターの /proc /sys (多くてもマイナーな変更を加えた新しいカーネル.. PCLOS 派生物) は、fb0 が 16 bpp を使用していると主張しているようです。非常に異なる結論。標準のフレーム バッファ グラブ ユーティリティ (このディストリビューションで保持されているバージョン用) からのこれら 2 つの失敗の結果は、16 ビットを想定していた可能性がありますが、フレーム バッファのピクセル データを 32 ビットとして扱った別の成功したテスト結果がありました。cat /dev/fb0 経由で取り込んだデータからファイルを作成しました。ファイルのサイズは最終的に 1920000 になりました。次に、小さな C プログラムを作成して、そのデータを操作しようとしました (何らかのエンコーディングまたはその他のピクセル データであると仮定して)。私は最終的にそれを釘付けにし、ピクセル形式は、クエリ時に X から取得したものと正確に一致しました (TrueColor RGB 8 ビット、アルファはありませんが、32 ビットにパディングされました)。別の手がかりに注意してください: 800x600 x 4 バイトの私の画面解像度は、正確に 1920000 になります。私が最初に試した 16 ビットのアプローチはすべて、fbgrap と同様の壊れたイメージを生成したため、適切なデータを見ていない可能性がある場合は好きではありません。[データのテストに使用したコードが必要な場合はお知らせください。基本的に、適切なppmファイルを作成するヘッダー「P6\n800 600\n255\n」を追加した後、fb0ダンプ全体を読み込んでファイルに吐き出し、すべてのピクセルをループして順序を操作するか、それらを展開すると、.. 4 バイトごとにドロップし、4 バイト単位ごとに 1 番目と 3 番目を切り替えるという最終的な成功の結果が得られました。要するに、見かけ上の BGRA fb0 ダンプを ppm RGB ファイルに変換しました。ppm は、Linux の多くの pic ビューアーで表示できます。] そして、すべてのピクセルをループして順序を操作したり、それらを展開したりしながら、最終的に成功した結果は、4 バイトごとにドロップし、4 バイト単位ごとに 1 番目と 3 番目を切り替えることでした。要するに、見かけ上の BGRA fb0 ダンプを ppm RGB ファイルに変換しました。ppm は、Linux の多くの pic ビューアーで表示できます。] そして、すべてのピクセルをループして順序を操作したり、それらを展開したりしながら、最終的に成功した結果は、4 バイトごとにドロップし、4 バイト単位ごとに 1 番目と 3 番目を切り替えることでした。要するに、見かけ上の BGRA fb0 ダンプを ppm RGB ファイルに変換しました。ppm は、Linux の多くの pic ビューアーで表示できます。]
-- fb0 を使用してプログラミングしたい理由を再考する必要があるかもしれません (これは、例がほとんどない理由でもあります)。X を使用する利点をあきらめながら、X よりも価値のあるパフォーマンスの向上を達成できない可能性があります (これは、限定的ではあるが私の経験でした)。
-- DirectFB は fb ではないことに注意してください。DirectFB は、よりセクシーな 3D ハードウェア アクセルに重点を置いているため、最近、以前の FB よりも多くの支持を得ています。3D ハードウェア アクセラレータ (または 2D ハードウェア アクセラレータでさえも) を利用せずにできるだけ速くデスクトップ画面にレンダリングしたい場合、fb は問題ないかもしれませんが、X が提供しないものは何も提供しません。X は明らかに fb を使用しており、プログラムで発生する可能性が高い他のコストと比較して、オーバーヘッドは無視できる可能性があります (タイトなループで X を呼び出さないでください。代わりに、フレームのすべてのピクセルを設定したら最後に呼び出します)。一方、このコメントで説明されているように、fb をいじってみるのもいいかもしれません: Linux FrameBuffer を介してピクセルを画面にペイントする
fbxat、fbida、fbterm、fbtv、directFB ライブラリ、libxineliboutput-fbe、ppmtofb、xserver-fbdev のいずれかのソース コードを見てください。これらはすべて debian パッケージ アプリです。Debian ライブラリからソースを apt-get するだけです。他にもたくさんあります...
ヒント: お気に入りのパッケージ マネージャーを使用して、パッケージの説明でフレーム バッファーを検索します。
わかりました。コードを読むことを「 Guru のドキュメント」と呼ぶこともありますが、実際にそれを行うには少し多すぎる場合があります。
スプラッシュ画面のソース（つまり、起動中）は、良いスタートを切るはずです。