コグノスケ

たまにズレちゃうWindows 10

目次: Windows

Windows 10は自動的にWindows Updateを実行し、勝手にPCを再起動することがあります。その際にウインドウの幅がズレることがあります。

タイトルバーとウインドウの幅がずれる

ウインドウの幅が多少ズレても実用上害はありませんが、この状態と同時に発生する、フォント表示がボヤボヤになって、サイズがおかしくなり、非常に読みづらくなる症状が辛いです。目が痛くなってきます。

いずれの症状もPCを再起動すると直ります。直る理由すらわかりませんが、今のところ直らなかったことは一度もありません。

不思議なことにWindows Update後に必ずズレた状態になる訳ではなく、何か他の条件があるようです。人が見ていない夜中に再起動して、勝手にこの状態にハマるので、詳細は確認しようがないです。

我が家でのWindowsの存在意義

最近のWindowsは再起動により、作業中のアプリケーションが全て終了され、当初かなりイライラしていました。

しかし今は「Windowsで大事な作業をしない」ことにより、諦めがつきました。デスクトップPCは勝手に再起動されては困るので、Windowsごと消しました。さようなら〜。

ノートPCは再起動されても特に問題ないのでWindowsを残しています。なぜなら最近Windows上で実行しているアプリケーションは、

ブラウザ

強制終了されても最後に開いていたページを覚えている。

VNCクライアント

強制終了されてもLinuxマシンが動き続けているので問題ない。

しかないからです。あとは、たまに音楽プレーヤーやSteamを起動しますが、起動しっぱなしにはしません。たとえ強制終了されたとしても問題はありません。

この使い方はほぼシンクライアントですね。わざわざカスタムオーダーまでしてCore i5-8250と外部グラフィックスAMD Radeon RX550を積んだのに、彼らがSteam以外で活用されることはありません……。

つまり、もっとゲームをやりなさいということだな？？

ROCKPro64とPCI Express - 動作せず

目次: ROCK64/ROCKPro64

ROCKPro64にはPCI Expressスロットが実装されています。せっかくあるので試そうと思い、玄人志向のSATAインタフェース増設カード（SATA3-PCIE-E2）と、USB 3.0インタフェース増設カード（USB3.0R-P2H2-PCIE）を買いました。

結論から先に言うとRK3399のPCI Expressコントローラは有効にできましたが、ROCKPro64の信号品質が良くないのかUSBのカードしか認識しませんでした。残念です。

唯一認識されるUSBのカードもPCI Expressのライザーカードで延長すると認識しなくなります。認識できるギリギリの信号なんですかね。

rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!

認識されないときはこんなエラーログが出ています。うーん。

有効にするだけでは動かないRK3399のPCI Expressコントローラ

RK3399のPCIeコントローラもちょっと癖があって、ep-gpiosプロパティを指定しないとprobe時にエラーで落ちます。このドライバはGPIOを使ってレギュレータを操作し、PCI Expressへの電源供給を制御したいようです。

通常、デバイスドライバで電源制御を実装したい場合vpcie12v-supplyのようなレギュレータを指定するプロパティを使いますが、なぜGPIOを使っているのでしょうね……？

しかもうまくないことにROCKPro64の場合、既にPCI Express用レギュレータのデバイスノードが定義されており、常にPCI Expressの電源をONにしています。そのためPCI ExpressのデバイスノードにGPIOを追加すると「もう使われているよ！」と怒られてしまいます。

どう直すのが正しいのかわかりませんが、とりあえずPCI Expressのドライバを改造し、GPIOのエラー処理を削ったら先に進みました。しかし良くハングするようにもなりました。イマイチだ……。

後日、直すことができました（2019年5月9日の日記参照）。

メモ: 技術系の話はFacebookから転記しておくことにした。追記した。

ROCK64のUSBをデグレさせた

目次: ROCK64/ROCKPro64

昔、私が投稿したパッチがLinux 4.20をデグレさせていました。Linux 4.20以降ではROCK64のUSBが動かなくなっています。全然気づきませんでした……。

Arch Linuxの人たちが「動かねーぞ？？」とハマった挙句（リンク）に、指摘してくれたようです。

反省を込めて、ROCK64がデグレした理由をまとめておきます。

当時、私が直したのはピンに出力する信号の割り当て設定です。

GPIO0 A2

• 本来の出力: USB電源供給Enable/Disable信号
• 当時の出力: 何も割り当たっていない（が、なぜか動いていた…）

GPIO0 D3

• 本来の出力: S/PDIF信号
• 当時の出力: USB電源供給Enable/Disable信号

上記のように、本来GPIO0 D3にはS/PDIF信号が割り当てられるはずですが、なぜか全く関係のないUSB電源供給信号が割り当てられており、S/PDIFが全く動作しない状態になっていました。

私のパッチはUSB電源供給信号のピンアサインをGPIO0 A2に直すパッチです。GPIO0 D3ピンからS/PDIFが無事出力できるようになりました。

しかし実装の間違いはこれだけではありませんでした。GPIO0 A2は信号の極性（Active High指定でしたが、本来はActive Lowが正しい）も間違っていたのです。

GPIO0 A2

• 本来: USB電源供給Enable/Disable信号
• 実装: 何も割り当たっていない
• パッチ後: USB電源供給Enable/Disable信号（直った）
• 本来の極性: Active Low
• 実装の極性: Active High
• パッチ後: Active High（変化なし）

私のパッチはピンアサインだけ直して、信号の極性を直さなかったため、USBの電源が常にダウンしてしまい、USBが全く動かなくなってしまったようです。

USB電源周りをいじったのに、USBの動作確認をせずにパッチを投稿してしまったのは、片手落ちだったなあと反省しきりです。

メモ: 技術系の話はFacebookから転記しておくことにした。

誕生日

干支を3周しました。もう完全におじさんの仲間入りです。

若い人に自慢と説教だけはしないように気を付けよう。