PCI-E USB 3.0 controller loses UVC webcam upon changing image format

Just got myself a Razer Kiyo and it works flawlessly on Windows 7 Bare Metal, (ALL USB 2.0 and USB 3.0 ports) Windows 8.1 through a passed through USB 3.0 controller, macOS over USB 2.0 and native Intel USB 3.0 on a Macbook Air (although the control protocol is buried and requires shareware to reveal it), and Linux over USB 2.0…

However, XHCI USB 3.0 controllers which aren’t part of the chipset, like Fresco Logic and VIA controllers, (which I passed the Fresco Logic through to a Windows 8.1 VM, and it worked) break the link to the webcam in both macOS and Linux, which is strange considering the Windows 8.1 VM and Windows 7 Bare Metal has no issues with the controller. In macOS using a Fresco Logic controller, Photo Booth locks up upon receiving the bitstream, and in Linux, the only format it can reliably bitstream is the FIRST datastream format it receives. If you try to change the picture format, the camera disappears from /dev/video0

This now begs the question, will I have similar problems with USB 3.0 HDMI devices like the Magewell or the Epiphan AVio? Are these issues specific to those Fresco Logic and VIA USB 3.0 chips? If those issues persist with OSX and Linux, I’ll have to do a Windows 8.1 passthrough and open the device in MPC-HC in combination with Looking Glass for my X79 setup…

I’m beginning to wonder if this is a common issue with XHCI controllers trying to grab USB 2.0 UVC devices in Linux. @wendell, can you test the C920 connected to multiple PCI-E USB 3.0 controller brands to see if a similar issue crops up in Linux? The more coverage, the better. Remember, the issue crops up when a resolution/frame rate change is requested.

I solved the problem halfway by simply using qv4l2 to set everything up before OBS grabs the device and having a native XHCI device (Kingston USB 3.0 card reader) present on the same hub constantly powered. Seems to be a power save issue with EHCI on XHCI, or just in general. A fix I tried for USB autosuspend didn’t work, so it’s at a deeper level rather than a simple issue with kernel USB suspend with user level access to the device’s power rules. The only way to fix it in both Ubuntu and Fedora is to have another device constantly keeping the hub active… IKR? I was wondering why this problem wasn’t common… I guess everyone else moved on to native Intel and AMD USB 3.0. I’m going to assume native XHCI devices and V4L2 on third party controllers works with the XHCI implementation in OBS, and power save functions can cause it to malfunction. I’ve unfortunately heard no accounts of people successfully using the FL1000 series with Ubuntu/Fedora and XHCI UVC devices in Linux, so I’m going to have to be the first to report this.

My alternative in case it doesn’t work is passing through the Fresco Logic to Windows 8.1 and using Looking Glass to transfer the framebuffer from Windows to Linux. It would really save me some anxiety if someone can test this on a FL1009 or FL1000, and if they had to deal with the same power save issues.

BIG REVELATION:

Controllers getting a constant 5V supplementary power supply from the PSU directly are NOT affected by a sleep bug, (at least as far as I’ve tested.)

My conclusion is that if the controller itself has to call for a 5V power line from a onboard buck converter, Linux’s XHCI implementation is flawed in that it cannot send the correct signal to tell a device to sleep or not. HOWEVER, if a constant 5V is fed through the port, that eliminates the need for XHCI power management.

2 XHCI controllers are confirmed to work due to a supplementary power supply: My VIA VL800 with IOMMU off and my Renesas uPD720202 with a SATA power cable connected. It turns out there is a difference between if that “optional” SATA power connection on the back of some cards is connected or not, as it completely affects how the controller handles USB port sleep modes, at least on Linux.