HOST_SET_MIPI_CONFIG needed for HM1092 IR sensor on Panther Lake (CVS blocks data lane)

[jibsta210]

Summary

On Dell XPS Panther Lake, the Synaptics CVS SoC (INTC10E1) blocks MIPI CSI-2 data from the HM1092 IR sensor because HOST_SET_MIPI_CONFIG (command 0x0830) is never sent by the intel_cvs driver.

Details

• CVS device capability 0xD200 has HOST_MIPI_CONFIG_REQUIRED (bit 15) = true
• The intel_cvs driver defines the HOST_SET_MIPI_CONFIG = 0x0830 command but never sends it
• The Windows Vision.sys driver sends this command with 176 bytes of data during camera initialization
• Without it, the CSI-2 data lane stays in stop state — clock lane works, data doesn't

Evidence

csi 2 PHY_RX = 0x00010000        ← receiver active
csi 2 PHY_STOPSTATE = 0x00010001 ← clock active, DATA IN STOP
csi 2 PHY_CAL = 0x00000000       ← HS calibration never completes

The sensor (HM1092, I2C 0x24) is properly initialized — chip ID reads, PLL configured, mode_select=streaming. But no data reaches the IPU7 because the CVS is blocking.

Request

1. What is the data format for HOST_SET_MIPI_CONFIG on CVS protocol v2.2?
2. Should the intel_cvs driver send this command automatically when HOST_MIPI_CONFIG_REQUIRED is set?
3. Is this the same format as the Intel IVSC csi_link_cfg (16 bytes: nr_lanes, link_freq, rsvd[2]) or a different Synaptics-specific format (176 bytes)?

Related

• HM1092 IR sensor driver — probes but no MIPI data (need I2C trace from Windows) ipu7-drivers#64 — full HM1092 IR sensor driver development
• INT3472 GPIO type 0x02 (IR LED) support — upstream patch pending

System

• Dell XPS 16, Panther Lake
• CVS: Synaptics SVP7500 (06cb:0701), protocol 2.2, capability 0xD200
• Sensor: Himax HM1092 (HIMX1092:00), chip ID 0x1091
• Kernel: 7.0.0-rc7

[jibsta210]

Update 2026-04-24 — substantial progress and dead-end summary

After extensive work on this since the original report, here's the full state. Hopefully useful for anyone else stuck on this hardware.

What now works in our local intel_cvs (all upstream-able)

• HOST_SET_MIPI_CONFIG (0x0830) is sent at probe time when HOST_MIPI_CONFIG_REQUIRED (cap bit 15) is set. 256-byte I2C transfer (2-byte cmd BE + 176-byte payload + 78 zero-pad), checksum is 32-bit sum of payload words. Then poll GET_DEVICE_STATE for bit 0x40 to clear (up to 30 retries × 100ms). Reverse-engineered byte-for-byte from Vision.sys (Dell driver 81.26100.0.13).
• HOST_SET_MIPI_CONFIG_AUX (0x0833) new opcode — sibling of 0x0830 in Vision.sys's userland IOCTL dispatcher. 44-byte SET command. CVS firmware accepts ANY 44-byte payload regardless of content. Tested with zeros, SSDB[0:44], SSDB[0x50:0x6B]+pad, and mipi_cfg[0x30:0x5B] — all accepted, none unblock streaming.
• CVS firmware download via cvs_ctrl_data_pre sysfs works correctly when given an fd of the OEM firmware blob (06CB0701.bin in the Vision_Ext package, 1.93 MB, magic VISSOCFW). State transitions 0x06 → 0x16 (download) → 0x56 (download complete + something).
• reset command added to the existing cmd sysfs — wraps cvs_reset_cv_device() to allow user-triggered rst GPIO pulse. Confirms state goes 0x56 → 0x06 after reset.

What's still broken (the actual bug)

The CVS bridge does not forward sensor MIPI traffic to IPU7 port 2. This persists even after:

• ✅ MIPI config sent + accepted (state=0x06)
• ✅ Sensor reports mode_select=0x01 during stream attempts (verified via direct I2C read)
• ✅ IPU7 firmware accepts STREAM_OPEN (STREAM_OPEN_DONE, STREAM_START_AND_CAPTURE_ACK received)
• ✅ stream on CSI2-2 with 1 lanes in dmesg
• ✅ IPU7 PHY for port 2 comes up identically to working RGB port 0 (PHY_RX, ready, etc.)
• ✅ CVS firmware uploaded successfully (post-FW state byte changes)
• ✅ CVS reset GPIO pulse works (state cycles correctly)
• ❌ Zero sof_event::csi2-2 ever fires — the IPU7 CSI-2 receiver never sees a single frame-start packet (verified via custom MMIO peek module reading IS_IO_CSI2_SYNC_LEGACY_IRQ_CTL directly, and via dmesg with ipu7_isys_csi2_isr dyndbg enabled).

Hardware-level: lanes are silent.

Dead-end findings (so others don't burn cycles)

1. PHY_CAL=0 + PHY_STOPSTATE=0 are NORMAL during successful streaming. Don't use these as failure indicators. Verified by reading the same registers during a working RGB stream — same values. The real "stream is alive" signal is the firmware-dispatched IPU_INSYS_RESP_TYPE_FRAME_SOF event.

2. 0x833 is NOT the unlock command. Vision.sys exhaustively has only 7 SET opcodes total (0x805, 0x820/821/822, 0x830, 0x831, 0x833) and Vision.sys does NOT issue any post-MIPI-config command before stream start. The bridge enabling is implicit-on-0x830-success.

3. Capability 0xD200 is what we read (matching what others see). Bits 10-15 are documented in the upstream header. Bit 9 (0x200) is set on PTL CVS firmware 1.20.129 and is NOT documented or tested anywhere in Vision.sys or iacamera64.sys — possibly a feature flag handled in user-mode trustlet (iaisptrustlet64.dll).

4. The CVS rst GPIO takes down the entire I2C bus when pulsed — both CVS (0x76) and any sensor on its I2C path (0x24) become unreachable. USBIO disconnects. Recovery requires USB re-enumeration. Don't pulse rst inline during a streaming test — it requires orchestrating USB reset + CVS reprobe + MIPI config re-send.

5. The complete 226-register sensor init from Windows hm1092.sys was extracted byte-for-byte (159 global init + 24 mode 3 + 38 pre-stream + 5 in 8-byte format from VMA 0x14002c760). Sensor side configures correctly per Windows. Original 35-register init had byte-swapped VTS/HTS values and wrong 0x4800 — those are now correct. Output dim is 648x368 (binned), not 1280x720 — but firmware rejects 648x368 stream open while accepting 1280x720, so we advertise the larger size.

6. Software reset (sensor reg 0x0103=1) at start of init triggers IPU7 firmware "critical boot state error 0xdead0001" and wedges the entire camera stack. Not a workaround.

Hardware/protocol unknowns we cannot resolve from software

• What capability bit 9 (0x200) controls
• Whether iaisptrustlet64.dll secure-enclave operations participate in CVS bridge enabling
• The actual 44-byte payload Windows sends for opcode 0x833 (it's userland-fed; not in any kernel binary)
• Whether MEI / SecureWorld events need to be exchanged with CVS

What would unblock this

A USBPcap trace from Windows running on this exact hardware (Dell XPS 16 PB16250 / Latitude 7440/9440 with HM1092) capturing the I2C/USB-bridge traffic from camera-app launch through first frame. 5-minute capture with USBPcap installed would settle every remaining unknown.

Anyone with Windows on PTL + HM1092 hardware, please consider running this trace. Drop it in this thread or DM and we'll get IR cameras working for everyone on Linux.

Hardware involved

• Dell XPS 16 PB16250 (Panther Lake, IPU7), CVS Synaptics SVP7500 (06cb:0701), CVS firmware 1.20.129, capability 0xD200, HM1092 IR sensor at I2C 0x24
• Other affected: Dell Latitude 9440/7440/7450 (HM1092), Lenovo ThinkPad X9 (HM1092), ASUS Vivobook X1407Q (HM1092 on Snapdragon X — same blocking pattern)

Code

• WIP intel_cvs patches: https://github.com/intel/vision-drivers (see local fork comments)
• WIP hm1092 sensor driver: ~150 lines, builds clean on 7.0.x
• INT3472 GPIO type 0x02 (IR LED) handling: 2-line patch, has analog in upstream patches
• INT3472 SSDB controllogicid fallback for USBIO platforms (where _DEP chain is broken): ~30 lines

Happy to upstream the working pieces if there's interest. The MIPI bridge unblock work would benefit greatly from Intel/Synaptics docs on capability bit 9 and the post-MIPI-config sequence iacamera64.sys runs.

[jibsta210]

Cross-platform debugging dossier with everything in one place: https://gist.github.com/jibsta210/8316b6a0bc58910891512945c4e91a08

Cross-linked also on:

• [Lunar Lake] Protocol Error (-71) and I2C Speed Bottleneck on OV08X40 via Synaptics SVP7500 Bridge ipu7-drivers#51 (Lunar Lake SVP7500)
• HM1092 IR sensor driver — probes but no MIPI data (need I2C trace from Windows) ipu7-drivers#64 (HM1092 sensor)
• Intel IPU6 camera fails to start (ov08x40 + Synaptics SVP7500) on Dell Pro Max 16 Premium MA16250 ublue-os/bazzite#4290 (Synaptics SVP7500 family)
• Cross-platform: HM1092 IR sensor blocked on x86 PTL too — sharing findings pir0c0pter0/fedora-vivobook-x1407q#9 (Snapdragon X port, same sensor)

[tverhaeghe]

Hi @jibsta210,
I have a Dell XPS 16 DA16260 Panther Lake xith HM1092 + SVP7500 06cb:0701 on fedora 44 silverblue. I would be very happy if my camera worked. I still have the original Windows installation on an SSD.

I've run USBPcap; please find attached two captures. I hope this will be helpful. Thank you!

capture_svp7500_long2.zip

[jibsta210]

Hi @jibsta210, I have a Dell XPS 16 DA16260 Panther Lake xith HM1092 + SVP7500 06cb:0701 on fedora 44 silverblue. I would be very happy if my camera worked. I still have the original Windows installation on an SSD.

I've run USBPcap; please find attached two captures. I hope this will be helpful. Thank you!

capture_svp7500_long2.zip

this looks super promising i think this is what we needed to get the full camera stack working.

[jibsta210]

@tverhaeghe — your trace was the single most useful piece of data we've gotten on this hardware in three months. Two specific follow-up captures would be enormously valuable if you're up for it.

The ask (10 seconds each)

🥇 Windows Hello (IR face auth) capture

Your existing trace was the Camera app, which uses RGB on port 0. We need the IR-specific flow because it's a different sensor (HM1092 @ I2C 0x24, not OV08x40 @ 0x36) with different 0x830 payload bytes.

Procedure: start USBPcap → cold reboot → sign in via Windows Hello face → stop. 10-15 seconds.

🥈 Capture spanning camera close

Your existing trace cuts off mid-stream. We never see the teardown — exactly the inverse of the post-config flow we're trying to reconstruct.

Procedure: start USBPcap → open Camera → wait 5s → close Camera → wait 5s → stop.

Bonus: whole-bus capture

If USBPcap can grab all USB rather than just 06CB:0701, useful for finding any side channels (Intel CSE/MEI, vendor-specific endpoints) we currently don't see.

Why we're asking — what your trace already unlocked

1. The 0x833 command we'd been hunting for isn't used during normal camera launch

Exhaustive search across both your captures: zero instances of opcode 08 33 to I2C 0x76. Three months of chasing it: closed.

2. CVS bridge runtime protocol on USB is just two opcodes

HOST_SET_MIPI_CONFIG (0x0830) — 256 bytes, sent once. GET_DEVICE_STATE (0x0800) — polled afterward. No magic post-MIPI handshake visible on the bus.

3. Sensor init happens before MIPI config in your trace

430+ I2C writes to OV08x40 first, then 0x0830. Linux drivers do the opposite order. We're testing a reorder.

4. We extracted the exact 256-byte 0x830 payload structure and noticed the upstream intel_cvs was sending the wrong format

The upstream driver computes a checksum but never includes it in the buffer, and lays out the body at SSDB-style offsets that don't match what your capture shows.

5. Your bytes do real work — and this is the headline finding

We rewrote our DKMS intel_cvs to send your 254 payload bytes verbatim and tested:

• Without patch: bridge state stays 0x06, sensor I2C @ 0x24 accessible directly, IR streaming fails cleanly with stream stop time out.
• With patch: bridge accepts the payload and persistently reconfigures — sensor I2C @ 0x24 stops responding (-110 ETIMEDOUT), state survives USBIO disconnect/reconnect, only clears on a full reboot.

This proves three things at once:

• Your 0x830 payload IS recognized as valid by CVS firmware (not just acked)
• The previous SSDB-style payload upstream was being silently ignored (it was a no-op)
• After valid 0x830, the bridge expects the host to proxy sensor I2C through CVS commands rather than direct I2C — and we don't know what those commands are

So the actual blocker for IR streaming on Linux is the post-0x830 sensor-I2C-via-bridge-proxy command set. We never see it in your trace because once 0x830 succeeds the camera is streaming and frames flow via CSI-2, not USB. A capture spanning Windows Hello (IR) or a camera close would be the missing piece.

Full writeup: https://gist.github.com/jibsta210/8316b6a0bc58910891512945c4e91a08 (updating tonight with the verbatim-payload test results)

Either of the two captures would unblock months of work for everyone hitting this bridge family — Dell XPS 16/Latitude, Lenovo X9, ASUS Vivobook X1407Q, anyone with Synaptics SVP7500. Even a no-result trace is valuable as a comparison baseline.

Happy to share the working patches we have (suspend/resume fixes, INT3472 GPIO type 0x02 + SSDB controllogicid fallback, ipu_bridge HM1092 enumeration, hm1092 sensor driver) for your Fedora 44 setup — they won't unblock IR streaming yet but will get HM1092 enumerating without USBIO crashes and survive suspend cycles cleanly. Thank you again.

[jibsta210]

Quick update on what we learned today — narrowed the IR streaming blocker to a single specific gap, and the IR-Hello USBPcap from your machine would directly resolve it.

Today's test: stream pipeline state on identical hardware

Stage	State	Evidence
HM1092 sensor MIPI TX	Streaming	i2ctransfer w2@0x24 0x01 0x00 r1 returns 0x01 mid-stream — the sensor's mode_select register live-read
CVS bridge config	Accepted	state 0x06, no errors, ownership transferred
ISYS firmware STREAM_OPEN	Succeeded	first time — no stream open time out
Userspace VIDIOC_STREAMON	Returns 0 (Success)	buffers queued, kernel waiting for SOF
CSI-2 line activity	Dead	zero sof_event::csi2-2 events

Every layer above the PHY works. The MIPI signal is generated by the sensor (we proved this with the live register read). The IPU7 ISYS is listening on port 2 firmware-side. Linux is ready for frames.

Diagnosis

The break is between bridge → IPU7 PHY: CVS accepts our config but isn't physically forwarding port-2 MIPI to the IPU7's CSI-2 input lines. Signal goes INTO the bridge from the sensor, doesn't come OUT.

The 0x830 bytes we send describe port 0 (OV08x40 RGB) — bridge enables port-0 forwarding (which works for RGB anyway) but no equivalent enable for port 2 has been sent. The "second port descriptor" at offset 0x38 in your long2 trace seems to be RGB-related too (port 1, with the same 71 MHz speed param as port 0), not IR.

Why the IR-Hello trace would directly resolve this

A capture during Windows Hello face auth would show:

1. 0x0830 to CVS with port-2 specific bytes — the IR-equivalent of what your long2 has for port 0
2. Possibly an additional opcode toggling port-2 forwarding (we haven't seen it in any trace yet)
3. Sensor I2C writes to address 0x24 (HM1092) instead of 0x36 (OV08x40)

Within hours of getting that trace, we'd know exactly what command sequence makes the bridge forward port-2 MIPI. Without it, this is currently unresolvable from public info — Synaptics hasn't published SVP7500 docs and the IR-specific bytes aren't reverse-engineerable from Vision.sys alone (built at runtime from userland/ACPI inputs).

The ask, restated cleanly

If you can do one capture, please do this one:

• Start USBPcap on 06CB:0701
• Cold boot
• Sign in via Windows Hello face authentication (NOT the regular Camera app)
• Stop capture after sign-in completes
• 10-15 seconds of capture is plenty

Even if Hello fails on your Windows install (e.g. you haven't enrolled), just opening the Windows Camera app and selecting the IR/infrared option (if available) would also work — anything that activates HM1092 specifically.

Findings dossier (now updated with today's diagnosis): https://gist.github.com/jibsta210/8316b6a0bc58910891512945c4e91a08

Thank you in advance for any time you can spare on this. We're genuinely one short capture away from unblocking IR for everyone with this bridge family.

[tverhaeghe]

Hi @jibsta210,

I can't get USBPcap to persist across reboots, but I've captured the following scenarios:

1. Camera App

• Start USBPcap
• Start Camera App
• Stop USBPcap

2. Windows Hello configuration

• Start USBPcap
• Start Windows Hello configuration
• Stop USBPcap

3. Windows Hello unlock after session lock

• Start USBPcap
• Session face unlock with Windows Hello
• Stop USBPcap

I ran scenarios 1 and 3 a second time (capture_svp7500_20260512_second_try); I'm not sure if they'll be useful

USBpcap won't let me capture the whole bus.
There are only two options listed in the text file. I chose option 1; I think there's already quite a bit included in that option.

I hope this information is helpful.

Thank you for your efforts.

capture_svp7500_20260512_second_try.zip

capture_svp7500_20260512.zip

[jibsta210]

@tverhaeghe — your traces unlocked everything. Two huge findings since my last reply:

1. We found the bridge-stability root cause

While analyzing the post-mipi-ir behavior on our setup, dmesg surfaced a kernel WARNING at probe time:

WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x8ec/0x9f0
  new->flags & IRQF_ONESHOT && !new->thread_fn
Call Trace:
  request_threaded_irq+0x13a/0x190
  devm_request_threaded_irq+0x80/0x100
  cvs_init+0x47/0x80 [intel_cvs]
  cvs_common_probe+0x321/0x5a0 [intel_cvs]

The upstream intel_cvs driver calls devm_request_irq() (the hardirq-only variant) but passes IRQF_ONESHOT in flags. IRQF_ONESHOT is only meaningful for threaded handlers — on a hardirq-only handler the kernel warns and the IRQ behavior is undefined.

Removing that flag fixes the bridge stability problem. Without the fix, the SVP7500 wedges after brief idle periods (we observed wedges as fast as 3 minutes into uptime, sometimes immediately on first I2C access). With the fix:

• ✅ Bridge survives idle (tested 10+ minutes)
• ✅ Bridge survives RGB libcamera streaming (28.57 fps sustained)
• ✅ Bridge accepts our IR 0x830 payload without wedging
• ✅ Kernel WARNING gone entirely

This is a real upstream-worthy fix. Pure Linux kernel API misuse — nothing Synaptics-specific. The patch is a one-line diff to drivers/misc/icvs/intel_cvs.c::cvs_init():

- ret = devm_request_irq(icvs->dev, icvs->irq, cvs_irq_handler,
-                        IRQF_ONESHOT | IRQF_NO_SUSPEND,
-                        dev_name(icvs->dev), icvs);
+ ret = devm_request_irq(icvs->dev, icvs->irq, cvs_irq_handler,
+                        IRQF_NO_SUSPEND,
+                        dev_name(icvs->dev), icvs);

2. We extracted the RGB pre-config sequence

Right before the IR 0x830 in your windows_hello_unlock trace (frames 1700-1846), Windows runs an extensive RGB sensor sequence: 15 burst writes of 32 bytes of 0x75 to RGB sensor SRAM at 0x5d60–0x5fxx, then PLL config reads, then MIPI control writes (0x4802=0x20, 0x4820=0x0073, 0x3820=0x04, 0x3821=0x00).

So Windows touches the RGB sensor during IR setup. Our hypothesis: bridge has shared MIPI hardware between port 0 and port 2, and the RGB sensor must be put into a specific state before bridge will switch port forwarding to IR.

We tried to replicate this via i2ctransfer w@0x36 — which wedged the bridge. We discovered the bridge denies direct host I2C to sensor addresses 0x24 / 0x36 in our Linux configuration. It works in Windows via some mechanism we don't yet see (possibly CSE/MEI-mediated, or a privileged USB control transfer we missed). On Linux, attempting it = bridge wedge.

So the IR streaming side is still under investigation, but at least we know exactly what the gap is.

3. Drop-in installer for you (and anyone else with this hardware)

I built a fix pack that should restore your RGB camera on Fedora 44 Silverblue — same one as us on PTL hardware. Repo:

https://github.com/jibsta210/svp7500-camera-fix-pack

Install:

curl -L -o fix-pack.tar.gz https://github.com/jibsta210/svp7500-camera-fix-pack/releases/download/v0.1/svp7500-camera-fix-pack.tar.gz
tar xzf fix-pack.tar.gz
cd svp7500-camera-fix-pack
sudo ./install.sh
sudo reboot

What it does:

• intel-cvs DKMS with the IRQ fix + verbatim Windows-format 0x830 payloads (both RGB and IR)
• int3472-patched DKMS — GPIO type 0x02 (IR LED) + SSDB controllogicid fallback (without these, sensors don't enumerate on USBIO platforms)
• ipu-bridge-patched DKMS — HIMX1092 in supported_sensors array
• hm1092 DKMS — IR sensor driver (lazy LED, 198-register Windows-faithful init)
• udev rule to disable USB autosuspend on 06CB:0701 (defense in depth)

Requires DKMS + kernel headers (Silverblue: rpm-ostree install dkms kernel-devel then reboot before install).

On Silverblue specifically the DKMS layering is a bit awkward but doable. If you hit issues, raise an issue on the repo and I'll iterate.

The IR camera (Windows Hello) still won't stream after install — that's the remaining mystery. But the RGB camera should work for the first time on your Linux installation, which would be a real life-improvement.

---

Thanks again for the traces. They were the difference between "guessing" and "knowing where the wall is." Updated findings gist: https://gist.github.com/jibsta210/8316b6a0bc58910891512945c4e91a08

[jibsta210]

One important clarification I should have included up front: all testing was done on CachyOS with a custom-built linux-cachyos-susfix 7.0.5 kernel.

The DKMS modules themselves are vanilla C against the standard kernel API — they should work on Fedora / Arch / Debian / Ubuntu — but we have not personally tested those. Fedora 44 Silverblue specifically is going to be awkward because DKMS layering on an immutable OS requires rpm-ostree install dkms kernel-devel + reboot before running the installer.

I updated the README to spell this out. If you (or anyone else) tries the installer on another distro, please open an issue at the fix-pack repo with results — positive or negative. That's how we'll know what actually carries across.

Hardware compatibility is broader than distro compatibility here — the fix-pack only cares about Intel IPU7 + Synaptics SVP7500 + OV08x40/HM1092 silicon. Anyone with that combination on any modern-kernel Linux should benefit.

[jibsta210]

Quick request: would you mind testing the fix pack on your Fedora 44 Silverblue setup and reporting back?

If RGB starts working for you, that confirms the patches generalize beyond CachyOS — and we'd then make a bigger noise about it (Phoronix, r/linux, etc.) to reach the wider set of affected laptop owners. Right now I'm hesitant to push it broadly with only a one-distro test sample.

I bumped the release to v0.2 (link) — key change from v0.1: the install script now automatically backs up your vmlinuz and initramfs before touching anything DKMS-related. Also takes a snapper Btrfs snapshot if available. Cheap insurance against the worst case.

Procedure:

# 1. Make sure DKMS + kernel headers are installed (Silverblue: requires rpm-ostree)
rpm-ostree install dkms kernel-devel  # then reboot before continuing

# 2. Download + extract
curl -L -o fix-pack.tar.gz https://github.com/jibsta210/svp7500-camera-fix-pack/releases/download/v0.2/svp7500-camera-fix-pack.tar.gz
tar xzf fix-pack.tar.gz
cd svp7500-camera-fix-pack

# 3. Read the README (especially "Recovery if something breaks")
less README.md

# 4. Run installer (auto-backups vmlinuz+initramfs first)
sudo ./install.sh
sudo reboot

# 5. After reboot, test RGB
cam --list
cam --camera=1 --capture=5 --file=/tmp/test.raw

What I'd love to know after you test:

• Did all 4 DKMS modules build successfully on your kernel?
• Did the camera show up in cam --list after reboot?
• Did cam --capture produce frames?
• Any new dmesg errors during boot or first camera use?

If anything goes sideways, the auto-backup gives you a clean recovery path (boot to fallback kernel entry → dkms remove everything → reboot to known-good state).

No rush at all — only when convenient for you. The IR investigation is also ongoing in parallel; if you have time and energy for one more USBPcap run later, even better data we could use would be:

1. What command actually unlocks direct host I2C to sensor addresses 0x24 / 0x36 in Windows — our Linux test wedges the bridge when we try i2ctransfer w@0x36, but your trace shows Windows doing it successfully. There must be a privileged setup we haven't seen.

2. A capture spanning a clean enumeration — laptop powered off, USBPcap started, laptop powered on, capture USB enum + first camera use. That would tell us if the bridge enters a different state at first plug-in.

But these are nice-to-haves and only if it's not a hassle. The fix-pack test report would already be the main next step.

Thank you again — your traces did the heavy lifting on the bridge stability fix. That was the single biggest blocker for everyone affected and it's now solved.