HDR Headset Displays

[bjornbytes]

Adds t.headset.hdr and lovr.headset.isHDR. Similar to the existing t.graphics.hdr and lovr.graphics.isHDR, which is for the desktop window. Uses the new XR_SONY_swapchain_color_space extension.

Has the same semantics/caveats as window HDR: You get an HDR10 (rgb10a2 + bt2020 + pq) texture and it's up to you to write correct color data.

[bjornbytes]

• Why not lovr.headset.getFeatures().hdr?
  • Querying the supported color spaces requires an active OpenXR session, so we can't actually check for HDR support until lovr.headset.start is called.
  • So we don't know if the feature should be true or false before lovr.headset.start.
  • We could have an hdr feature that means "this runtime is capable of advanced color space stuff" but that's too low-level and could be wrong (runtime supports color spaces but doesn't support the exact HDR combo we need).
  • Note that the depthSubmission feature kinda has this same problem -- it's gated on some information that we can't know until lovr.headset.start, so it could unexpectedly go from true -> false after starting the session.
• It's weird how there's t.graphics.hdr and t.headset.hdr.
  • The desktop monitor HDR is separate from the headset HDR.
  • One idea nagging at me is adding the notion of "displays" or rendering surfaces, like a Display object or lovr.display module. A display could be either the desktop window or a headset. Then more of these duplicated APIs could be shared (dimensions, focus states, HDR, textures/passes, MSAA, etc.).
• When headset is HDR but window is not, lovr.mirror blit won't look right.
  • Yes
• Layer / lovr.headset.setBackground could support HDR
  • Yes, left for future
• Note: this change is untested, no known runtimes support this yet. It's fine for this to lie dormant because it's opt-in and non-invasive.