Hi
Am 09.10.20 um 11:24 schrieb Simon Ser:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
>
> Signed-off-by: Simon Ser <contact@xxxxxxxxxxx>
> Suggested-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> Cc: Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxxxx>
> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/drm_connector.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> * drm_connector_update_edid_property(), usually after having parsed
> * the EDID using drm_add_edid_modes(). Userspace cannot change this
> * property.
> + *
> + * User-space should not parse the EDID to obtain information exposed via
> + * other KMS properties. For instance, user-space should not try to parse
> + * mode lists from the EDID.
Acked-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
But this makes me wonder why the kernel exposes raw EDID in the first
place. Wouldn't it be better to expose meaningful fields (display model,
vendor, etc) instead?
Best regards
Thomas
> * DPMS:
> * Legacy property for setting the power state of the connector. For atomic
> * drivers this is only provided for backwards compatibility with existing
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
