NZXT Signal 4K30の修理パート2：緑/ピンクのビデオバグ

昨年、私はeBayで安く手に入れたNZXT Signal 4K30 USBキャプチャデバイスを修理しました。それは完全に壊れていましたが、原因はインダクタのハンダ付け不良で、基板の重要な部分への電力供給を妨げていました。 修理後、正常に動作するか確認するために、さまざまなHDMIソースデバイスから信号をキャプチャしようとしました。前回の投稿で述べたように、720p60のHDMIソースのうち1つだけはうまくいきませんでした。キャプチャされたビデオはピンクと緑になってしまうのです。その投稿では、PS5やNintendo Switchで同様の問題が報告されているRedditのスレッドもいくつか紹介しました。 問題のHDMIソースからキャプチャしたビデオのスナップショットがこちらです。 ご覧のように、色は緑と紫で、完全に間違っています。ビデオエンコーダーやデコーダーに関する過去の経験から、これはRGBとYUVビデオの不一致が原因である典型的な動作だとすぐにわかりました。特にRedditで他の人も全く同じ症状を見ていたので、ハードウェアの故障だとは疑っていませんでした。そのままにしておきました。この1つのデバイスで正しくキャプチャできないことには関心がなく、NZXTに連絡することもありませんでした。 その後、このデバイスは市場から完全に姿を消したようです。AmazonやNeweggではもう購入できず、NZXTのウェブサイトでもサポート以外ではどこにも記載されていません。NZXTがキャプチャカード市場から撤退したのは明らかです。今連絡しても、何か対応してくれるとは思えません。 昨夜、ふとある考えが頭をよぎりました。最近、Claudeを使ってかなり詳細なリバースエンジニアリングやバグ調査を行っています。例えば、数年前に私が詳細に調査したElgato Game Capture HD60 S用のリバースエンジニアリングされたLinuxカーネルV4L2ドライバーがあります。これをClaudeにこの問題の調査を依頼したらどうなるだろうか？ハードウェアの問題を完全に解決した最初の投稿を締めくくる良い方法になるかもしれません。協力して、私がファームウェアの問題だと推測していた最後の問題を解決できるでしょうか？ ハードウェア修理の際、デバイスに使用されているさまざまなコンポーネントをすべて文書化していました。それをClaudeに提供し、問題の説明、Redditの投稿からの問題の写真、NZXTが2022年にリリースした最後のファームウェアアップデート、そしてSignal 4K30で使用されているITEのIT6805 HDMIレシーバーIC用のドライバーを含むGitHubリポジトリのチェックアウトも提供しました。また、過去にビデオデバイスのファームウェアを開発していた際にこのようなことがあったため、RGB対YUVの不一致のようなものだと疑っていることも指摘しました。 約15分後、Claudeから結果が返ってきました。YUV対RGBの不一致問題であるという意見に同意しました。有望に見えるファームウェアのバグをいくつか指摘してきました。確実を期すために、検出された信号についていくつか確認するように求めてきました。 Cortex-M0マイクロコントローラにはデバッグ出力付きのUARTがあると教えてくれました。PCB上の unmarked のデバッグヘッダーを見つけ、ポータブルオシロスコープでTXピン（およびボーレート）を特定し、問題のHDMIソースデバイスを取り付けた状態でその出力をキャプチャし、貼り付けました。また、前述のリバースエンジニアリングされたGame Capture HD60 S Linuxドライバーを使用して、問題のソースが出力していた信号の種類に関する詳細情報を提供しました。ソースデバイスはHDMIモードではなくDVIモードで出力していました。これは大きな手がかりでした。DVIモードということは、AVI InfoFramesのような、新しいHDMIソースに含まれる追加パケットがいくつか含まれていないことを意味します。 Claudeは、ITEの標準IT6805ドライバーのコードの一部を特定し、それが間違っていると指摘しました。このコードがNZXTのファームウェアにも存在することを確認しました。以下はその抜粋です。 ```c // REG6B[5:4]: Reg_ColMod_Set Input color mode set // 00: RGB mode - 01: YUV422 mode, 10: YUV444 mode, 11: YUV420 mode chgbank(0); if (iTE6805_Check_HDMI_OR_DVI_Mode(iTE6805_DATA.CurrentPort) == MODE_HDMI) { HDMIRX_DEBUG_PRINT(("---- CSC HDMI mode ----\n")); ... hdmirxset(0x6B, 0x30, iTE6805_DATA.AVIInfoFrame_Input_ColorFormat << 4); // seting input format by info frame ??? do not need ??? ... } else { ... HDMIRX_DEBUG_PRINT(("---- CSC DVI mode ----\n")); hdmirxset(0x6B, 0x30, 0x10); // seting input format to RGB ... } ``` このコードは、IT6805がHDMI信号またはDVI信号を検出したかどうかを判断し、その結果に基づいてさまざまなレジスタを設定しています。そのレジスタの1つは、IT6805が受信したビデオ信号をどのようにデコードするかを指示します。HDMI信号の場合、AVI InfoFrameからカラーモードを直接取得し、レジスタ0x6Bのビット4と5に設定します。一方、DVI信号の場合は、ビデオ信号がRGBである必要があることを認識しているため、レジスタ0x6Bの同じビットをRGBモードに設定しようとします。しかし…コードが間違っています。コメントは正しく「RGBモードに設定する」（“seting input format to RGB”）と述べていますが、実際にはビット5:4に0x10（16進数）を書き込んでおり、これは上のコメントによればYUV 4:2:2モードを意味します。 断言はできませんが、元のITE開発者が犯した間違いが見える気がします。最初にRGBモードのコメントに目がいくと、私の頭に「RGBモード - 01」という言葉が残ります。しかし、それは私の脳がコメントを誤って解釈しているのです。実際には「00: RGBモード」と書かれています。コメントがハイフンを1つしか使わず、それ以外はすべてカンマを使っていることが、私を混乱させるのだと思います。元の開発者も同じような解析エラーを脳で犯したとしても驚きません。 さて、これで理論ができました。どうやってテストできるでしょうか？デバッグUARTは、IT6805のレジスタを読み書きする方法を提供していなかったので、もしできたら簡単にテストできたのにと思います。楽しい話と、この修正を皆のためにリリースできる可能性のために、デバイスをブリックするリスクを冒す価値はあると思いました。Claudeはこれに非常に慎重で、まずSWD経由でMCUにアクセスしてファームウェアをバックアップするように求めてきましたが、私はそのまま実行することにしました。チップはすでにロックされていたと思います。 ClaudeにNZXTのファームウェアアップデーターユーティリティをリバースエンジニアリングさせ、その仕組みを解明させました。また、ファームウェアを単純にパッチして、レジスタ0x6Bのビットに0x01ではなく0x00を書き込むように変更しても安全かどうかを確認させました。特にファームウェアイメージのチェックサムやCRCを変更する可能性を心配していましたが、ClaudeはMCUファームウェアにはチェックサムが全くないだろうと確信していました。 Claudeは、NZXTファームウェアの1バイトをパッチして`movs r2, #16`命令を`movs r2, #0`に変更することで、ITEのドライバーのバグを修正しました。また、NZXTのアップデーターに含まれるDLLを使用してファームウェアを再フラッシュするコマンドラインユーティリティも返してくれました。NZXTの標準ユーティリティは、デバイスがすでに最新の状態だと判断した場合、ファームウェアアップデートファイルのインストールを拒否するため、これを使うことはできませんでした。 デバイスを完全に動作不能にする可能性があったにもかかわらず、アップデーターを実行することにしました。アップデートプロセス全体が実行され、最終的にはこのようになりました。 指示通りにキャプチャカードの電源を入れ直し、OBSを開いて動作が変わったか確認しました。幸いなことに、アップデート後もすべて正常に動作し、さらにバグもなくなっていました！DVIソースデバイスをキャプチャしたときの色の表示は完璧でした。間違いなくそれがバグでした。実際にはITEのドライバーのバグなので、おそらくこのベンダーコードを多くのデバイスにそのまま組み込み、さまざまなHDMIソースやシンクでテストせずに使用している多くのデバイスに影響しているでしょう。私の場合は、使用しているソースデバイスはInfoFramesを全く提供しないため、InfoFramesのない信号に遭遇したHDMIシンクデバイスは、データがRGBであると想定すべきです。他の人の状況については…