Summary
On IPU6 Surface devices (e.g. Surface Pro 7+, Pro 8, Pro 9), the intel-ipu6-isys kernel driver registers 64 raw video nodes (/dev/video0 through /dev/video63).
When creating a virtual loopback camera using v4l2loopback (for video conferencing apps like Zoom, MS Teams or browser WebRTC modules) mapped to an index such as /dev/video70, the device is completely invisible to WebRTC-based applications.
Root Cause
In WebRTC's Linux video capture implementation (modules/video_capture/linux/device_info_v4l2.cc):
/* detect /dev/video [0-63]VideoCaptureModule entries */
for (int n = 0; n < 64; n++) {
snprintf(device, sizeof(device), "/dev/video%d", n);
// ...
}The hardcoded upper bound of 64 appears across NumberOfDevices(), GetDeviceName(), and CreateCapabilityMap(). WebRTC does not use udev or sysfs enumeration; it sequentially probes only /dev/video0../dev/video63.
On IPU6 machines:
- Every slot in the 0..63 range is filled with raw ISYS capture nodes (reporting card='ipu6'), none of which stream user frames directly.
- Any loopback device configured above index 63 (e.g. /dev/video70) is never probed.
- The app dropdown is filled with 64 unusable ipu6 entries while the actual loopback camera is omitted.
(Note: Browsers using PipeWire's camera portal bypass this loop and work normally; this specifically affects native apps bundling WebRTC's video_capture module, such as Zoom).
Workaround
For users needing loopback camera functionality in Zoom or other WebRTC-based binaries on IPU6 devices:
An LD_PRELOAD shim can be used to intercept filesystem open/stat calls, remapping /dev/video0 to the real loopback node (/dev/video70) and returning ENOENT for /dev/video1../dev/video63. This presents exactly one clean camera (SurfaceCam) to the application.
Documented here to save time for other IPU6 Surface users experiencing missing loopback devices in conferencing apps.
Summary
On IPU6 Surface devices (e.g. Surface Pro 7+, Pro 8, Pro 9), the intel-ipu6-isys kernel driver registers 64 raw video nodes (/dev/video0 through /dev/video63).
When creating a virtual loopback camera using v4l2loopback (for video conferencing apps like Zoom, MS Teams or browser WebRTC modules) mapped to an index such as /dev/video70, the device is completely invisible to WebRTC-based applications.
Root Cause
In WebRTC's Linux video capture implementation (modules/video_capture/linux/device_info_v4l2.cc):
The hardcoded upper bound of 64 appears across NumberOfDevices(), GetDeviceName(), and CreateCapabilityMap(). WebRTC does not use udev or sysfs enumeration; it sequentially probes only /dev/video0../dev/video63.
On IPU6 machines:
(Note: Browsers using PipeWire's camera portal bypass this loop and work normally; this specifically affects native apps bundling WebRTC's video_capture module, such as Zoom).
Workaround
For users needing loopback camera functionality in Zoom or other WebRTC-based binaries on IPU6 devices:
An LD_PRELOAD shim can be used to intercept filesystem open/stat calls, remapping /dev/video0 to the real loopback node (/dev/video70) and returning ENOENT for /dev/video1../dev/video63. This presents exactly one clean camera (SurfaceCam) to the application.
Documented here to save time for other IPU6 Surface users experiencing missing loopback devices in conferencing apps.