1日に5〜20回程度I / O負荷が高い場合にのみ発生する競合条件により、一時的な視覚的欠陥とハイゼンバーグが発生します。時間をかけてカメラをキャッチするには画面から早く消えるので、ショートカット/ショートカットを押した後、待ち時間が最も短いスクリーンショット/スクリーン録画ツールを探して/作成しています。タスク/応答を実行します。
決定的に、ツールの高い応答性は、高いI / Oアクティビティ（たとえば、20〜40の10秒の負荷平均）によって無視できるほど（理想的にはまったく影響を受けてはいけません）必要です。
PREEMPT_RTXorgと自家製のスクリーンショットデーモンをリアルタイムでロードして実行することについて公正な主張が出ることがあります。これはうまくいくでしょう... Xをリアルタイムで実行する部分を除いて、実際にコンピュータで作業を完了したいと思います。 :)
実際、私の好きなコードをLinuxカーネルに入れるだけで、自分のコンピュータでリアルタイムで安全に実行できます。さて、カーネルモジュールの時間です！ ！私の質問をもう一度申し上げると、
Linuxカーネルモジュールで画面のピクセルを表すメモリ領域を見つけ、アクセスし、理解する方法は？
/dev/fb0Xの実行中に読み取ろうとすると、黒い画像のみが生成されるため、明らかに機能しないことがわかりました。
残念ながらhttps://dri.freedesktop.org/docs/drm/gpu/index.htmlフレームバッファの再読み込みに明らかに関連するものは表示されませんが、このAPIの経験がないので、実際に何が欲しいのかわかりません。
ドライバ固有のコードが必要になる可能性があることを認めます（実際には、画面に表示される内容を示すドライバに依存しない仕様点がメモリにある可能性がほとんどないため）。私は現在Intel-GPUベースのコンピュータを使用しており、そのためのコードを直接書くことができてうれしいです。
今後、別の表現のバージョンを要求しました。この質問は2年も経っておらず提起されました。この質問はHDCPについて1つのコメントしか引きずり、答えを受け取らなかった。しかし、2年が過ぎた今でも1日に最大20回までこの問題を処理しているので、もう一度試してみました。
（現在の方法（scrotホットキーバインダーで始まるi3）は、I / O負荷の高いシステムで単一のスクリーンショットを撮るのに最大20（!!）秒かかることが多いです。）