feat(dashboard): Client overrides for OLED-pertinent encoding settings (10-bit, encoding gamma, etc)

[shinyquagsire23]

I kept seeing people complain about blocking in dark areas on AVP, and the encoding gamma option is a bit hidden :/

Enables client-side preference for 10-bit encoding, full-range encoding, encoding gamma, and HDR. OLED panels benefit from an encoding gamma of 1.5 to prevent the encoder from trying to throw away dark values that aren't visible on LCDs, and this encoding gamma requires 10-bit full-range encoding in order to prevent the color correction from being lossy at 8-bit SDR.

HDR was also thrown in but I'm not brave enough to make it default on AVP yet, it has a non-zero performance cost that folks in humid clients might actually bump into.

[zmerp]

I don't think this should be a manual setting, by default at least. There should be an "automatic" option where the client advertises its preferred option.

[zmerp]

Ok, negotiating a preset value is not really possible, because presets are only a dashboard concept. You could add a new setting "client overrides display color params" which then translates to the "Automatic" preset option

[shinyquagsire23]

Agreed, imo a lot of settings should just have an automatic default (headset and controller emulation for instance). But atm all the presets are kinda stuck being hardcoded so this is just a stopgap until resolutions/FPS/etc can be negotiated and displayed as negotiated.

Edit: And yeah I think the easy way would be some booleans which the presets set if they're automatic + some shenanigans.

[shinyquagsire23]

tho actually to be clear, if I'm doing any Automatic infrastructure I'd probably start scoping it out with the headset/controller settings first (in a later PR), and then do color settings either with that PR or in another one

[zmerp]

Actually, i think every parameter should be negotiated independently. The client should send its parameters probably as just true/false, and defaulting to false. Use a Option if the parameter has multiple options (None is the default meaning the client doesn't support that option). Then for each setting on the server, add an override option. In case the negotiation param is an Option, don't wrap the setting with Option because we still need a default value in case the client doesn't actually support the negotiation for that value.

[zmerp]

tho actually to be clear, if I'm doing any Automatic infrastructure I'd probably start scoping it out with the headset/controller settings first (in a later PR), and then do color settings either with that PR or in another one

I don't think we need to do much for headset/controllers right now. There are some settings in there that don't apply to avp but it's not an issue

Also i would prefer if you do the negotiation part in this PR.

[zmerp]

You should negotiate also the 10bit and full range parameters

[shinyquagsire23]

You should negotiate also the 10bit and full range parameters

I don't think there's much of a point for those two, those are always transmitted in the stream itself. Though, actually yeah I guess the OpenXR client still has some nonsense doesn't it, since it doesn't handle full range correctly.

[zmerp]

I don't think there's much of a point for those two, those are always transmitted in the stream itself. Though, actually yeah I guess the OpenXR client still has some nonsense doesn't it, since it doesn't handle full range correctly.

Ah right, nevermind. i see we never reference full range or 10 bit in the renderer or decoder. we have a full range fix, but that uses only enable_hdr.

[zmerp]

Needs a rebase. It's my fault, sorry about that