Cosmos Elite support ?

[MonsieurLanza]

Hello, do you have an idea what amount of effort it would take to get Cosmos Elite (the one with lighthouse tracking) working, using this repo as a basis ?

Should I dig in, or ditch the idea straight away ?

I use Arch, btw. ;)
Thanks.

[MonsieurLanza]

So far, after some battle with kernel versions and config here and on https://github.com/santeri3700/vive-pro-2-on-linux, I was able to get a patched kernel (with the last patches which includes the cosmos ID \o/), and the vivepro2 driver.

Patches need another update, they won’t work on the latest linux-drm-misc-next, I had to get the 2023-01-12 tag. And the provided config failed to boot on my machine.

Steam now displays the VR icon in the toolbar, and on my nvidia box with the AllowHMD option set in xorg conf, I can see the render… on my primary display. So I now know the tracking works, and the render seems somewhat correct, I’m not sure about the dimensions. And the system freezes while exiting SteamVR.

But with or without the AllowHMD flag, nothing renders on HMD itself. My guess because the vivepro2 driver does not set the mode properly (only vivepro2 modes seems available), but I now have to find a way to get logs.

[CertainLach]

For cosmos support, you should at least

1. Set your modes here: https://github.com/CertainLach/VivePro2-Linux-Driver/blob/master/crates/vive-hid/src/lib.rs#L169 (Only one mode is available on cosmos)
2. Disable every writing method in vive-hid crate (Because cosmos has other protocols)

There was a release of steamvr part with cosmos-specific fixes here: https://github.com/CertainLach/VivePro2-Linux-Driver/releases/tag/v0.3.1-cosmos
However my tester reported it doesn't work, and most likely some other kernel changes are required.

[CertainLach]

Set of changes, that was applied on v0.3.1-cosmos tag:
https://gist.github.com/CertainLach/888c4958678bee5f1736bc2ac3a5095d

It also disables lens distortion functionality, as I'm not sure of its protocol on cosmos either.

[MonsieurLanza]

Thank you.

[MonsieurLanza]

Ok, I had correct modes, and product ID. I did not remove any of the writing, though.

[CertainLach]

You should remove writings, as cosmos has slightly different protocol, which also lacks some of the vive pro 2 features (I.e mode switching)

[MonsieurLanza]

Well, stuck on "Permission denied". Maybe stupid, but still…

�[31mERROR�[0m �[2mdriver_proxy::server::driver_host�[0m�[2m:�[0m failed to wrap hmd: hid error: hid error: hidapi error: Permission denied

cosmos-log.txt

I have to stop for tonight.

[CertainLach]

chmod a+rw /dev/hidraw* for a quick test

There is no udev rules for vive cosmos installed

[MonsieurLanza]

Thanks again.

So it does not work out of the box. No image, and cosmos is led still red.

At least it does not seem to crash the whole system on exit. Note : stations are not going to standby mode, despite driver saying so.

cosmos-log.txt

[CertainLach]

To make stations sleep, you should enable power management for them, driver tells its going to put only managed ones to sleep.

[MonsieurLanza]

Ok.

Now, for what I understand, there is probably an « usb switch » to turn on display.

OpenHMD does this by sending a magic sequence https://github.com/OpenHMD/OpenHMD/blob/master/src/drv_htc_vive/vive.c#L594 , and as the sequence is different for Vive an Vive Pro, I guess it is different for Cosmos. And I guess on Vive Pro 2 setting the display mode does turn the display on.

If I understand correctly, I just have to find that value in the middle if the flow of USB traffic I just wiresharked, write it and see if something happens.

[CertainLach]

For Vive Pro 2 nothing is required, the display just starts working as soon as it receives the DisplayPort signal.
There are commands for led control, but they are not mandatory to start displaying an image.

I didn't tough about Vive Cosmos requiring it, but this may be the case

[CertainLach]

I have looked in EyesReader.dll, and seems like there is some function for managing HMD panel.
Is I can see, report should have 0x782938 as its 1-3 bytes (counting from zero) as part of HMD_SetFeatures call, then should contain 0x80 and power state (1 byte) somewhere in data (Too lazy to count bytes, this report is created in SetPowerState function), and rest is filled with zeros.

[CertainLach]

I think you should be able to easly recover all of the protocol messages by using api monitor (http://www.rohitab.com/apimonitor), and capturing HidD_SetFeature calls from the EyesReader.dll library, every function there has self-explaining name

Config for the lens-server library is returned by GetInHouseDistortionJson, and then there is some other possible useful setters.

[MonsieurLanza]

Thank you for all that, I’ll have a deeper look when I can get some free time again.