Friday 17 March 2017

Why can't Firmware and API developers get along (They are lying!!)

So, another nice HMD rant.
Over the last couple of weeks we have been implementing a Universal Shader for OpenHMD, which will automatically correct the lenses based on parameters set in the drivers.
This makes it possible for developers to just implement 1 final shader and not worry about the rest, which is totally fine!

During this progress Nedlinpopo, one of our lovely contributors has figured out the firmware properties for the Oculus DK2 and CV1 were a bit off, redesigning the variables by recalculating them himself with a custom frustum.

Why is this needed? The Firmware reports different values then the hardware uses.....

During this process we found out that the IPD of the DK2 can actually be set, nice! if the values don't align we can at least set them based on our own calculations, and keep things the way there were, but the CV1.....
You can see they had to rush this out for production, The firmware reports back wrong values, and some one has confirmed OVR has hard coded values.

Why, o why would you do this if you have a firmware team you could just poke and ask to change the default variable, or at least expose a set method, like they had with the DK2.


Oculus is not the only one with firmware issues, OSVR has them as well.
This 'Open Source' headset has closed firmware, and does not expose all the sensors we would need to implement proper native support.
The Gyro is untouchable, they prefer to expose a pre-fused quaternion, which is wrong by default (it needs manual rotation every frame to align properly).

Sure i get that firmware can not be opened up even when its a bit sad (though I would not call a device "Open" then, I can replace almost all screens of my laptops, most of the vendors delivering howto guides, are they "Open" devices now?), but at least choose to expose the sensors and do the sensor fusion in software, this allows users to make tweaks, fix things, trying out other fusion techniques, instead of being forced to use a (wrong) fused quaternion.
I also suspect the documentation not lining up with what we find, but thats still in research.

Bottom line, please firmware developers, force your API/Driver devs to communicate, make sure things are logical and well implemented.
And API/Driver devs, think of the firmware, if they do it right, less work for you eh?