スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 何とかなりそうだ | トップページ | 1933年国際連盟脱退 »

ポイントはPython

今は、Ubuntu版Mirror-DTCの開発フェーズで、今回は、18.04LTS対応も強化しようとしているのだが、そのメイン項目はログイン画面の操作だ。もっとも、実際の問題は、様々なイベントへの対応になっていて、その解決にはPythonの活用が重要だ。

ここの所の調査/テストの結果から、今日の時点で、手元のUbuntu18.04LTS環境では、Mirror-DTCサーバーでは以下の処理が可能になっている。
 
1.ログイン画面操作
2.ログイン画面→デスクトップ画面操作への移行
3.デスクトップ画面操作
4.サスペンド時の遅滞ない接続切断
5.リジューム後の再接続受け入れ
6.デスクトップ画面→ログイン画面操作への移行
7.再起動/シャットダウン時の遅滞ない接続切断
 
現行のUbuntu版では、Ubuntu16.04LTS環境では、同梱してある資料に従って環境を構築すれば、上記の4,7以外は実現されているのだが、Ubuntu18.04LTS環境では、同様の環境を構築する資料は同梱されていないので、上記では、3だけしか実現されていない。
 
と、言うことで、次バージョンでは、Ubuntu18.04LTS環境では大幅に利便性が向上し、16.04LTS環境でも、現在の環境に若干の追加を行えば、上記と同様の事は可能に出来るので、若干の利便性向上が図れる事になる。
 
で、上記はどのようにして実現しているのか、という話になるのだが、まず、ログイン画面操作に関しては、デフォルトのWayland描画ではキャプチャーが出来ないので、Xorg描画に設定変更しつつ、Systemdのサービスを構築する事で、PCが立ち上がった直後にMirror-DTCサーバーが立ち上がるようにしている。
 
この時、問題になるのは、Systemdのサービスはrootとして実行されるのだが、X-Window絡みの環境変数が設定されていないので、X-Windowから画面データをキャプチャーしたりキーボード/マウス操作をエミュレートするMirror-DTC的には、ログイン画面用の環境変数設定が必要になる、という事だ。
 
もっとも、環境変数を設定しても、ログイン画面では、ダイアログ表示なんかは見えないので、GUI操作抜きでサーバー操作する必要があるのだが、Mirror-DTC的には、元々、そういう操作用のオプションはある訳なので、今回も、そのオプションを使用している。
 
で、上記でログイン画面操作は可能になるのだが、18.04LTSの場合、ログイン後にはログインユーザー用にDISPLAYが新設され、それが使われるので、上記のサーバーに接続したままだと、デスクトップ画面の操作は出来ない。
 
なので、ネットを見ていると、VNCサーバーなんかでは、上記でログイン画面の操作を終えた後、クライアントから接続を切断して、ログインユーザー空間で起動されている新しいサーバーに接続し直せ、みたいな使い方が書かれている。
 
これに対して、Mirror-DTCの場合、サーバーがクライアントに対して接続リトライを要求する機能があるので、クライアントを操作しているユーザーに手動で接続をやり直させる必要はない訳だ。
 
もっとも、そのためには、接続リトライを要求するタイミングを把握できる必要があるのだが、ログイン/ログアウトが実行されたタイミングでは、GDM3でスクリプトを実行できるので、そのスクリプトで、イベント通知用に自前のファイルを作成/削除する仕組みを構築できる。
 
つまり、Systemdで動作させるサーバーは、サーバー本体ではなく、上記のファイルが存在しない場合にログイン画面用のサーバーを起動し、存在する事を確認したら終了させるスクリプトにしておけば、ログイン画面用とデスクトップ画面用の両方のサーバーを同一ポートで排他的に実行できる様になるので、ログイン⇔デスクトップの切り替えもスムーズに行える様になる。
 
ただし、GDM3で実行可能なログアウト時のスクリプトは、実際にログアウトが行われた後に実行されるので、そのタイミングでは、既にネットワークが使えないので、サーバーがクライアントに対して正常な切断シーケンスを実行する事は出来ない。
 
なので、デスクトップ画面用のサーバーを終了させるトリガーは別に必要になるのだが、このような目的で便利になるのが、D-Busになる訳だ。
 
D-Busというのは、Linux環境でプロセス間通信を行う仕組みになるのだが、実際の所としては、Windows環境のメッセージシステムみたいな捉え方も出来る訳だ。
 
つまり、Windows環境では、サスペンドなんかの特別なイベントが発生する場合には、その旨がブロードキャストメッセージで全てのアプリに通達されるので、アプリ的には、そのメッセージを受けて、必要な処理を事前に行えるのだが、Linux環境では、D-Busのシグナルというのが、同様な感じのモノとなる。
 
なので、アプリ的には、D-Busのシグナルを受信して、必要な処理を行ってやれば良い訳なのだが、D-Busからは、ログインセッションが終了する前に、その準備をしろ、みたいなシグナルが送られてくるし、サスペンド/リジューム/シャットダウンについても、シグナルを受信しておけば、事前に必要な処理を実行できる。
 
と、言うことで、次バージョンで現行版では実現されていないサスペンド対応等が可能となるのは、上記のD-Busのシグナルを扱う様になるからなのだが、D-BusからのシグナルをC++のアプリ本体で受信して処理するのは至って大変だ。
 
何故なら、ネットをいくら検索しても、そのために必要になるライブラリ等に関する情報が得られないからなのだが、それでは、D-Busは扱いが面倒すぎて誰も使っていないのか、というと、そんな事はなくて、ネットをかなり真面目に検索してみれば、Pythonを使った実現方法が見つかる筈だ。
 
つまり、Python用には、D-Busを簡単に扱えるライブラリがUbuntuではデフォルトで提供されているので、Pythonを使ってスクリプト処理する分には、前述の様なD-Busのシグナルは簡単に受信して、それに対応するシグナルハンドラーで必要な処理を行える。
 
と、言うことで、次バージョン用には、Mirror-DTCサーバーをサービス化する為のスクリプトはPythonを使って記述しているのだが、16.04LTSまでは、Pythonのバージョンは2だったのだが、18.04LTSでは3になっている。
 
なので、Ubuntu18.04LTSのデフォルト環境を使う場合には、Pythonのスクリプトはバージョン3用に書いておく必要があって、16.04LTS用にはバージョン2用のスクリプトが必要だ。
 
と、言うことで、Ubuntu18.04LTS用のログイン画面対応等については、外部スクリプト等を使って実現できた感じなので、明日からは、本体をVer1.4.0相当に変更する作業に移る事にする。

« 何とかなりそうだ | トップページ | 1933年国際連盟脱退 »

トラックバック


この記事へのトラックバック一覧です: ポイントはPython:

« 何とかなりそうだ | トップページ | 1933年国際連盟脱退 »

2019年9月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google