@@ 3,19 3,24 @@
package drmdoc
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.\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.",
- "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.",
- "link-status": "Connector link-status property to indicate the status of link. The\ndefault value of link-status is \"GOOD\". If something fails during or\nafter modeset, the kernel driver may set this to \"BAD\" and issue a\nhotplug uevent. Drivers should update this value using\ndrm_connector_set_link_status_property().\n\nWhen user-space receives the hotplug uevent and detects a \"BAD\"\nlink-status, the sink doesn't receive pixels anymore (e.g. the screen\nbecomes completely black). The list of available modes may have\nchanged. User-space is expected to pick a new mode if the current one\nhas disappeared and perform a new modeset with link-status set to\n\"GOOD\" to re-enable the connector.\n\nIf multiple connectors share the same CRTC and one of them gets a \"BAD\"\nlink-status, the other are unaffected (ie. the sinks still continue to\nreceive pixels).\n\nWhen user-space performs an atomic commit on a connector with a \"BAD\"\nlink-status without resetting the property to \"GOOD\", the sink may\nstill not receive pixels. When user-space performs an atomic commit\nwhich resets the link-status property to \"GOOD\" without the\nALLOW_MODESET flag set, it might fail because a modeset is required.\n\nUser-space can only change link-status to \"GOOD\", changing it to \"BAD\"\nis a no-op.\n\nFor backwards compatibility with non-atomic userspace the kernel\ntries to automatically set the link-status back to \"GOOD\" in the\nSETCRTC IOCTL. This might fail if the mode is no longer valid, similar\nto how it might fail if a different screen has been connected in the\ninterim.",
- "max bpc": "This range property is used by userspace to limit the bit depth. When\nused the driver would limit the bpc in accordance with the valid range\nsupported by the hardware and sink. Drivers to use the function\ndrm_connector_attach_max_bpc_property() to create and attach the\nproperty to the connector during initialization.",
- "non_desktop": "Indicates the output should be ignored for purposes of displaying a\nstandard desktop environment or console. This is most likely because\nthe output device is not rectilinear.",
- "panel orientation": "On some devices the LCD panel is mounted in the casing in such a way\nthat the up/top side of the panel does not match with the top side of\nthe device. Userspace can use this property to check for this.\nNote that input coordinates from touchscreens (input devices with\nINPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel\ncoordinates, so if userspace rotates the picture to adjust for\nthe orientation it must also apply the same transformation to the\ntouchscreen input coordinates. This property is initialized by calling\ndrm_connector_set_panel_orientation() or\ndrm_connector_set_panel_orientation_with_quirk()",
- "privacy-screen sw-state, privacy-screen hw-state": "These 2 optional properties can be used to query the state of the\nelectronic privacy screen that is available on some displays; and in\nsome cases also control the state. If a driver implements these\nproperties then both properties must be present.\n\n\"privacy-screen hw-state\" is read-only and reflects the actual state\nof the privacy-screen, possible values: \"Enabled\", \"Disabled,\n\"Enabled-locked\", \"Disabled-locked\". The locked states indicate\nthat the state cannot be changed through the DRM API. E.g. there\nmight be devices where the firmware-setup options, or a hardware\nslider-switch, offer always on / off modes.\n\n\"privacy-screen sw-state\" can be set to change the privacy-screen state\nwhen not locked. In this case the driver must update the hw-state\nproperty to reflect the new state on completion of the commit of the\nsw-state property. Setting the sw-state property when the hw-state is\nlocked must be interpreted by the driver as a request to change the\nstate to the set state when the hw-state becomes unlocked. E.g. if\n\"privacy-screen hw-state\" is \"Enabled-locked\" and the sw-state\ngets set to \"Disabled\" followed by the user unlocking the state by\nchanging the slider-switch position, then the driver must set the\nstate to \"Disabled\" upon receiving the unlock event.\n\nIn some cases the privacy-screen's actual state might change outside of\ncontrol of the DRM code. E.g. there might be a firmware handled hotkey\nwhich toggles the actual state, or the actual state might be changed\nthrough another userspace API such as writing /proc/acpi/ibm/lcdshadow.\nIn this case the driver must update both the hw-state and the sw-state\nto reflect the new value, overwriting any pending state requests in the\nsw-state. Any pending sw-state requests are thus discarded.\n\nNote that the ability for the state to change outside of control of\nthe DRM master process means that userspace must not cache the value\nof the sw-state. Caching the sw-state value and including it in later\natomic commits may lead to overriding a state change done through e.g.\na firmware handled hotkey. Therefor userspace must not include the\nprivacy-screen sw-state in an atomic commit unless it wants to change\nits value.",
- "scaling mode": "This property defines how a non-native mode is upscaled to the native\nmode of an LCD panel:\n\nNone:\n\tNo upscaling happens, scaling is left to the panel. Not all\n\tdrivers expose this mode.\nFull:\n\tThe output is upscaled to the full resolution of the panel,\n\tignoring the aspect ratio.\nCenter:\n\tNo upscaling happens, the output is centered within the native\n\tresolution the panel.\nFull aspect:\n\tThe output is upscaled to maximize either the width or height\n\twhile retaining the aspect ratio.\n\nThis property should be set up by calling\ndrm_connector_attach_scaling_mode_property(). Note that drivers\ncan also expose this property to external outputs, in which case they\nmust support \"None\", which should be the default (since external screens\nhave a built-in scaler).",
- "subconnector": "This property is used by DVI-I, TVout and DisplayPort to indicate different\nconnector subtypes. Enum values more or less match with those from main\nconnector types.\nFor DVI-I and TVout there is also a matching property \"select subconnector\"\nallowing to switch between signal types.\nDP subconnector corresponds to a downstream port.",
+ "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.\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.",
+ "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().",
+ "link-status": "Connector link-status property to indicate the status of link. The\ndefault value of link-status is \"GOOD\". If something fails during or\nafter modeset, the kernel driver may set this to \"BAD\" and issue a\nhotplug uevent. Drivers should update this value using\ndrm_connector_set_link_status_property().\n\nWhen user-space receives the hotplug uevent and detects a \"BAD\"\nlink-status, the sink doesn't receive pixels anymore (e.g. the screen\nbecomes completely black). The list of available modes may have\nchanged. User-space is expected to pick a new mode if the current one\nhas disappeared and perform a new modeset with link-status set to\n\"GOOD\" to re-enable the connector.\n\nIf multiple connectors share the same CRTC and one of them gets a \"BAD\"\nlink-status, the other are unaffected (ie. the sinks still continue to\nreceive pixels).\n\nWhen user-space performs an atomic commit on a connector with a \"BAD\"\nlink-status without resetting the property to \"GOOD\", the sink may\nstill not receive pixels. When user-space performs an atomic commit\nwhich resets the link-status property to \"GOOD\" without the\nALLOW_MODESET flag set, it might fail because a modeset is required.\n\nUser-space can only change link-status to \"GOOD\", changing it to \"BAD\"\nis a no-op.\n\nFor backwards compatibility with non-atomic userspace the kernel\ntries to automatically set the link-status back to \"GOOD\" in the\nSETCRTC IOCTL. This might fail if the mode is no longer valid, similar\nto how it might fail if a different screen has been connected in the\ninterim.",
+ "max bpc": "This range property is used by userspace to limit the bit depth. When\nused the driver would limit the bpc in accordance with the valid range\nsupported by the hardware and sink. Drivers to use the function\ndrm_connector_attach_max_bpc_property() to create and attach the\nproperty to the connector during initialization.",
+ "non_desktop": "Indicates the output should be ignored for purposes of displaying a\nstandard desktop environment or console. This is most likely because\nthe output device is not rectilinear.",
+ "panel orientation": "On some devices the LCD panel is mounted in the casing in such a way\nthat the up/top side of the panel does not match with the top side of\nthe device. Userspace can use this property to check for this.\nNote that input coordinates from touchscreens (input devices with\nINPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel\ncoordinates, so if userspace rotates the picture to adjust for\nthe orientation it must also apply the same transformation to the\ntouchscreen input coordinates. This property is initialized by calling\ndrm_connector_set_panel_orientation() or\ndrm_connector_set_panel_orientation_with_quirk()",
+ "privacy-screen hw-state": "These 2 optional properties can be used to query the state of the\nelectronic privacy screen that is available on some displays; and in\nsome cases also control the state. If a driver implements these\nproperties then both properties must be present.\n\n\"privacy-screen hw-state\" is read-only and reflects the actual state\nof the privacy-screen, possible values: \"Enabled\", \"Disabled,\n\"Enabled-locked\", \"Disabled-locked\". The locked states indicate\nthat the state cannot be changed through the DRM API. E.g. there\nmight be devices where the firmware-setup options, or a hardware\nslider-switch, offer always on / off modes.\n\n\"privacy-screen sw-state\" can be set to change the privacy-screen state\nwhen not locked. In this case the driver must update the hw-state\nproperty to reflect the new state on completion of the commit of the\nsw-state property. Setting the sw-state property when the hw-state is\nlocked must be interpreted by the driver as a request to change the\nstate to the set state when the hw-state becomes unlocked. E.g. if\n\"privacy-screen hw-state\" is \"Enabled-locked\" and the sw-state\ngets set to \"Disabled\" followed by the user unlocking the state by\nchanging the slider-switch position, then the driver must set the\nstate to \"Disabled\" upon receiving the unlock event.\n\nIn some cases the privacy-screen's actual state might change outside of\ncontrol of the DRM code. E.g. there might be a firmware handled hotkey\nwhich toggles the actual state, or the actual state might be changed\nthrough another userspace API such as writing /proc/acpi/ibm/lcdshadow.\nIn this case the driver must update both the hw-state and the sw-state\nto reflect the new value, overwriting any pending state requests in the\nsw-state. Any pending sw-state requests are thus discarded.\n\nNote that the ability for the state to change outside of control of\nthe DRM master process means that userspace must not cache the value\nof the sw-state. Caching the sw-state value and including it in later\natomic commits may lead to overriding a state change done through e.g.\na firmware handled hotkey. Therefor userspace must not include the\nprivacy-screen sw-state in an atomic commit unless it wants to change\nits value.",
+ "privacy-screen sw-state": "These 2 optional properties can be used to query the state of the\nelectronic privacy screen that is available on some displays; and in\nsome cases also control the state. If a driver implements these\nproperties then both properties must be present.\n\n\"privacy-screen hw-state\" is read-only and reflects the actual state\nof the privacy-screen, possible values: \"Enabled\", \"Disabled,\n\"Enabled-locked\", \"Disabled-locked\". The locked states indicate\nthat the state cannot be changed through the DRM API. E.g. there\nmight be devices where the firmware-setup options, or a hardware\nslider-switch, offer always on / off modes.\n\n\"privacy-screen sw-state\" can be set to change the privacy-screen state\nwhen not locked. In this case the driver must update the hw-state\nproperty to reflect the new state on completion of the commit of the\nsw-state property. Setting the sw-state property when the hw-state is\nlocked must be interpreted by the driver as a request to change the\nstate to the set state when the hw-state becomes unlocked. E.g. if\n\"privacy-screen hw-state\" is \"Enabled-locked\" and the sw-state\ngets set to \"Disabled\" followed by the user unlocking the state by\nchanging the slider-switch position, then the driver must set the\nstate to \"Disabled\" upon receiving the unlock event.\n\nIn some cases the privacy-screen's actual state might change outside of\ncontrol of the DRM code. E.g. there might be a firmware handled hotkey\nwhich toggles the actual state, or the actual state might be changed\nthrough another userspace API such as writing /proc/acpi/ibm/lcdshadow.\nIn this case the driver must update both the hw-state and the sw-state\nto reflect the new value, overwriting any pending state requests in the\nsw-state. Any pending sw-state requests are thus discarded.\n\nNote that the ability for the state to change outside of control of\nthe DRM master process means that userspace must not cache the value\nof the sw-state. Caching the sw-state value and including it in later\natomic commits may lead to overriding a state change done through e.g.\na firmware handled hotkey. Therefor userspace must not include the\nprivacy-screen sw-state in an atomic commit unless it wants to change\nits value.",
+ "right 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().",
+ "scaling mode": "This property defines how a non-native mode is upscaled to the native\nmode of an LCD panel:\n\nNone:\n\tNo upscaling happens, scaling is left to the panel. Not all\n\tdrivers expose this mode.\nFull:\n\tThe output is upscaled to the full resolution of the panel,\n\tignoring the aspect ratio.\nCenter:\n\tNo upscaling happens, the output is centered within the native\n\tresolution the panel.\nFull aspect:\n\tThe output is upscaled to maximize either the width or height\n\twhile retaining the aspect ratio.\n\nThis property should be set up by calling\ndrm_connector_attach_scaling_mode_property(). Note that drivers\ncan also expose this property to external outputs, in which case they\nmust support \"None\", which should be the default (since external screens\nhave a built-in scaler).",
+ "subconnector": "This property is used by DVI-I, TVout and DisplayPort to indicate different\nconnector subtypes. Enum values more or less match with those from main\nconnector types.\nFor DVI-I and TVout there is also a matching property \"select subconnector\"\nallowing to switch between signal types.\nDP subconnector corresponds to a downstream port.",
+ "top 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().",
}