The kernel never declares which EOTF modes it supports in HDR_OUTPUT_METADATA

The following discussion from !835 (merged) should be addressed:

• @daniels started a discussion: (+7 comments)

  From what I understand, there's no pruning (other than can only do SDR if no property) here, because the kernel never declares which EOTFs it understands, right? If so, this could probably just be flattened in somewhere else. But I'm not too concerned about it.

Amdgpu driver has peculiar behavior here. If I try to use HLG as EOTF mode on my monitor that says it does not support HLG mode, amdgpu rejects the atomic commit with Invalid value. Userspace is supposed to parse EDID to discover what the monitor supports.

As @swick points out, problems may arise when new EOTF modes are added, e.g. Source-Based Tone Mapping (SBTM).

If userspace parses EDID, understands SBTM, finds that SBTM is supported in EDID, attempts to use that, and kernel is too old to understand that SBTM is an option, the modeset will fail. (SBTM or any other new value for EOTF in HDR_OUTPUT_METADATA.)

I guess this cannot really be called a (future) regression, because SBTM never worked before, and it still doesn't. It does expose userspace to unexpected failures. One could say userspace just needs to TEST_ONLY and fall back, but OTOH why is the kernel checking this to begin with? The kernel only forwards the metadata to the sink as-is.

cc @emersion