みなさん、こんにちは。
Logicool C270nをHaiku OSで動かそうとしてISO転送（等時転送）とXHCIドライバの深淵に呑まれ、「Haiku OSチームがUSBスタックを抜本改善してくれるのを気長に待つことにしましょう」と白旗を揚げて撤退してからはや2ヶ月半。やはりエンジニアとしての不完全燃焼感は燻り続けていました。
そんな中、「BubiCam」というWebカメラ診断アプリの存在を知り、「もしかして今なら……？」と淡い期待を胸に、再びあの暗く深い沼へと足を踏み入れることにしました。「BubiCam」のインストールは以下で記事にしました。
今回は、C270nを動作させる再挑戦の記録をお届けします。
「try lower resolution」、また会ったな
期待を込めてBubiCamをインストールし、C270を認識させて起動。しかし、画面に躍り出たのは見覚えのありすぎる「No Video Signal」のダイアログでした。
デジャヴを感じつつ syslog を掘り返してみると、そこには前回と全く同じ懐かしい（そして憎たらしい）顔ぶれが並んでいました。
KERN: usb error ohci 0: td error: 0x00000004
USER: UVCCamDevice: bandwidth 3060>1024, high-bw disabled (TBC=0 bug)
それもそのはずです。BubiCamが内部で利用しているUVCドライバの実体は、BubiCam独自のコードではなく、~/git/haiku-uvc-webcam という外部のメディアアドオンでした。（何を隠そう、このリポジトリの作者もBubiCamの作者である atomozero 氏その人なのですが…）
土台となるアドオンが変わっていない以上、前回の記事で散々苦しめられた「XHCIのhigh-bandwidth isochronous転送エラー」および「TBC=0問題」という壁にそのまま再衝突したわけです。
安全側に倒された結果、1024バイトのlow-bandwidthエンドポイントにフォールバックしていましたが、C270が要求する本来の帯域は3060バイト。isochronous転送の実測ログを見ると pkt[0]act=12/req=1024 となっており、要求した1024バイトのうち、実際にはたったの12バイトしか届いていないという惨状でした。
立ちふさがる「ふたつの落とし穴」
ここから原因究明を進める中で、不覚にも2つの罠にはまってしまいました。
罠1 – 環境変数が届かない「常駐デーモンの壁」
ドライバのコードを読み込むと、裏技的に WEBCAM_FORCE_HIGH_BANDWIDTH=1 という抜け道が用意されているのを発見しました。
「勝った！」と思い、すぐさま Terminal で export WEBCAM_FORCE_HIGH_BANDWIDTH=1 を実行してテストしたものの、一向に挙動が変わりません。
原因は単純でした。このアドオンの実体はユーザーのシェル上ではなく、バックグラウンドで動く media_addon_server という常駐デーモンの中で起動していたのです。後から別シェルでいくら export しても、環境変数は届きません。
結局、~/config/settings/global.environment に直接記述し、メディアサービス全体を再起動することで、ようやく反映させることができました。
罠2 – 比較実験の「早とちり」
もうひとつ、自分の検証環境による盛大な勘違いがありました。
検証中、「同じVirtualBox上のXubuntuではC270の映像が綺麗に映る」ことを確認していたため、「やっぱりHaiku側の実装が100%悪いんだ」と思い込んでいました。
しかし、よくよく設定を確かめてみると、Xubuntuで映っていたのはVirtualBoxの「Webcam機能（仮想リレー）」を経由した映像であり、Haiku側でテストしていた「生のUSBパススルー」とは別物だったのです。
条件を揃えてXubuntuでも生パススルーを試したところ……なんとXubuntuでも動作しませんでした。つまり、「Haiku固有のバグ」という見立ては半分正解で、半分は私の早とちりだったというわけです。
光明 – 指をくわえて待っている間に、upstreamは進んでいた
前回は haiku-uvc-webcam の根深いエラーに押し返されて撤退しましたが、今回試しに git fetch を実行してみて驚きました。なんと手元のローカルリポジトリから、 upstream（本家）に 30以上ものコミット が積み上がっていたのです。
コミットログのタイトルを眺めるだけで、開発者たちの血と汗が伝わってきます。
Harden against a wedged data pump instead of hanging or killing itSanitize negotiated Probe/Commit sizesFix data-pump recovery so it escalates and gives up on a wedged controller
まさに私たちがぶつかっていた「データポンプが固まる」「コントローラがハングする」といった問題に対する泥臭い改善が、着々と進められていたのです。
期待を込めて git pull し、ビルドして再インストール。メディアサービスを再起動して再度検証を行ったところ、明確なパフォーマンスの向上が確認できました。
| 項目 | 更新前 | 更新後 |
| 音声接続 | 毎回8秒のタイムアウトが発生 | 即座に接続完了 |
| ISO転送実測 | act=12/req=1024（スカスカ） | pkt[0]=980/1024（ほぼフルパケット） |
転送効率が劇的に改善され、データがしっかりと流れてくるようになりました！
現状 – 片足だけ沼から抜けた
とはいえ、完全勝利とはいきません。
USB 3.0（XHCI）での接続は相変わらず厳しく、VirtualBox側の設定でUSB 2.0（EHCI）に落としてやる必要があります。これで一応映像の枠組み自体は出るようになったものの、必要帯域3060バイトに対してlow-bandwidthの上限は1024バイトのまま。帯域不足により、映し出される映像はまだ大きく乱れており、実用には程遠い状態です。
ですが、完全に沈んでいた前回に比べれば、「片足は沼から抜けた」と言っても良いのではないでしょうか。
今後の展望とまとめ
次に試すとすれば、まずは160×120などの低解像度フォーマットに絞り、1024バイトの帯域内に収まる設定でノイズのないクリーンな映像が出せるかどうかの検証になりそうです。もしこれで綺麗な映像が出るのであれば、「high-bandwidthなしでも動作する実用プリセット」を作るという、現実的な落とし所が見えてきます。
もちろん、根本的な解決にはHaiku OS本体のXHCIドライバにおけるhigh-bandwidth isochronous転送の修正が不可欠です。しかし今回分かったのは、OS本体の修正をただ指をくわえて待つだけでなく、haiku-uvc-webcam のような周辺コミュニティが、EHCI経路の最適化やデータポンプの堅牢化といった形で地道に前進を続けているということでした。
「ただ指をくわえて撤退した前回」から、「コミュニティの進化を実感しつつ半歩だけ前に進めた今回」。沼の深さは相変わらずですが、確実に景色は変わりつつあります。
Haiku OS、歩みは遅くても、着実に進化はしています！
「Haiku OS は無理でも、自分も何かアプリを作ってみたい」と思われた方、そのアイデア、頭の中で寝かせておくのはもったいないかもしれません。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、現場で「使い続けられる」ものづくりを支援しています。
アイデアを短期間で「動くもの」にし、PoCで終わらせず、実運用まで伴走します。まずは「これ、作る価値ありますか？」という壁打ちからでも大歓迎です。
▶ PoC・MVP開発サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
本日も最後までお読みいただきありがとうございました。
それでは、よい（そして少しずつ前進する）Haiku OSライフを！
