0

ネットワークから受信したデータを受け取り、さまざまなアクションを実行する小さなサーバー プログラムに取り組んでいます。これらのアクションの 1 つは、システムで実行されている X サーバーとの接続を開き、キーの押下をシミュレートすることです。X 内の端末からサーバーを起動する場合は問題ありませんが、プログラムをシステム サービスとして起動し、クライアントから要求されたときに X と通信するようにしたいと考えています。

XOpenDisplay(NULL)私が抱えている基本的な問題は、X 内部から開始されていないプロセスでの呼び出しが失敗することです。私が理解している限り、X の外部から X ディスプレイを開くことはできないため、考えられる最善の回避策は、ユーザーが X にログインしたときに開始され、シグナルまたはメッセージを待機する別のプログラムを作成することです。要求されたアクションを実行します。このヘルパー プログラムが実行されていないか、何らかの理由で失敗した場合、サーバーがクライアントにエラーを返すことができると想定しても問題ありません。

質問: 上記で説明したことは、(面倒ではありますが) 最善の解決策ですか、それとももっと良い方法がありますか? 実際、X の外から X ディスプレイを開く方法はありますか? ありがとう！

4

2 に答える 2

3

「X の内部」にいるということは、DISPLAY環境変数を設定するだけの問題です。これはどこからでも実行できます。

問題の X サーバーが別のユーザーのために実行されている場合は、Xauthorityチケットなどの認証トークンも処理する必要がある場合があります。

ただし、説明したユースケースでは、システムの実際のディスプレイハードウェアとは関係なく、独自の X サーバープロセスを実行することを強くお勧めします。これはXvnc、対話的に検査するために接続する場合、または単純なヘッドレス実装を行う場合、またはXvfb表示バッファーがまったく必要ない場合です。このアプローチにより、ユーザーがログインおよびログアウトするときにソフトウェアを再起動する必要がなくなります。

于 2012-10-19T21:15:46.480 に答える
1

マシンで実行されている任意のプロセスからXディスプレイに接続できDISPLAYます。接続するXセッションを示す変数セットが必要であり、正しいXAuthorityトークンが必要な場合があります。

ただし、基本的に表示番号を推測し、認証の問題を回避する必要があるため、これはケースの「厄介な」解決策と見なされます。また、デーモンの起動時にXサーバーがまだ起動していない場合、またはデーモンの実行中にXサーバーが再起動された場合も処理する必要があります（Xクライアントライブラリは、実際には次の場合を処理するように設計されていません）。 Xサーバーがなくなり、再び戻ってきます）。

「クリーンな」ソリューションは、実際には回避策として提案したソリューションです。つまり、UNIXドメインソケットなどを介してデーモンに接続するXセッション内で実行されているクライアントです。

于 2012-10-19T21:45:16.777 に答える