~emersion/drmdb

270711bb9666615b8712a9fe81dbba77c6a9ee5e — Simon Ser 26 days ago 85ea5ba
drmdoc: update docs from upstream
M drmdoc/color-management-properties.go => drmdoc/color-management-properties.go +1 -1
@@ 7,5 7,5 @@ var colorManagementProperties = map[string]string{
	"DEGAMMA_LUT":      "Blob property to set the degamma lookup table (LUT) mapping pixel data\nfrom the framebuffer before it is given to the transformation matrix.\nThe data is interpreted as an array of &struct drm_color_lut elements.\nHardware might choose not to use the full precision of the LUT elements\nnor use all the elements of the LUT (for example the hardware might\nchoose to interpolate between LUT[0] and LUT[4]).\n\nSetting this to NULL (blob property value set to 0) means a\nlinear/pass-thru gamma table should be used. This is generally the\ndriver boot-up state too. Drivers can access this blob through\n&drm_crtc_state.degamma_lut.",
	"DEGAMMA_LUT_SIZE": "Unsinged range property to give the size of the lookup table to be set\non the DEGAMMA_LUT property (the size depends on the underlying\nhardware). If drivers support multiple LUT sizes then they should\npublish the largest size, and sub-sample smaller sized LUTs (e.g. for\nsplit-gamma modes) appropriately.",
	"GAMMA_LUT":        "Blob property to set the gamma lookup table (LUT) mapping pixel data\nafter the transformation matrix to data sent to the connector. The\ndata is interpreted as an array of &struct drm_color_lut elements.\nHardware might choose not to use the full precision of the LUT elements\nnor use all the elements of the LUT (for example the hardware might\nchoose to interpolate between LUT[0] and LUT[4]).\n\nSetting this to NULL (blob property value set to 0) means a\nlinear/pass-thru gamma table should be used. This is generally the\ndriver boot-up state too. Drivers can access this blob through\n&drm_crtc_state.gamma_lut.",
	"GAMMA_LUT_SIZE":   "Unsigned range property to give the size of the lookup table to be set\non the GAMMA_LUT property (the size depends on the underlying hardware).\nIf drivers support multiple LUT sizes then they should publish the\nlargest size, and sub-sample smaller sized LUTs (e.g. for split-gamma\nmodes) appropriately.\n\nThere is also support for a legacy gamma table, which is set up by calling\ndrm_mode_crtc_set_gamma_size(). Drivers which support both should use\ndrm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp with the\n\"GAMMA_LUT\" property above.\n\nSupport for different non RGB color encodings is controlled through\n&drm_plane specific COLOR_ENCODING and COLOR_RANGE properties. They\nare set up by calling drm_plane_create_color_properties().\n\n\"COLOR_ENCODING\"\nOptional plane enum property to support different non RGB\ncolor encodings. The driver can provide a subset of standard\nenum values supported by the DRM plane.\n\n\"COLOR_RANGE\"\nOptional plane enum property to support different non RGB\ncolor parameter ranges. The driver can provide a subset of\nstandard enum values supported by the DRM plane.",
	"GAMMA_LUT_SIZE":   "Unsigned range property to give the size of the lookup table to be set\non the GAMMA_LUT property (the size depends on the underlying hardware).\nIf drivers support multiple LUT sizes then they should publish the\nlargest size, and sub-sample smaller sized LUTs (e.g. for split-gamma\nmodes) appropriately.",
}

M drmdoc/plane-blending-properties.go => drmdoc/plane-blending-properties.go +3 -2
@@ 4,12 4,13 @@ package drmdoc

var planeBlendingProperties = map[string]string{
	"CRTC_H":           "Height for the destination rectangle. CRTC_Y plus CRTC_H can extend past\nthe currently visible vertical area of the &drm_crtc.",
	"CRTC_ID":          "Mode object ID of the &drm_crtc this plane should be connected to.\n\nNote that the source rectangle must fully lie within the bounds of the\n&drm_framebuffer. The destination rectangle can lie outside of the visible\narea of the current mode of the CRTC. It must be apprpriately clipped by the\ndriver, which can be done by calling drm_plane_helper_check_update(). Drivers\nare also allowed to round the subpixel sampling positions appropriately, but\nonly to the next full pixel. No pixel outside of the source rectangle may\never be sampled, which is important when applying more sophisticated\nfiltering than just a bilinear one when scaling. The filtering mode when\nscaling is unspecified.\n\nOn top of this basic transformation additional properties can be exposed by",
	"CRTC_ID":          "Mode object ID of the &drm_crtc this plane should be connected to.",
	"CRTC_W":           "Width for the destination rectangle. CRTC_X plus CRTC_W can extend past\nthe currently visible horizontal area of the &drm_crtc.",
	"CRTC_X":           "X coordinate offset for the destination rectangle. Can be negative.",
	"CRTC_Y":           "Y coordinate offset for the destination rectangle. Can be negative.",
	"FB_ID":            "Mode object ID of the &drm_framebuffer this plane should scan out.",
	"IN_FORMATS":       "Blob property which contains the set of buffer format and modifier\npairs supported by this plane. The blob is a drm_format_modifier_blob\nstruct. Without this property the plane doesn't support buffers with\nmodifiers. Userspace cannot change this property.\n\nNote that all the property extensions described here apply either to the\nplane or the CRTC (e.g. for the background color, which currently is not\nexposed and assumed to be black).",
	"IN_FORMATS":       "Blob property which contains the set of buffer format and modifier\npairs supported by this plane. The blob is a drm_format_modifier_blob\nstruct. Without this property the plane doesn't support buffers with\nmodifiers. Userspace cannot change this property.",
	"SCALING_FILTER":   "Indicates scaling filter to be used for plane scaler\n\nThe value of this property can be one of the following:\nDefault:\n        Driver's default scaling filter\nNearest Neighbor:\n        Nearest Neighbor scaling filter",
	"SRC_H":            "Height for the source rectangle within the &drm_framebuffer, in 16.16\nfixed point. SRC_Y plus SRC_H must be within the height of the source\nframebuffer. Must be positive.",
	"SRC_W":            "Width for the source rectangle within the &drm_framebuffer, in 16.16\nfixed point. SRC_X plus SRC_W must be within the width of the source\nframebuffer. Must be positive.",
	"SRC_X":            "X coordinate offset for the source rectangle within the\n&drm_framebuffer, in 16.16 fixed point. Must be positive.",

M drmdoc/standard-connector-properties.go => drmdoc/standard-connector-properties.go +1 -1
@@ 6,7 6,7 @@ var standardConnectorProperties = map[string]string{
	"CRTC_ID":             "Mode object ID of the &drm_crtc this connector should be connected to.",
	"Content Protection":  "This property is used by userspace to request the kernel protect future\ncontent communicated over the link. When requested, kernel will apply\nthe appropriate means of protection (most often HDCP), and use the\nproperty to tell userspace the protection is active.\n\nDrivers can set this up by calling\ndrm_connector_attach_content_protection_property() on initialization.\n\nThe value of this property can be one of the following:\n\nDRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0\n\tThe link is not protected, content is transmitted in the clear.\nDRM_MODE_CONTENT_PROTECTION_DESIRED = 1\n\tUserspace has requested content protection, but the link is not\n\tcurrently protected. When in this state, kernel should enable\n\tContent Protection as soon as possible.\nDRM_MODE_CONTENT_PROTECTION_ENABLED = 2\n\tUserspace has requested content protection, and the link is\n\tprotected. Only the driver can set the property to this value.\n\tIf userspace attempts to set to ENABLED, kernel will return\n\t-EINVAL.\n\nA few guidelines:\n\n- DESIRED state should be preserved until userspace de-asserts it by\n  setting the property to UNDESIRED. This means ENABLED should only\n  transition to UNDESIRED when the user explicitly requests it.\n- If the state is DESIRED, kernel should attempt to re-authenticate the\n  link whenever possible. This includes across disable/enable, dpms,\n  hotplug, downstream device changes, link status failures, etc..\n- Kernel sends uevent with the connector id and property id through\n  @drm_hdcp_update_content_protection, upon below kernel triggered\n  scenarios:\n\n\t- DESIRED -> ENABLED (authentication success)\n\t- ENABLED -> DESIRED (termination of authentication)\n- Please note no uevents for userspace triggered property state changes,\n  which can't fail such as\n\n\t- DESIRED/ENABLED -> UNDESIRED\n\t- UNDESIRED -> DESIRED\n- Userspace is responsible for polling the property or listen to uevents\n  to determine when the value transitions from ENABLED to DESIRED.\n  This signifies the link is no longer protected and userspace should\n  take appropriate action (whatever that might be).",
	"DPMS":                "Legacy property for setting the power state of the connector. For atomic\ndrivers this is only provided for backwards compatibility with existing\ndrivers, it remaps to controlling the \"ACTIVE\" property on the CRTC the\nconnector is linked to. Drivers should never set this property directly,\nit is handled by the DRM core by calling the &drm_connector_funcs.dpms\ncallback. For atomic drivers the remapping to the \"ACTIVE\" property is\nimplemented in the DRM core.\n\nNote that this property cannot be set through the MODE_ATOMIC ioctl,\nuserspace must use \"ACTIVE\" on the CRTC instead.\n\nWARNING:\n\nFor userspace also running on legacy drivers the \"DPMS\" semantics are a\nlot more complicated. First, userspace cannot rely on the \"DPMS\" value\nreturned by the GETCONNECTOR actually reflecting reality, because many\ndrivers fail to update it. For atomic drivers this is taken care of in\ndrm_atomic_helper_update_legacy_modeset_state().\n\nThe second issue is that the DPMS state is only well-defined when the\nconnector is connected to a CRTC. In atomic the DRM core enforces that\n\"ACTIVE\" is off in such a case, no such checks exists for \"DPMS\".\n\nFinally, when enabling an output using the legacy SETCONFIG ioctl then\n\"DPMS\" is forced to ON. But see above, that might not be reflected in\nthe software value on legacy drivers.\n\nSummarizing: Only set \"DPMS\" when the connector is known to be enabled,\nassume that a successful SETCONFIG call also sets \"DPMS\" to on, and\nnever read back the value of \"DPMS\" because it can be incorrect.",
	"EDID":                "Blob property which contains the current EDID read from the sink. This\nis useful to parse sink identification information like vendor, model\nand serial. Drivers should update this property by calling\ndrm_connector_update_edid_property(), usually after having parsed\nthe EDID using drm_add_edid_modes(). Userspace cannot change this\nproperty.",
	"EDID":                "Blob property which contains the current EDID read from the sink. This\nis useful to parse sink identification information like vendor, model\nand serial. Drivers should update this property by calling\ndrm_connector_update_edid_property(), usually after having parsed\nthe EDID using drm_add_edid_modes(). Userspace cannot change this\nproperty.\n\nUser-space should not parse the EDID to obtain information exposed via\nother KMS properties (because the kernel might apply limits, quirks or\nfixups to the EDID). For instance, user-space should not try to parse\nmode lists from the EDID.",
	"HDCP Content Type":   "This Enum property is used by the userspace to declare the content type\nof the display stream, to kernel. Here display stream stands for any\ndisplay content that userspace intended to display through HDCP\nencryption.\n\nContent Type of a stream is decided by the owner of the stream, as\n\"HDCP Type0\" or \"HDCP Type1\".\n\nThe value of the property can be one of the below:\n  - \"HDCP Type0\": DRM_MODE_HDCP_CONTENT_TYPE0 = 0\n  - \"HDCP Type1\": DRM_MODE_HDCP_CONTENT_TYPE1 = 1\n\nWhen kernel starts the HDCP authentication (see \"Content Protection\"\nfor details), it uses the content type in \"HDCP Content Type\"\nfor performing the HDCP authentication with the display sink.\n\nPlease note in HDCP spec versions, a link can be authenticated with\nHDCP 2.2 for Content Type 0/Content Type 1. Where as a link can be\nauthenticated with HDCP1.4 only for Content Type 0(though it is implicit\nin nature. As there is no reference for Content Type in HDCP1.4).\n\nHDCP2.2 authentication protocol itself takes the \"Content Type\" as a\nparameter, which is a input for the DP HDCP2.2 encryption algo.\n\nIn case of Type 0 content protection request, kernel driver can choose\neither of HDCP spec versions 1.4 and 2.2. When HDCP2.2 is used for\n\"HDCP Type 0\", a HDCP 2.2 capable repeater in the downstream can send\nthat content to a HDCP 1.4 authenticated HDCP sink (Type0 link).\nBut if the content is classified as \"HDCP Type 1\", above mentioned\nHDCP 2.2 repeater wont send the content to the HDCP sink as it can't\nauthenticate the HDCP1.4 capable sink for \"HDCP Type 1\".\n\nPlease note userspace can be ignorant of the HDCP versions used by the\nkernel driver to achieve the \"HDCP Content Type\".\n\nAt current scenario, classifying a content as Type 1 ensures that the\ncontent will be displayed only through the HDCP2.2 encrypted link.\n\nNote that the HDCP Content Type property is introduced at HDCP 2.2, and\ndefaults to type 0. It is only exposed by drivers supporting HDCP 2.2\n(hence supporting Type 0 and Type 1). Based on how next versions of\nHDCP specs are defined content Type could be used for higher versions\ntoo.\n\nIf content type is changed when \"Content Protection\" is not UNDESIRED,\nthen kernel will disable the HDCP and re-enable with new type in the\nsame atomic commit. And when \"Content Protection\" is ENABLED, it means\nthat link is HDCP authenticated and encrypted, for the transmission of\nthe Type of stream mentioned at \"HDCP Content Type\".",
	"HDR_OUTPUT_METADATA": "Connector property to enable userspace to send HDR Metadata to\ndriver. This metadata is based on the composition and blending\npolicies decided by user, taking into account the hardware and\nsink capabilities. The driver gets this metadata and creates a\nDynamic Range and Mastering Infoframe (DRM) in case of HDMI,\nSDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then\nsent to sink. This notifies the sink of the upcoming frame's Color\nEncoding and Luminance parameters.\n\nUserspace first need to detect the HDR capabilities of sink by\nreading and parsing the EDID. Details of HDR metadata for HDMI\nare added in CTA 861.G spec. For DP , its defined in VESA DP\nStandard v1.4. It needs to then get the metadata information\nof the video/game/app content which are encoded in HDR (basically\nusing HDR transfer functions). With this information it needs to\ndecide on a blending policy and compose the relevant\nlayers/overlays into a common format. Once this blending is done,\nuserspace will be aware of the metadata of the composed frame to\nbe send to sink. It then uses this property to communicate this\nmetadata to driver which then make a Infoframe packet and sends\nto sink based on the type of encoder connected.\n\nUserspace will be responsible to do Tone mapping operation in case:\n\t- Some layers are HDR and others are SDR\n\t- HDR layers luminance is not same as sink\n\nIt will even need to do colorspace conversion and get all layers\nto one common colorspace for blending. It can use either GL, Media\nor display engine to get this done based on the capabilities of the\nassociated hardware.\n\nDriver expects metadata to be put in &struct hdr_output_metadata\nstructure from userspace. This is received as blob and stored in\n&drm_connector_state.hdr_output_metadata. It parses EDID and saves the\nsink metadata in &struct hdr_sink_metadata, as\n&drm_connector.hdr_sink_metadata.  Driver uses\ndrm_hdmi_infoframe_set_hdr_metadata() helper to set the HDR metadata,\nhdmi_drm_infoframe_pack() to pack the infoframe as per spec, in case of\nHDMI encoder.",
	"PATH":                "Connector path property to identify how this sink is physically\nconnected. Used by DP MST. This should be set by calling\ndrm_connector_set_path_property(), in the case of DP MST with the\npath property the MST manager created. Userspace cannot change this\nproperty.",

M drmdoc/standard-crtc-properties.go => drmdoc/standard-crtc-properties.go +3 -2
@@ 3,6 3,7 @@
package drmdoc

var standardCRTCProperties = map[string]string{
	"ACTIVE":  "Atomic property for setting the power state of the CRTC. When set to 1\nthe CRTC will actively display content. When set to 0 the CRTC will be\npowered off. There is no expectation that user-space will reset CRTC\nresources like the mode and planes when setting ACTIVE to 0.\n\nUser-space can rely on an ACTIVE change to 1 to never fail an atomic\ntest as long as no other property has changed. If a change to ACTIVE\nfails an atomic test, this is a driver bug. For this reason setting\nACTIVE to 0 must not release internal resources (like reserved memory\nbandwidth or clock generators).\n\nNote that the legacy DPMS property on connectors is internally routed\nto control this property for atomic drivers.",
	"MODE_ID": "Atomic property for setting the CRTC display timings. The value is the\nID of a blob containing the DRM mode info. To disable the CRTC,\nuser-space must set this property to 0.\n\nSetting MODE_ID to 0 will release reserved resources for the CRTC.",
	"ACTIVE":         "Atomic property for setting the power state of the CRTC. When set to 1\nthe CRTC will actively display content. When set to 0 the CRTC will be\npowered off. There is no expectation that user-space will reset CRTC\nresources like the mode and planes when setting ACTIVE to 0.\n\nUser-space can rely on an ACTIVE change to 1 to never fail an atomic\ntest as long as no other property has changed. If a change to ACTIVE\nfails an atomic test, this is a driver bug. For this reason setting\nACTIVE to 0 must not release internal resources (like reserved memory\nbandwidth or clock generators).\n\nNote that the legacy DPMS property on connectors is internally routed\nto control this property for atomic drivers.",
	"MODE_ID":        "Atomic property for setting the CRTC display timings. The value is the\nID of a blob containing the DRM mode info. To disable the CRTC,\nuser-space must set this property to 0.\n\nSetting MODE_ID to 0 will release reserved resources for the CRTC.",
	"SCALING_FILTER": "Atomic property for setting the scaling filter for CRTC scaler\n\nThe value of this property can be one of the following:\nDefault:\n\tDriver's default scaling filter\nNearest Neighbor:\n\tNearest Neighbor scaling filter",
}