TL; DR-Linuxのグラフィカル環境で、ビデオを見たり、ゲームをプレイしたり、インタラクティブなWebページをスクロールしたりしても、全体像を適時に更新できない場合は、4.10以上の最新の安定したカーネルをインストールするのが理にかなっています。
昔、つまり数年前、X11プロトコルの各実装は、父親のカーネル全体でビデオモードの変更を直接想定していました 。 その後、KMS(カーネルモード設定)が登場し、この重要な機能がカーネルに渡されました。 しかし、多少の粗さが残っていました。 原子レジームの変更は、KMSメカニズムのさらなる改善です。
アトミックKMS操作とは何ですか? 主にそのような瞬間を避けるために。

アトミックビデオモードの変更
アトミックモードの変更をサポートするDRMドライバー、。 k。 。 アトミックモード設定には便利な機能があります。これは、ビデオモードへの変更が有効になる前に完全なチェックに合格するということです。 これは、ドライバーやディスプレイ上での正しい実行を保証するために行われ、ユーザーのちらつき、引き裂き、その他の画像アーチファクトを防ぎます。 実行速度も向上します。 良さそうですが、どのように機能しますか?
- フレームバッファ -ただし、KMSの用語では、ビデオメモリは、ビデオオブジェクトGEMのメモリソースのプールであり、アクティブメモリゾーンや表示されるもの、データ形式、ステップ長などの特性が設定されています。
フレームバッファ

DRM/KMS Components: Framebuffer struct drm_framebuffer { [...] unsigned int pitches[4]; unsigned int offsets[4]; unsigned int width; unsigned int height; int flags; [...]
- CRTC-略語はCathode Ray Tube Controller、CRT Controllerの略です。 現在、ブラウン管でモニターを使用している人はほとんどいませんが、歴史的な名前は鉄の抽象化として保存されており、ビデオカードのメモリからバイトを読み取り、ピクセルをデータバスに出力します。
- エンコーダー -異種ビデオソース間のインターフェース、
CRTC
からの読み取り、コネクターへの転送CRTC
k。 。Connector
1つのCRTC
複数のエンコーダーをCRTC
ことができます。 - コネクタ -これは、モニタのコネクタのビュー、または外部画面が接続された組み込みデバイスの場合はモニタ自体のビューです。
- プレーン-CRTC上の画像のレイヤーまたはプラン。

これを行うには、この革新なしでビデオモードがどのように変化するかを理解する必要があります。 ユーザーがハードウェアアクセラレーションを使用して、全画面表示ではなくブラウザーまたはプレーヤーウィンドウでビデオを視聴する一般的なシナリオを考えます。 ビデオは、ブラウザまたはプレーヤーの前景、ウィンドウ、およびシーナリーを形成します。これが2番目の背景です。
- さまざまなパラメーターのリストがビデオドライバーに渡されます:フレームバッファー、CRTC、画面、モード。
- ユーザーがプレーヤーウィンドウを移動します。
- これを行うには、新しいページ、load k。 。 たとえば、 ページフリップ 。
- 新しいページが前景と背景の間で同期されていない場合、ビデオはウィンドウに対して相対的にシフトします。
struct drm_mode_crtc_page_flip { __u32 crtc_id; __u32 fb_id; __u32 flags; __u32 reserved; __u64 user_data; };
最後から2番目のステップで同期を確保するメカニズムはありません;すべての作業を行うioctl()
はありませんでした。 たとえば、メインプランだけが、イベントの正確な完了を伴う重要な更新をブロックしないメカニズムを備えていました。 また、更新が複数のレイヤーで発生するためには、ユーザー空間からのシステムコールの束が、 同期的に完了することを期待して必要でした 。 同時に、KMSアトミック操作にはこれに対する組み込みの保護があります。 3つの異なるioctl()
代わりに、すべての変更は1つの ioctl()
行われます。
実際、ビデオを見ながらアクティブゾーンとバックグラウンドが同期しないという問題は、GLを使用してすべてをリンクすることで解決されました。GLはVBlankと同期してフレームを更新できるためです。 すべては問題ありませんが、モバイルデバイスの場合、GLリンカーのメモリと電力の要件が高いため、 これは受け入れられません 。
「アトミック」プロジェクトの作業は2015年に開始され、 Dave AirlieパッチはIntel i915
といくつかのドライバーに加えて、新しいアトミックAPIに影響を与えました。
現在、アトミック更新プロセスは次のとおりです。
- すべての変更は、 プロパティの 1つのリスト(
Properties
画像の中央)とともにカーネルに転送されProperties
。 - カーネルはデバイスの状態を生成します ( 状態の図の右側)。
-
atomic_check()
は、 プロパティリストのすべての要素の有効性をチェックします。 エラーがある場合、ioctl()はエラー通知を返し、更新を破棄します。 -
atomic_commit()
も、名前に従って、前のステップのatomic_check()
がエラーなしで完了した場合に変更を導入します。

アトミックKMSの構造は、ファイル/usr/include/uapi/drm/drm_mode.h
定義されています。
#define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define DRM_MODE_ATOMIC_TEST_ONLY 0x0100 #define DRM_MODE_ATOMIC_NONBLOCK 0x0200 #define DRM_MODE_ATOMIC_ALLOW_MODESET 0x0400 struct drm_mode_atomic { __u32 flags; __u32 count_objs; __u64 objs_ptr; __u64 count_props_ptr; __u64 props_ptr; __u64 prop_values_ptr; __u64 reserved; __u64 user_data; };
オープンなNvvea Nouveauドライバーの場合、Atomic KMSはLinux 4.10以降、4.12以降のIntelドライバーに対してデフォルトで有効になっています。 さらに-もっと!