タッチスクリーン付きの組み込みシステムを開発しています。タッチスクリーンは、入力と出力の両方として動作し、「仮想」キーボードがグラフィック出力をオーバーレイします。
kernel.orgのこのガイドを使用して作成された、タッチセンサーからの入力を読み取り、それをキープレスに正しく変換する機能するデバイスドライバーがあります。このドライバーを拡張して、画面への画像出力も処理したいと考えています。
できるだけ少ない重複でgettyとXの両方をサポートしたいと思います。最小限のXなど、厳選されたパッケージで最小限のDebianバリアントを実行しています。パブリックGitHubリポジトリにダンプする可能性がありますが、このドライバーをリポジトリパイプラインに入れようとするつもりはありません。
画面イメージの出力は、現在、危険な回避策を介して行われています。ディスプレイに接続されていないにもかかわらず、CPUの組み込みグラフィックスハードウェアにレンダリングを強制するブートオプションと、そのバッファーを継続的に画面スクレイピングするデーモンが、いくつかの事前変更を変更します。キーボードビジュアルを作成するピクセルを定義し、それを実際の画面にプッシュします。
これは概念実証として機能し、画面デバイスが期待する言語を正しく理解していることを証明しますが、明らかに最適ではありません。
kernel.org 「DRM」デバイスドライバーのガイドもありますが、私のハードウェアで可能なことは、次のように深刻になりすぎています。
Linux DRMレイヤーには、複雑なグラフィックスデバイスのニーズをサポートするためのコードが含まれており、通常、3Dグラフィックスアクセラレーションに適したプログラム可能なパイプラインが含まれています。
私のハードウェアには3Dアクセラレーションに似たものがないため、これはおそらく私が望んでいるものではないと結論付けます。
どのサブシステム/ APIを使用すればよいですか？欠落している用語の1つが私の検索を妨げているものだと思いますが、これを達成する方法についての情報がありましたら、いただければ幸いです。
ハードウェアの詳細（おそらく無関係）： CPUと画面は、CPUがネイティブでサポートしていない8080-esqueパラレルプロトコルを介して通信するため、GPIOでそれをエミュレートします（mmapを介してレジスターを操作することにより）。
完全な画面イメージの送信には約20ミリ秒かかりますが、組み込みグラフィックスバッファーから完全なコピーを取得するには約180ミリ秒かかるため、そのステップをスキップすることが最も重要な目的です。画面ハードウェアには十分なSGRAMが含まれています、フレーム全体のデータを保持するのにメモリが、長方形のサブ領域の書き込みをサポートしているため、変更された画面の部分のみを更新するフックが望ましいでしょう。
画面は、着信データのタイミングに特別ではありません。タッチセンサー入力は、CPUがサポートするI²Cを介してCPUと通信する専用のICによって処理されます。現在のドライバーはlinux/input-polldev.hインターフェースを使用します。CPUはBroadcom BCM2835であり、画面はHimax HX8357コントローラーが埋め込まれたTFTであり、タッチスクリーンセンサーデコーダーはST STMPE610であり、HX8357とBCM2835の間には電圧レベルシフター（Nexperia 74LVCH245A）があります。詳細については、リクエストに応じてご利用いただけます。