KMSでは、グラフィックドライバーがカーネルに移動されます。フレームバッファはすでにカーネルにあるので、これがフレームバッファの動作に影響するとは思わないでしょう。それでも、KMSはfbに取って代わり、fbを増強し、fbを必要とし、fbサポートを削除する必要があることを読みました。一体何？私が探している答えは、KMSとフレームバッファの関係の説明です。
私はttyでネイティブ解像度を取得するためにuvesafbを使用しています。ここでの私の目的は、KMSを使用したシステムでどのように機能するかを理解することです。KMSでのスクロールは高速ですか？fbtermやfbidaなどのユーティリティは同じように機能しますか？安定性は向上していますか？
回答:
まず、基本的な2種類のクラシックフレームバッファドライバーがあります。
従来のフレームバッファドライバはすべて基本的なモード設定サポートを備えていましたが、ハードウェアアクセラレーションのサポートはほとんどありませんでした。
従来のXデザインでは、これは実際には問題ではありませんでした。2Dアクセラレーションを取得するために、Xサーバーはルートとして実行され、ハードウェアに直接アクセスできました。基本的に、フレームバッファードライバーを完全にバイパスしました。3D（および新しいカードの2Dサポート）では、アクセスと管理されたビデオメモリを仲介するカーネルDRMドライバーも使用します。
この設定では、モード設定が行われた場所が2つありました。カーネルフレームバッファードライバーとユーザー空間Xサーバーの両方です。このコードの重複（および、VTスイッチなどでのドライバー間のたまの戦い）は理想的ではありませんでした。
さらに、同じハードウェアのカーネルには、フレームバッファードライバーとDRMドライバーの2つの別個のドライバーがありました。場合によっては（たとえば、km前のintelfb）、どちらか一方を読み込むことができますが、両方を同時に読み込むことはできません。
KMSはこれらの問題の解決策でした。それ：
興味深いメモ：現在のKMSへの移行は、実際には2004年頃に開始されました。コンソールの再構築に関するJon Smirlのメールを参照してください。
より具体的な質問に答えるには：
KMSは、ユーザー空間ではなくカーネル空間でディスプレイの解像度と深さを設定します。はい、それはそれを置き換えます。フレームバッファのネイティブ解像度を有効にします。