Support Oculus CV1 sensor in USB 2.0 / JPEG mode
Closed this issue · 7 comments
Hello,
when testing the latest additions on the rift-kalman-filter branch last night and spending quite a bit of time scratching my head, I discovered upon running the simple example that the sensor I was trying to use wasn't being detected. The sensor I used is mounted in the corner of my room and connected via a USB2.0 active extension cable - https://www.amazon.co.uk/dp/B00B2HP3A2/ref=pe_3187911_185740111_TE_item upon changing to a none extended cable, all worked as expected.
I was wondering if this might be due to the extension being USB 2.0 rather than 3.0. I should also stress that this is completely none urgent, just something to be aware of if feature parity is the end goal as this setup works fine on the proprietary software.
Yes, probably. If you could paste some syslog output when connecting the camera via the extension, I suspect we'll find it enumerates as a USB 2.0 device. When connected to USB 2.0, the camera doesn't support raw video frame transport - only JPEG encoded frames. Conversely, when connected to USB 3.0, the camera only offers raw video format and doesn't support JPEG.
It's a bit silly.
The upshot is that I have not at all looked at incorporating a JPEG decoder to support the USB 2.0 mode and have been testing exclusively with USB 3.0 and raw video frames.
Looking at my lsusb that seems to indeed be the case. That might explain why my previous CPU struggled so hard when running the rift under Windows. Is it bad that I'm not even surprised the sensors do that?
Here's an output from lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 004: ID 2833:0211 Oculus VR, Inc. Rift CV1 Sensor
Bus 005 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 005 Device 002: ID b58e:9e84 Blue Microphones Yeti Stereo Microphone
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 2833:3031 Oculus VR, Inc. Rift CV1
Bus 004 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 28de:1142 Valve Software Wireless Steam Controller
Bus 003 Device 074: ID 2833:0330 Oculus VR, Inc. Rift CV1 Audio
Bus 003 Device 073: ID 2833:0031 Oculus VR, Inc. Rift CV1
Bus 003 Device 072: ID 2833:2031 Oculus VR, Inc. Rift CV1
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 2833:0211 Oculus VR, Inc. Rift CV1 Sensor
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 008: ID 8087:0029 Intel Corp. AX200 Bluetooth
Bus 001 Device 007: ID 1462:7c91 Micro Star International MYSTIC LIGHT
Bus 001 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 004: ID 1b1c:1b13 Corsair Vengeance K70RGB keyboard
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I'll grab dmesg/systemd logs later when I'm back at the PC if you need it.
Thanks!
I think the best way to check the sensor is using v4l2-ctl --list-formats-ext -d /dev/video2 and specifying the right v4l2 device node. It will print out the formats the camera is announcing. If it includes JPEG, it's in USB 2.0 mode
I see from your blog that we're one step closer to this. Which reminds me I still need to check which format the camera is using!
Merry Christmas! I got you JPEG decoding as a present. 🎄
Don't forget if you're testing this, you need libjpeg development packages installed to get the JPEG support.
meson build should output a line like:
Run-time dependency libjpeg found: YES 2.0.90
I've been testing with 1 sensor in JPEG mode for weeks. Decoding adds a few ms to frame processing, but I can't tell the difference. The processing latency is compensated by prediction / lagged state updates.