We do wanna support WebXR/WebVR simultaneously. However, we find out something like transform matrix of hmd and controllers have to be re-inverted for WebXR, and it might have others in the future. So, I would like to propose a way to detect if the website is asking for WebXR or WebVR sessions and forward a flag into VR shmem. Then, we will ask VR backends to do this conversion.

As future features are enabled in the browser, such as immersive video element extensions, the values in the ShMem will be used for things other than WebVR and WebXR. It is also important that the values be consistent as code rendering browser UX for FxR Desktop will be using the ShMem values while rendering.

May I suggest that we optimize for the forward-looking case, WebXR?

Specifically, we could change the formats used in the ShMem to match what WebXR needs. WebXR code would no longer need to re-invert, for example.

This would require the existing WebVR path to be updated with the invert instead.

IMHO, this would be preferable over maintaining additional state of "WebXR" vs "WebVR" on the VRService side of the ShMem.

This patch should be able to cover our requirements. It will send a flag from the content side to VRService via IPC when entering the presentation mode. Then, VR sessions will get this flag from VRBrowserState shmem.

I also notice the coordinates in OpenVR and Oculus are different. One of them has to invert its orientation to match the other one. We can keep an eye to watch other platforms like Quest and WaveVR. If others still need to reverse their orientation on their side, we can consider to move these reverse into XRFrame.

MozReview-Commit-ID: GriiniEGvWe

This patch is not ready to land because we still need to work on other FxR standalone devices coordinate convert. Besides, OpenVR has a eyeToHead transform, if we can't get it in VRDisplayClient, we will have a problem to make both eyes have correct view matrices.

The bug assignee didn't login in Bugzilla in the last 7 months.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.