@@ 9,7 9,7 @@ var standardConnectorProperties = map[string]string{
"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.",
+ "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.\n\nIn the case of DP MST, the property has the format\n``mst:<parent>-<ports>`` where ``<parent>`` is the KMS object ID of the\nparent connector and ``<ports>`` is a hyphen-separated list of DP MST\nport numbers. Note, KMS object IDs are not guaranteed to be stable\nacross reboots.",
"TILE": "Connector tile group property to indicate how a set of DRM connector\ncompose together into one logical screen. This is used by both high-res\nexternal screens (often only using a single cable, but exposing multiple\nDP MST sinks), or high-res integrated panels (like dual-link DSI) which\nare not gen-locked. Note that for tiled panels which are genlocked, like\ndual-link LVDS or dual-link DSI, the driver should try to not expose the\ntiling and virtualise both &drm_crtc and &drm_plane if needed. Drivers\nshould update this value using drm_connector_set_tile_property().\nUserspace cannot change this property.",
"bottom margin": "Add margins to the connector's viewport. This is typically used to\nmitigate overscan on TVs.\n\nThe value is the size in pixels of the black border which will be\nadded. The attached CRTC's content will be scaled to fill the whole\narea inside the margin.\n\nThe margins configuration might be sent to the sink, e.g. via HDMI AVI\nInfoFrames.\n\nDrivers can set up these properties by calling\ndrm_mode_create_tv_margin_properties().",
"left margin": "Add margins to the connector's viewport. This is typically used to\nmitigate overscan on TVs.\n\nThe value is the size in pixels of the black border which will be\nadded. The attached CRTC's content will be scaled to fill the whole\narea inside the margin.\n\nThe margins configuration might be sent to the sink, e.g. via HDMI AVI\nInfoFrames.\n\nDrivers can set up these properties by calling\ndrm_mode_create_tv_margin_properties().",
@@ 4,5 4,6 @@ package drmdoc
var standardPlaneProperties = map[string]string{
"IN_FORMATS": "Blob property which contains the set of buffer format and modifier\npairs supported by this plane. The blob is a struct\ndrm_format_modifier_blob. Without this property the plane doesn't\nsupport buffers with modifiers. Userspace cannot change this property.\n\nNote that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver\ncapability for general modifier support. If this flag is set then every\nplane will have the IN_FORMATS property, even when it only supports\nDRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been\nvarious bugs in this area with inconsistencies between the capability\nflag and per-plane properties.",
+ "SIZE_HINTS": "Blob property which contains the set of recommended plane size\nwhich can used for simple \"cursor like\" use cases (eg. no scaling).\nUsing these hints frees userspace from extensive probing of\nsupported plane sizes through atomic/setcursor ioctls.\n\nThe blob contains an array of struct drm_plane_size_hint, in\norder of preference. For optimal usage userspace should pick\nthe first size that satisfies its own requirements.\n\nDrivers should only attach this property to planes that\nsupport a very limited set of sizes.\n\nNote that property value 0 (ie. no blob) is reserved for potential\nfuture use. Current userspace is expected to ignore the property\nif the value is 0, and fall back to some other means (eg.\n&DRM_CAP_CURSOR_WIDTH and &DRM_CAP_CURSOR_HEIGHT) to determine\nthe appropriate plane size to use.",
"type": "Immutable property describing the type of the plane.\n\nFor user-space which has enabled the &DRM_CLIENT_CAP_ATOMIC capability,\nthe plane type is just a hint and is mostly superseded by atomic\ntest-only commits. The type hint can still be used to come up more\neasily with a plane configuration accepted by the driver.\n\nThe value of this property can be one of the following:\n\n\"Primary\":\n To light up a CRTC, attaching a primary plane is the most likely to\n work if it covers the whole CRTC and doesn't have scaling or\n cropping set up.\n\n Drivers may support more features for the primary plane, user-space\n can find out with test-only atomic commits.\n\n Some primary planes are implicitly used by the kernel in the legacy\n IOCTLs &DRM_IOCTL_MODE_SETCRTC and &DRM_IOCTL_MODE_PAGE_FLIP.\n Therefore user-space must not mix explicit usage of any primary\n plane (e.g. through an atomic commit) with these legacy IOCTLs.\n\n\"Cursor\":\n To enable this plane, using a framebuffer configured without scaling\n or cropping and with the following properties is the most likely to\n work:\n\n - If the driver provides the capabilities &DRM_CAP_CURSOR_WIDTH and\n &DRM_CAP_CURSOR_HEIGHT, create the framebuffer with this size.\n Otherwise, create a framebuffer with the size 64x64.\n - If the driver doesn't support modifiers, create a framebuffer with\n a linear layout. Otherwise, use the IN_FORMATS plane property.\n\n Drivers may support more features for the cursor plane, user-space\n can find out with test-only atomic commits.\n\n Some cursor planes are implicitly used by the kernel in the legacy\n IOCTLs &DRM_IOCTL_MODE_CURSOR and &DRM_IOCTL_MODE_CURSOR2.\n Therefore user-space must not mix explicit usage of any cursor\n plane (e.g. through an atomic commit) with these legacy IOCTLs.\n\n Some drivers may support cursors even if no cursor plane is exposed.\n In this case, the legacy cursor IOCTLs can be used to configure the\n cursor.\n\n\"Overlay\":\n Neither primary nor cursor.\n\n Overlay planes are the only planes exposed when the\n &DRM_CLIENT_CAP_UNIVERSAL_PLANES capability is disabled.",
}