フレームバッファは、単純化された画面インタフェースを可能にするデバイスファイルです。たとえば、HDMIディスプレイが接続されているRaspberryPiで次のコードを実行します。
cat /dev/urandom > /dev/fb1
フレームバッファに画像全体を挿入するためのコマンド（fbi、）があります。fim
インターネットにはたくさんの資料があります（参考文献1、参考文献2、参考文献3）は、画面に画像を生成するmake systemdサービスを追加する方法を説明するために、ある程度成功しようとしました。
これらのリソース間の共通スレッドはttyと一緒に言及されるということですframebuffer。 （つまり、fbi両方とfimオプションでaに渡すことができますtty）。
私の仮定は、aがttyaとは別の概念であるということですframebuffer。ユーザーにコンテンツttyを出力するために使用されますが、framebufferフレームバッファはtty。
ttyframebuffer画像をaに印刷するコマンドがaframebufferに依存するように見える理由を説明できるaとaの後に隠された関係はありますかtty？
答え1
この「隠された関係」は、Linuxのマルチ仮想端末サポートに関連しています。つまり、フレームバッファを複数の異なる端末で使用できることを意味します。フレームバッファを直接操作するプログラムは、現在フレームバッファを所有している端末を知る必要があります。
これらのプログラムが起動したら、現在の端末設定を保存してからディスプレイを直接制御したいとカーネルに知らせる必要があります（次を使用して「グラフィックモード」に切り替えます）。これ
KDSETMODEioctl）必要に応じてフレームバッファを設定します（例えばでfbi翻訳を設定します。）また、仮想ターミナルスイッチ（ユーザーが押すとき）について知りたいことをカーネルに知らせる必要があります。CtrlAltFnユーザーが端末を切り替えると、カーネルは実行中のプログラムに端末設定を復元し、端末制御を放棄する必要があることを通知します。
VT_RELDISP）実際に切り替える前に。ユーザがフレームバッファベースのプログラムを実行する端末に切り替えると、カーネルはプログラムに再度通知し、プログラムは必要に応じて端末とフレームバッファを設定し、表示を再開する。
これはVT切り替えの仕組み。