HTC Vive hardware is surprisingly open

[roothorick]

I'm dualbooting, so I can use the headset properly, but after booting back to Ubuntu, I discovered some interesting things. As is already known, the headset presents itself as a USB composite device with an intimidating list of subdevices. What I didn't know is that most of these devices report standard USB device classes, and for what can be readily tested, those claims are legitimate.

Most of its parts are already fully operational, without any special drivers:

1. X recognizes it as a display that is 2160x1200@100Hz native. When enabled, the screen does turn on and show a correct-looking image (at least, correct for an HMD being treated as a 2D display)
2. The internal audio device was recognized by the snd-usb-audio driver and is fully functional save for HRTF (which, judging by its behavior in Windows, is probably actually implemented in software)
3. The camera was recognized by the uvcvideo driver and, also, is fully functional.

Now, what isn't immediately recognized, is pretty interesting.

A device calling itself "Hub Controller" was recognized by the cdc_acm module. I'm not sure what a modem is doing inside a VR headset... maybe for firmware updates? Didn't poke at this.

usbhid claimed a pretty large chunk of the devices exposed:
* 28de:2000 "Lighthouse FPGA RX"
* 0bb4:2c87 "HTC Vive" (there are two of these)
* 28de:2101 "Watchman Dongle" (two of these as well)

That first one is very interesting. It produces a hidraw device that hidraw-dump shows as a continuous stream of data that changes in coherent ways as the headset is moved. This could very well be how the headset reports its tracking data -- and it doesn't appear to need any special incantation to spill the beans!

One of the second produces an interesting hidraw device as well. The data produced is usually mostly FF, but changes here and there... but only if the headset is within clear view of at least one base station.

The "Watchman Dongle" devices create hidraw devices that only produce input if a particular wand controller is turned on. I'm guessing right hand & left hand. These were too noisy to eyeball, but based on what the HMD is putting out, there's probably useful data here as well.

The only thing that didn't load a driver at all was the one vendor-specific class: 0bb4:0306 "BCM920703 Bluetooth 4.1" which is known to be for optional communication with the base stations. Even then, it appears to be an off-the-shelf Bluetooth IC that has been found elsewhere, and may already have a valid driver that just needs a quick compatibility list update (see: https://bugzilla.redhat.com/show_bug.cgi?id=1349379 )

In summary, it looks like no special drivers are needed and the data is already there, ready for some userspace runtime to parse and process directly without any assistance from official Valve blobs. And by design, no less.

[roothorick]

Found another interesting thing. The Valve official steam-launcher package includes, of course, udev rules for the Steam Controller, but also a rules file named "60-HTC-Vive-perms.rules". Here's its contents:

# HTC Vive HID Sensor naming and permissioning
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="2c87", TAG+="uaccess"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2101", TAG+="uaccess"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2000", TAG+="uaccess"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="1043", TAG+="uaccess"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2050", TAG+="uaccess"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2011", TAG+="uaccess"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2012", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="2c87", TAG+="uaccess"
# HTC Camera USB Node
SUBSYSTEM=="usb", ATTRS{idVendor}=="114d", ATTRS{idProduct}=="8328", TAG+="uaccess"
# HTC Mass Storage Node
SUBSYSTEM=="usb", ATTRS{idVendor}=="114d", ATTRS{idProduct}=="8200", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="114d", ATTRS{idProduct}=="8a12", TAG+="uaccess"

Some of those productIDs aren't present on my unit -- Vive Pre, perhaps? In any case, this confirms that there will be no kernel or libusb component to Vive support and SteamVR will access the headset through the hidraw interface exposed by the unmodified usbhid driver.