ToDo:
Windows10 20H2環境からFreeBSD 12.2-STABLE上のsamba4.13共有上に置かれたファイルをコピーしようとすると、署名が無いといって失敗する謎現象
状況から、Windows10 20H2に入れてある Nortonが諸悪の根源ぽぃ
あるいは、Norton入れたまま半期アップグレードを複数回跨いでいるので、正しいインストール状態になっていないとかか？
(UltraVNCなどは、半期アップグレード後に再インストールするまで挙動がおかしかった)
GT710/DVI-D接続からGT1030/HDMI2.0接続に変更してからVT-switchまわりがおかしい…
GT710/DVI-D環境はXorg終了後コンソール画面に戻れたが、GT1030/HDMI2.0環境だとXorg終了後コンソール画面が暗転したままになる。
暗転状態でもキー入力は受け付けられ再度xinitするとXorgの画面に戻るし、XorgからCtrl+Alt+FnなVT-switchは問題なくうまくゆく
Xorg終了時のVT-switchだけうまくいかない状況に… 致命的ではないとはいえ、釈然としない…
コンソール画面の解像度がGT710/DVI-D時と違うのが原因？ だとすると、UEFIファームのCSM回りの設定の違いかなぁ…
要検証なのでメモメモ
GT1030にHDMI2.0接続とDisplayPort接続(こちらは、DisplayPort->DVI-D変換経由)を用意して、 HDMI2.0接続のみの状態でXorgを起動・終了してHDMI2.0系出力が沈黙した状態で、DisplayPortからDVI-D変換経由でモニターを繋ぐとこちらは映る状態になっている
どうやら、Xorg終了時のVT-Switch先が起動時のコンソール出力先と関係なく、何らかの優先順位で自動決定されている？
GT1030にDisplayPort=>HDMI2.0変換アダプタ経由でHDMI接続のモニタのみを繋いだ状態だと、Xorg終了時もモニタが復帰することを確認
テスト対象のMSI GT1030では、DisplayPort出力がDFP-0、HDMI2.0出力がDFP-2に繋がっている。 Xorg終了時のVT-Switch先は、DisplauPortがつながるDFP-0が優先となる模様
nvidia-driver自身は、起動時に繋がっているモニタを認識しているし、X動作中のVT-Switchはきちんと出来ているので、Xorg終了時のVT-Switch処理を直せばいいはずだけど…変換ケーブル持ってくる方が簡単か Orz (ついでにPC側がラッチ付きになる)
srcツリーの配布ルートがSubversionからGitに切り替えられたので、ごそごそ対応作業実施…
ローカルの差分やらkernel config抱えたツリーのアップデートが面倒になりそうな予感…
あと、Gitには単調なrepository revisionが無いので、kernelに埋め込む revisionタグはどうするのだろう？ CURRENT/STABLE回りで不具合調査する際には、revision番号で2分探索とかするのに便利なのですがねぇ…
mergemasterは、/usr/srcから作ったetcと/etcのコンテンツの変更検知トリガーにFreeBSDタグに展開される revisionを使っていた気がする
/etc/groupとか/etc/master.passwdなんかだと、配布状態と異なっていても配布状態と等しいFreeBSDタグが入っていると更新対象にならなかった気がするのだが、この辺どうするんだろう…
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記