20で再現できるかやってみました。条件は同様でgdm3は終了させてxrdpのみ起動しています。結論から言うと再現しました。以下が通常時のログです。正常に画面が表示されます。existsログにはデバッグ有効であること以外は特に何も出ません。FIFOが作れない警告が出ます、これは何だろう?まあいいか。次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。画面は真っ黒になってすぐに切断されます。LTSでも再現するんですね。ログは下記のようになりました。Sorry....前回も見かけたamdgpu_get_auth()のエラーが出て止まりました。AMDのGPUの場合、エラーが起きると止まってしまう疑いが強まりました。本当はエラーが起きたらソフトウェアレンダリングにフォールバックしてほしいんですけど、そうならないようです......。デバイスファイルが/dev/driに全く存在しなくてもamdgpu_get_auth()が怒ってくるところを見ると、X.orgはPCのグラフィクスの種類(VirtualBoxなのかAMDのGPUなのか)を最初から決め打ちにしているんですね。01:33)コメント一覧コメントはありません。7.0.18で再現できるかやってみました。グラフィクスはVMSVGAを選択しています。VMSVGAは/dev/driの下にcard0とrenderD128が生成されるようです。ちなみにgdm3は終了させてxrdpのみ起動しています。ちなみに結論から言っておくと再現しません。以下が通常時のログです。正常に画面が表示されます。‘gsettings-backend’ログにはデバッグ有効であることと、libEGLが何かしら見つけて反応しています。それ以外は特に何も出ません。次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。正常に画面が表示されます。えぇー?ログは下記のようになりました。authenticateが出ています。エラーは無視されるんでしょうか?謎の動きですね。15:08)コメント一覧コメントはありません。LTSのxrdpに接続すると真っ黒な画面しか出ず、すぐに接続が切断されてしまう問題に遭遇しました。どこでクラッシュしているか調べるため、xrdpがGNOMEを起動するところまでを追いかけると下記のようになっていました。/usr/libexec/gnome-session-binaryスクリプトx-session-managerを書き換えてgnome-session-binaryの引数に--debugを足すと、GNOMEはより詳細なメッセージを出力します。メッセージはホームディレクトリの.xsession-errorsに記録されます。GNOMEのエラーメッセージは下記です。Sorry....エラーメッセージ曰くamdgpu_get_auth()が失敗しています。関数名から推測するにAMDのGPUが装着されているマシンでしか発生しないエラーなのかもしれません。ret;}ソースコードから推測するにグラフィクス系のデバイスファイルにioctl()しようとして失敗しているものと思われます。Infrastructure)と呼ばれるインタフェースを経由してGPUを使用します。Manager)を使用してGPUにアクセスします。DRMのデバイスファイルは/dev/driディレクトリの下にありますが、名前がDRIだったりDRMだったりして謎ですね。グラフィクス周りはあまり詳しくなくて理由はわかりません......。/dev/dri/renderD128上記のようにキャラクタデバイス/dev/dri/card0と/dev/dri/renderD128のパーミッションを0666にしたところエラーが出なくなりました。今回はこの2つのデバイスファイルで解決しましたが、他のデバイスファイルにもアクセスしていた場合はさらに調査が必要かもしれません。グラフィクス系のエラーは簡単に調べる方法がないのが辛いですね。ちなみにこの症状はQEMUだと再現しません。card0のパーミッションを0000にするとlibEGLがエラーになるのですが、なぜかGNOMEはエラーを無視して起動してしまいます。AMDのときだけなんで止まるんでしょうか。釈然としません......。08:30)おー、面白いですね。xrdpはすでに立ち上がっているVNCサーバーにつなぐ設定しかしたことがなくて、startwm.shなんてスクリプトがあったとは...この前WaylandのWestonを少し触ったんですが(ちなみにWestonにもRDPやVNCを提供する機能もあります)、その時にrendererにCPUを使うかGPUを使うかの選択肢がありました。Container上でXwaylandとXアプリケーションを走らせてホスト側Weston上に出すみたいなことをしたんですけど、GPUを使う設定だとXwaylandがDRMデバイスを探してしまってcontainerからアクセスできないのでエラーになるというのがありました。それで、QEMUだと再現しないというのは、まともなハードウェアアクセラレーションがないのでソフトウェアレンダリングになっているのかな、と思いました。/dev/driはkvmと同様にローカルのログインユーザーにはudevのuaccessでアクセス権が与えられていますね。10:12)私は逆にVNCサーバーに繋ぐ使い方をしたことがなくて、違いがわかってないです。あと今回調べて初めて構造を知ったので、正しいのか若干不安です。Westonは触ったことないですねえ。コンテナ内でもないから普通に動作してほしいところです。GNOMEがハードウェアレンダリングかソフトウェアレンダリングかどちらを選択したのか確認しなかったですね。ログに出るかな?パーミッションに関してはおっしゃる通りで/dev/driは通常パーミッションの問題は発生しないですが、なぜか今回は変な現象が発生しました。19:05)GNOMEをお使いでしたら今はWaylandにも対応していますから、Westonと同じようにRDPのバックエンドを選べてもよさそうです。パーミッションは、AMDだからというよりは、たぶんローカルでログインした扱いになっていないんじゃないかと思います。uaccessの設定は端末の眼の前で直接ログインした時にはアクセス権が付与されるんですが、それ以外のSSHとかVNCとかでは付与されないものです。昔、大学の共用計算機システムみたいなところで、光学ドライブのパーミッションが0666になっていて、人が使っているところにリモートログインして勝手にejectを実行する、なんて遊びがありましたが、そういうのができないように、今はuaccessで管理されるみたいですね。03:41)xrdpで十分動作しているので、Waylandにはそこまでこだわってないんですが、時代はWaylandなのかなあ。uaccess知らなかったので少し調べてみたら、TAG+="uaccess"をルールに追加するとpam-systemdからsystemd-logindに依頼が行ってACLでパーミッションが設定される、なんて仕組みがあるんですね。複雑だなあ......。編集するTAS動画をニコニコ動画にアップロードできないクラッキングでぶっ壊されてしまったニコニコ動画が復活し、シン・ニコニコ動画になって帰ってきました。いちユーザーとしては嬉しい気分でいっぱいです。前と比べて困ったことが起きていて、BizHawkで出力した動画をシン・ニコニコ動画にアップロードしようとすると「この動画の映像形式には対応していません」とエラーが出てしまって投稿できません。試行錯誤の末、解決方法を見つけたのでメモしておきます。端的に言えば原因はピクセルフォーマットでした。BizHawkは特に何も言わないとYUV444で出力しますが、ニコニコ動画はYUV420でないと受け付けてくれないようです。どこにもそんな制約は書いていないため、仕様か?バグか?どちらともわかりません。YUV420にする方法ですけども、BizHawkの出力設定を[Custom]にして、下記のようにピクセルフォーマットを明示的に指定すればYUV420で出力してくれました。mp4もしすでにYUV444で出力済みの動画ならば、ffmpegを使って再エンコードすれば良いです。output.mp4動画ビットレート(-vb)、フレームレート(-r)、動画サイズ(-s)は元の動画に応じて調整してください。01:07)コメント一覧コメントはありません。CPUの拡張機能をどのように認識し有効にするか調べました。今回はどのようにCPUの数を認識するか調べます。OpenSBIのプラットフォームは今まで同様にgenericを使います。実はそんなに難しくなく、デバイスツリーの/cpuノードを読みに行くだけのようです。virtマシン、4CPUで起動したときにQEMUが生成するデバイスツリーを下記に示します。名前やラベル、regが2や3になるだけです。*/};OpenSBIがCPU数を確認するコードは下記のようになっています。tree)の/cpuノードを見て、子ノードがCPUの定義であり、有効ならばhart_countを+1するシンプルなコードです。1までの連番)とhartidの対応表generic_hart_index2id[]も同時に作ります。無効なCPUはどうなるか?無効なCPUの扱いも見ておきます。"disabled"つまり無効なCPUの場合は、hartindexとhartidの対応表(platform.hart_index2id[])にhartidが載りません。"disabled"にしたときのhartindexとhartidの対応表をダンプします。3となっていることがわかります。次にメインCPUがサブCPUを起こしに行くコードを見ます。アセンブラなので若干分かりづらいですが、hartindexとhartidの対応表に自CPUのhartidが登録されていればCPUを起動し、登録されていない場合はCPUを起動しません。_start_hang//...OpenSBIのロゴが出たあたりでブレークして各スレッドの実行している関数名を見ると、下記のようになります。2(※)だけ_start_hang()に居ることがわかりますね。04:19)コメント一覧コメントはありません。08:30)「おー、面白いですね。最終勤務日でした、入門カードや会社のPCを返却してきました。マンガ紹介一覧が欲しくなったので作りました。マンガ紹介お気に入りのマンガ紹介シリーズ。最近完結した短めの作品を紹介します。