kernel/linux.git/Documentation/gpu/kms-properties.csv, branch v6.19.11

drm/connector: hdmi: Add Broadcast RGB property

2024-05-28T08:24:37+00:00

The i915 driver has a property to force the RGB range of an HDMI output. The vc4 driver then implemented the same property with the same semantics. KWin has support for it, and a PR for mutter is also there to support it. Both drivers implementing the same property with the same semantics, plus the userspace having support for it, is proof enough that it's pretty much a de-facto standard now and we can provide helpers for it. Let's plumb it into the newly created HDMI connector. Reviewed-by: Dave Stevenson Acked-by: Pekka Paalanen Reviewed-by: Sebastian Wick Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-18-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard

drm/doc: Remove unused Broadcast RGB Property

2024-05-28T08:24:37+00:00

The Broadcast RGB property has been documented as three separate entries so far, each with a different set of values. The first one is pretty much the generic one: it's used by i915 and vc4, and is the one used by all the compositors. The second one is used by the gma500 driver, and is a subset of the first one: it can have the values "Full" or "Limited 16:235", but lack the "Automatic" value. The third one however isn't used by any driver and documents the values "off", "auto" and "on". It's unclear where the last one comes from. It was first documented in commit 6c6a3996f2c5 ("Documentation: drm: describing drm properties exposed by various drivers") which adds a number of properties used by drivers, but without mentioning which driver was using what property. Grepping at the 6c6a3996f2c5 commit however, it looks like no driver is actually using it, and a quick look at the entire kernel history doesn't show any match either. At the time though, gma500 had an "audio" property used right next to Broadcast RGB that did have the "off", "auto" and "on" values in the same order. As such, it was probably a copy/paste or scripting error back then, and there's never been such property used in the kernel. Either way, it certainly hasn't been used in a decade or two so we can just get rid of it. Suggested-by: Dmitry Baryshkov Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-17-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard

Documentation: Fix typos

2023-08-18T17:29:03+00:00

Fix typos in Documentation. Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org Signed-off-by: Jonathan Corbet

drm/doc: Drop "content type" from the legacy kms property table

2019-03-26T13:18:51+00:00

We want new stuff documented in more verbose form, this table is deprecated. "content type" is already documented properly. Reviewed-by: Ville Syrjälä Fixes: 50525c332b55 ("drm: content-type property for HDMI connector") Cc: Hans Verkuil Cc: Daniel Vetter Cc: Stanislav Lisovskiy Cc: Ville Syrjälä Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190326090555.5969-1-daniel.vetter@ffwll.ch

drm: content-type property for HDMI connector

2018-05-17T15:58:35+00:00

Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by: Hans Verkuil Acked-by: Daniel Vetter Signed-off-by: Stanislav Lisovskiy Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by: Ville Syrjälä

drm/docs: Remove the rcar alpha from the csv file

2018-04-16T19:21:48+00:00

Now that we moved the rcar-du DRM driver has been switched to the generic alpha property, remove the former property documentation from the deprecated CSV file. Acked-by: Maarten Lankhorst Acked-by: Sean Paul Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/04be5e2256aa8d33d9521a68a10f0b73a24f8040.1523432341.git-series.maxime.ripard@bootlin.com

drm/docs: Document "scaling mode" property better

2018-02-20T11:10:46+00:00

Move it out of the csv dungeon. While at it add the missing link to the helper functions for setting up the "panel rotation" property. Also OCD how we list enum property values and their corresponding docs. Going for a nest definition list seams cleanest, no need for also making it an uordered list. Cc: Sean Paul Cc: Hans de Goede Reviewed-by: Thierry Reding Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-3-daniel.vetter@ffwll.ch

drm/doc: remove standard connector props from the csv file

2017-03-29T06:33:25+00:00

They're properly documented in drm_connector.c now, and this csv file is a horrible mess. Better to remove it. Reviewed-by: Alex Deucher Reviewed-by: Harry Wentland Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170328155349.5972-1-daniel.vetter@ffwll.ch

drm: Remove dirty property from docs

2016-09-22T07:04:03+00:00

We removed it in commit 6ab10b76ff6252bd9be0849c40f5865e39a29961 Author: Daniel Vetter Date: Fri Aug 12 22:48:45 2016 +0200 drm/kms: Nuke dirty_info property Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/1474448370-32227-7-git-send-email-daniel.vetter@ffwll.ch

drm/doc: Document color space handling

2016-09-22T07:04:03+00:00

Again move it from the unmaintainable csv into DOC free-form overview sections. v2: Types Lionel&Sean spotted. Cc: Lionel Landwerlin Reviewed-by: Sean Paul Reviewed-by: Lionel Landwerlin Signed-off-by: Daniel Vetter Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/1474448370-32227-6-git-send-email-daniel.vetter@ffwll.ch