fix: send full view config to openvr

[WilliamGanx]

Background: Same as #2198, rebased on the latest master. This change is specifically required for the PFDM MR device.

The PFDM MR device employs physically rotated displays to enable an expanded field of view (FOV). Previously, frame rotation was handled by the device runtime compositor to maintain 3rd party apps's backward compatibility (though this approach limited full utilization of the expanded FOV).

The latest OTA update introduces support for the standard KHR OpenXR Loader. OpenXR apps using the KHR loader must now render pre-rotated frames based on the left/right view configurations. If the full view configurations were not provided to OpenVR, the incorrect rendering could cause binocular misalignment.

The changes maintain theoretical compatibility across headset devices, and has been verified using Quest 3 units.

[zmerp]

This change breaks compatibility with the v20 protocol. I'm ok for merging this fix as version v21.0.0-dev02, but it can't be released until v21 stable. It will be a nightly-only fix for now

[zmerp]

Apart from the comments above, there is a format check fail from c++ code

[WilliamGanx]

Apart from the comments above, there is a format check fail from c++ code

I tried to fix the format errors from the c++ code, and there are no errors in local checks, but the online CI is still reporting errors.

cargo xtask check-format
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.20s
     Running `target\debug\alvr_xtask.exe check-format`
$ cargo fmt --all -- --check

Done [0m 1s]

[zmerp]

Run simply cargo xtask format to apply both Rust and c++ autofoemat

[curoviyxru]

cargo xtask format doesn't do anything on last commit in this PR. Also on master it adds the same space like here in Controller.h, but master has passed all checks, strange.

[The-personified-devil]

The format thing is a tad bit wonky sometimes if stuff changes between updates, I'll see if I can fix it for this pr

[shinyquagsire23]

fwiw I suspect there's a possible non-breaking mergable tempfix for this by always rendering the frames in world space based on the view params received w/ the frame, instead of the direct blit that we're doing (identity reprojection_rotation). That way if the streamer sends frames that are not canted, they can still be drawn even if there is a resampling penalty.

(I say world space, but it doesn't actually have to be in world space, but I've found that the math is much easier with a world space render pass; the streamer compositor is a good reference)

[WilliamGanx]

fwiw I suspect there's a possible non-breaking mergable tempfix for this by always rendering the frames in world space based on the view params received w/ the frame, instead of the direct blit that we're doing (identity reprojection_rotation). That way if the streamer sends frames that are not canted, they can still be drawn even if there is a resampling penalty.

(I say world space, but it doesn't actually have to be in world space, but I've found that the math is much easier with a world space render pass; the streamer compositor is a good reference)

From what I understand, in addition to the resampling penalty, there is also a FOV penalty.
Here is a user test report on the FOV.

With rotated rendering:
   horizontal: 94.46 deg
   vertical: 90.00 deg
   diagonal: 111.64 deg
   overlap: 94.46 deg

Without rotated rendering:
    horizontal: 102.46 deg
    vertical:    89.86 deg
    diagonal:   117.60 deg
    overlap:     86.46 deg

[shinyquagsire23]

Yeah, it would require a bit of over-rendering. For visionOS I added an "FOV comfort" slider to intentionally scale the render tangents to compensate for underprediction, might be worth moving/adding to the streamer.

[zmerp]

might be worth moving/adding to the streamer

That was the plan after the v21 protocol break