カーネルモードの設定とフレームバッファーの違い
KMSでは、グラフィックスドライバーがカーネルに移動されます。フレームバッファはすでにカーネル内にあったので、これがフレームバッファの動作に影響を与えるとは思いません。それでも、KMSはfbに取って代わり、fbを増強し、fbを必要とし、fbサポートを削除する必要があることを読みました。一体何ですか？私が探している答えは、KMSとフレームバッファーの関係の説明です。
私はttyでネイティブの解決を得るためにuvesafbを使用しています。ここでの私の目的は、KMSを備えたシステムでそれがどのように機能するかを理解することです。 KMSの方がスクロール速度が速いですか？ fbtermやfbidaなどのユーティリティは同じように機能しますか？安定性は良いですか？
まず第一に、基本的に2種類のクラシックフレームバッファードライバーがあります。
- 汎用ハードウェアおよびファームウェアドライバー（例：vga、vesafb/uvesafb、efifb）
- ハードウェア固有のドライバー（rivafb、atyfbなど）
クラシックフレームバッファードライバーはすべて、基本的なモード設定サポートを備えていましたが、ハードウェアアクセラレーションのサポートはほとんどありませんでした。
従来のX設計では、これはそれほど問題ではありませんでした。2Dアクセラレーションを取得するために、Xサーバーはrootとして実行され、ハードウェアに直接アクセスできました。基本的には、フレームバッファドライバを完全にバイパスします。 3D（および新しいカードでの2Dサポート）の場合、アクセスを仲介し、ビデオメモリを管理するカーネルDRMドライバーも使用します。
このセットアップでは、モード設定が行われた場所が2つありました。カーネルフレームバッファードライバーとユーザースペースXサーバーの両方です。このコードの重複（および、VTスイッチなどでのドライバー間の不定期の戦い）は理想的ではありませんでした。
さらに、同じハードウェアのカーネルには、フレームバッファードライバーとDRMドライバーという2つの別々のドライバーがありました。場合によっては（pre-kms intelfbなど）、どちらか一方をロードできますが、両方を同時にロードすることはできません。
KMSはこれらの問題の解決策でした。それ：
- カーネルハードウェア固有のフレームバッファードライバーとdrmドライバーを1つのドライバーにマージします。
- Xサーバーがモード設定の制御に使用するインターフェースを提供するため、Xサーバーはハードウェアに直接アクセスする必要がありません。 （実際、KMSを使用すると、Xサーバーはroot権限を必要としなくなります。）
いくつかの興味深いメモ：現在KMSとなっているものへの移行は、実際には2004年頃に始まりました。 コンソールの再構築に関するジョン・スミルのメール を参照してください。
より具体的な質問に答えるには：
- 速度は通常、加速されていない汎用ドライバー（VGA、vesafbなど）の1つよりも劣ることはありませんが、KMSフレームバッファーテキストコンソールは、速度よりも利便性と緊急用に設計されており、一部のドライバーではコンソールが完全に高速化されていません。たとえば、ラップされた長い行は、Intelカードではかなり悪いです。
- 古いフレームバッファーインターフェイスを使用するように設計されたアプリケーションは、KMSフレームバッファーでも機能します。
KMSは、ユーザー空間ではなくカーネル空間に表示解像度と深度を設定します。そうそれはそれを取り替えます。フレームバッファでネイティブ解像度を有効にします。