Commits on Source (9)
-
This is the switch to turn HDR mode on. The values in the enumeration come straight from CTA-861-G standard. Monitors advertise support for some of the HDR modes in their EDID, and I am not aware of any other way to detect if a HDR mode actually works or not. Different monitors may support different and multiple modes. Different modes may look different. Therefore the high-level choice of how to drive a HDR video sink is left for the Weston frontend to decide. All the details like what HDR metadata to use are left for the color manager. This commit adds the libweston API for backends to advertise support and for frontends to choose a mode. Backend and frontend implementations follow in other commits. The frontend API does not limit the EOTF mode to the supported ones to allow experimentation and overriding EDID. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
5f9b68d6 -
The headless backend does not display to anything, so it doesn't care what the EOTF mode is. To allow testing compositor internal behavior, claim to support all EOTF modes. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
1e9b1a10 -
The no-op color manager will not support any other EOTF mode than SDR. Other modes would require it to set up color transformations. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
46c0383c -
A reminder that this variable needs to be taken into account when crafting color transformations. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
271c11e9 -
These are fallback definitions in case libdrm is not new enough. They are copied from libdrm 2.4.107. struct hdr_output_metadata defines the contents of the blob to be used with the connector property "HDR_OUTPUT_METADATA". This is needed for programming a HDR mode in KMS. This headers need to be excluded from Doxygen, because Doxygen chokes on the kerneldoc markup. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
69140640 -
Check whether HDR_OUTPUT_METADATA property exists on a KMS connector. If yes, pretend that EDID claims support for all EOTF modes and update the head supported EOTFs mask accordingly. If not, then only SDR is possible. Parsing EDID to take monitor capabilities into account is left for later. HDR mode cannot be set without HDR_OUTPUT_METADATA. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
1d17e499 -
Program the connector property HDR_OUTPUT_METADATA based on the EOTF mode of the output. For now, this changes only the EOTF. The colorimetry and luminance are left undefined, to be filled in by later patches. This should still be enough to put a video sink into HDR mode, albeit the response is probably unknown. drm_output keeps track of the currently existing blob id. If the blob contents need to be re-created, this blob would be destroyed and the field set to zero. In this patch, there is no provision for runtime changing of HDR metadata, so there is no code doing that. Destroying the blob at arbitrary times is not a problem, because the kernel keeps a reference to the data as long as the blob id remains with KMS. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
5151f9fe -
This per-output option allows to choose one of the HDR video modes. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
33d553f8 -
Trying to do HDR with XRGB8888 is a bit like using RGB565 on SDR: you get visible color quantization and banding in gradients (without dithering which Weston does not implement yet, and might not work too well for HDR anyway). Therefore, on any HDR mode, default output framebuffer format to 10 bpc instead of 8 bpc. Ideally we'd also optionally try 16F or 16 bpc formats, but automatic fallbacks for those are more complicated to arrange. You can still configure 16F or 16 bpc manually. This patch also moves the default format setting from drm_output_set_gbm_format() to drm_output_enable(), because setting the default now requires eotf_mode. Frontends may call set_gbm_format() first and set eotf_mode next. This does create an awkward situation for outputs that a frontend disables and re-enables. This patch here makes sure that the old output configuration remains, but changing eotf_mode may not change the default format. One needs to call set_gbm_format(NULL) to re-evaluate the default format. Resetting the format on drm_output_deinit() would lose the current setting. DRM_FORMAT_INVALID was introduced in libdrm 2.4.95 which we already hard-depend on. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
e6a9e3c4
libweston/backend-drm/libdrm-updates.h
0 → 100644