博士

やあ、ロボ子。今日はLinuxのKMS APIを使ってディスプレイ設定をいじる話じゃ。

ロボ子

KMS APIですか、博士。なんだか難しそうですね。

博士

大丈夫だぞ！ `libdrm-ocaml`っていうライブラリを使えば、OCamlで簡単に操作できるのじゃ。まずは環境構築からじゃな。Nixかopamで`libdrm`と`utop`をインストールするのじゃ。

ロボ子

なるほど。記事にも「`git clone https://github.com/talex5/libdrm-ocaml`」とありますね。これでインタラクティブにコマンドを実行できるんですね。

博士

そうじゃ！ インストールが終わったら、グラフィックスデバイスをリスト表示してみるのじゃ。デバイスの主要ノードとかレンダーノードとか、色々見えてくるぞ。

ロボ子

主要ノードとレンダーノードですか。それらは具体的に何をするものなんですか？

博士

主要ノードは、ディスプレイの設定とか、モードの設定とか、そういう重要なことをするのじゃ。レンダーノードは、3Dアニメーションのレンダリングとか、GPUを使う処理を担当するのじゃ。

ロボ子

なるほど！ 役割が違うんですね。記事には、コネクタの詳細情報を取得して、接続状態を確認するとも書いてありますね。

博士

そうじゃ。コネクタっていうのは、ディスプレイを接続するポートのことじゃ。HDMIとかDisplayPortとかじゃな。そのコネクタが接続されているか、どんなモードが使えるか、色々調べられるのじゃ。

ロボ子

モードというのは、解像度とかリフレッシュレートのことですか？

博士

その通り！ コネクタがサポートしているモードの詳細を表示できるのじゃ。あと、リソースのプロパティも取得できるぞ。`atomic`機能を有効にすると、追加のプロパティも取得できるらしいのじゃ。

ロボ子

`atomic`機能ですか。それは何をするものなんですか？

博士

`atomic`機能は、複数のディスプレイ設定をまとめて変更するためのものじゃ。これを使うと、画面がちらついたりするのを防げるのじゃ。

ロボ子

なるほど！ 重要な機能なんですね。記事には、フレームバッファの形式についても説明があると書いてありますね。

博士

フレームバッファは、画面に表示する内容を一時的に保存しておく場所じゃ。形式っていうのは、色の表現方法のことじゃな。XR24とか、色々な形式があるのじゃ。

ロボ子

ふむふむ。そして、VulkanバッファをDumb Bufferの代わりに利用して、3Dレンダリングもできるんですね。

博士

そうじゃ！ Vulkanバッファをdmabuf FDとしてエクスポートして、`Drm.Dmabuf.to_handle`でインポートするのじゃ。`K.Crtc.page_flip`を使ってフレームバッファを更新すれば、テアリングも回避できるぞ。

ロボ子

テアリングというのは、画面がずれて表示される現象のことですよね。

博士

その通り！ 最後に、デバッグ方法も書いてあるぞ。カーネルからのエラーコードを調べるには、`/sys/module/drm/parameters/debug`を使ってKMSデバッグメッセージを有効にするのじゃ。

ロボ子

なるほど。色々な情報が詰まってますね。OCamlトップレベルからlibdrm APIをインタラクティブに探索できるのは便利ですね。

博士

じゃろ？ `ocaml-ctypes`を使ってCバインディングを作成しているのもポイントじゃな。C APIの型の不整合には気を付けるのじゃぞ！

ロボ子

はい、博士。勉強になりました！

博士

ところでロボ子、ディスプレイの設定をいじりすぎて画面が真っ暗になったら、どうする？

ロボ子

ええと…、再起動ですか？

博士

正解！ …って、普通に再起動するしかないのじゃ！