X.org X Windowsシステムでは、マウスカーソルはどのように実装されていますか？具体的には、これらのエラー条件をどのように理解する必要がありますか？
1）時々、GUI全体が遅くなったり、遅くなったり、止まったりするのを見たことがあります。しかし、マウスカーソルはまだ非常に迅速に反応します。たとえば、メモリが多すぎて「ゴミ」が始まると、これが発生する可能性があります。 （システムは常にディスクに交換され、再びディスクに交換されます。）
2）他の場合は、Linuxグラフィックスドライバがクラッシュすることがよくあります。画面が静止しているか破損しているか、その間にある可能性があります。しかし、時には静止または損傷したディスプレイ上でマウスカーソルが反応を維持することがあります。
破損したマウスカーソルが原因で発生する可能性があるいくつかの問題（および回避策）のヒントもあります。
私）テキストモードに入り、グラフィックモードに戻ると、マウスが消える問題が解決するのはなぜですか？
2）グラフィックは暗くなりますが、マウスカーソルは暗くなりません。
ベストアンサー1
これには少なくとも2つの詳細があります。
- ハードウェアカーソル
- カーソル更新は意図的に優先順位が付けられます。
1. ハードウェアカーソル
最初の詳細はよりよく知られています。 XorgのオプションドキュメントにありますHWCursor。
あなたのグラフィックおそらくハードウェアカーソルを使用します。ハードウェアがピクセルをディスプレイにスキャンすると、メインフレームバッファの上にマウスカーソルが重なります。
- グラフィックドライバのバグにより、ハードウェアカーソルが破損することなくフレームバッファを誤って設定できます。
- または、誤って設定されたハードウェアカーソルが破損する可能性があります。しかし、ディスプレイの残りの部分が壊れているように見えても、壊れたカーソルが動いて反応することがわかります。
- あるいは、フレームバッファが良好な場合、カーソルが誤って設定されている可能性があります。 「と同様にマウスはありません。「ケース。
1.1 ソフトウェアカーソル
ハードウェア カーソルは非常に便利ですが、ソフトウェア カーソルをよりよく機能させる技術があります。
https://www.x.org/wiki/Development/Documentation/InputEventProcessing/
ソフトウェアで実行されている場合は、カーソルをバックバッファーする必要があります。移動するたびに前の画像を復元し、ターゲット位置にウィンドウを保存し、カーソルをストリームにレンダリングします。
xorg-server-1.20.5/mi/midispcur.c- miDCSaveUnderCursor() / miDCRestoreUnderCursor()
2.意図的にカーソル更新の優先順位を設定します。
公平に言えば、カーソルは比較的簡単です。しかも着実に使われています。これは、メモリが不足し始めたときにカーソル関連のメモリが交換される可能性が低いことを意味します。しかし、もう一つの詳細があります。
https://who-t.blogspot.com/2016/09/input-threads-in-x-server.html
以前は、入力ドライバにイベントをXサーバーに転送する方法について、シグナルハンドラ内でイベントをポーリングまたは転送する2つのオプションがありました。ポーリングは、単にすべての入力デバイスのファイル記述子をサーバーの基本ループで処理されるselect（2）ループに追加します。ここでの欠点は、サーバーが何かをレンダリングしている場合、レンダリングが完了するまで入力が遅れることです。歴史的に、ポーリングはキー入力が遅れるタイミングが重要ではないので、キーボードドライバで主に使用されてきました。どちらもクライアントがとにかくレンダリングする必要があるため（忙しいときはレンダリングできません）、おそらく私たちは入力遅延に慣れているからです。
シグナルハンドラアプローチは、各入力デバイスfdにSIGIOハンドラをインストールし、入力が発生したときに対応するハンドラを呼び出して遅延を防ぎます。これは、サーバーが現在何をしているかに関係なく、シグナルハンドラが完了するまでプロセスを効果的に停止します。良い解決策即時の可視カーソル移動を提供 （これはevdev、synaptics、wacom、および現在廃棄されているほとんどのレガシードライバで使用されます）
[...]
ドライバはシグナルハンドラ中にイベントをキューにプッシュし、サーバーはメインループからイベントを読み取り、処理します。使用量の多いサーバーでは、画面上でポインタの移動が実行されてから数秒かかることがありますが、まだ反応するように感じます。
[...]
libinputが登場するまで、私たちはまだ「満足」していました。 libinputは完全な入力スタックであり、信号ハンドラで動作することを期待しているのは、楽観的、マゾヒスト的、および加法的なものの間のどこかにあります。 xf86-input-libinputドライバはシグナルハンドラを使用しません。その副作用は、サーバーがレンダリング中にlibinputがあるデスクトップが応答しないような気がします。
Keith Packardが介入し、サーバーをシグナルハンドラから入力スレッドの使用に切り替えました。具体的には、メインスレッドの上に入力スレッドがあることです。このスレッドは、すべての入力デバイスのファイル記述子を制御し、そのイベントを継続的に読み取ります。それ以外の場合は、以前にシグナルハンドラが行ったのと同じ機能を提供します。つまり、ビジュアルポインタの移動とイベントキューにイベントをプッシュして、後でメインスレッドで処理できるようにします。しかし、もちろんスレッドに切り替えると問題が発生します。 [...]いくつかの興味深い競争条件が引き続き発生します。しかし、現在ではほとんどの問題が解決されたと思います。