This commit fixes following warnings found by checkpatch: WARNING: please, no space before tabs Signed-off-by: Nicolas Devos <ndevos-dev@xxxxx> --- drivers/gpu/drm/drm_connector.c | 712 ++++++++++++++++---------------- 1 file changed, 356 insertions(+), 356 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index de71805aab2c..d90b9ae6be3c 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1150,70 +1150,70 @@ static const u32 dp_colorspaces = * DRM connectors have a few standardized properties: * * EDID: - * Blob property which contains the current EDID read from the sink. This - * is useful to parse sink identification information like vendor, model - * and serial. Drivers should update this property by calling - * 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 (because the kernel might apply limits, quirks or - * fixups to the EDID). For instance, user-space should not try to parse - * mode lists from the EDID. + * Blob property which contains the current EDID read from the sink. This + * is useful to parse sink identification information like vendor, model + * and serial. Drivers should update this property by calling + * 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 (because the kernel might apply limits, quirks or + * fixups to the EDID). For instance, user-space should not try to parse + * mode lists from the EDID. * DPMS: - * Legacy property for setting the power state of the connector. For atomic - * drivers this is only provided for backwards compatibility with existing - * drivers, it remaps to controlling the "ACTIVE" property on the CRTC the - * connector is linked to. Drivers should never set this property directly, - * it is handled by the DRM core by calling the &drm_connector_funcs.dpms - * callback. For atomic drivers the remapping to the "ACTIVE" property is - * implemented in the DRM core. - * - * Note that this property cannot be set through the MODE_ATOMIC ioctl, - * userspace must use "ACTIVE" on the CRTC instead. - * - * WARNING: - * - * For userspace also running on legacy drivers the "DPMS" semantics are a - * lot more complicated. First, userspace cannot rely on the "DPMS" value - * returned by the GETCONNECTOR actually reflecting reality, because many - * drivers fail to update it. For atomic drivers this is taken care of in - * drm_atomic_helper_update_legacy_modeset_state(). - * - * The second issue is that the DPMS state is only well-defined when the - * connector is connected to a CRTC. In atomic the DRM core enforces that - * "ACTIVE" is off in such a case, no such checks exists for "DPMS". - * - * Finally, when enabling an output using the legacy SETCONFIG ioctl then - * "DPMS" is forced to ON. But see above, that might not be reflected in - * the software value on legacy drivers. - * - * Summarizing: Only set "DPMS" when the connector is known to be enabled, - * assume that a successful SETCONFIG call also sets "DPMS" to on, and - * never read back the value of "DPMS" because it can be incorrect. + * Legacy property for setting the power state of the connector. For atomic + * drivers this is only provided for backwards compatibility with existing + * drivers, it remaps to controlling the "ACTIVE" property on the CRTC the + * connector is linked to. Drivers should never set this property directly, + * it is handled by the DRM core by calling the &drm_connector_funcs.dpms + * callback. For atomic drivers the remapping to the "ACTIVE" property is + * implemented in the DRM core. + * + * Note that this property cannot be set through the MODE_ATOMIC ioctl, + * userspace must use "ACTIVE" on the CRTC instead. + * + * WARNING: + * + * For userspace also running on legacy drivers the "DPMS" semantics are a + * lot more complicated. First, userspace cannot rely on the "DPMS" value + * returned by the GETCONNECTOR actually reflecting reality, because many + * drivers fail to update it. For atomic drivers this is taken care of in + * drm_atomic_helper_update_legacy_modeset_state(). + * + * The second issue is that the DPMS state is only well-defined when the + * connector is connected to a CRTC. In atomic the DRM core enforces that + * "ACTIVE" is off in such a case, no such checks exists for "DPMS". + * + * Finally, when enabling an output using the legacy SETCONFIG ioctl then + * "DPMS" is forced to ON. But see above, that might not be reflected in + * the software value on legacy drivers. + * + * Summarizing: Only set "DPMS" when the connector is known to be enabled, + * assume that a successful SETCONFIG call also sets "DPMS" to on, and + * never read back the value of "DPMS" because it can be incorrect. * PATH: - * Connector path property to identify how this sink is physically - * connected. Used by DP MST. This should be set by calling - * drm_connector_set_path_property(), in the case of DP MST with the - * path property the MST manager created. Userspace cannot change this - * property. - * - * In the case of DP MST, the property has the format - * ``mst:<parent>-<ports>`` where ``<parent>`` is the KMS object ID of the - * parent connector and ``<ports>`` is a hyphen-separated list of DP MST - * port numbers. Note, KMS object IDs are not guaranteed to be stable - * across reboots. + * Connector path property to identify how this sink is physically + * connected. Used by DP MST. This should be set by calling + * drm_connector_set_path_property(), in the case of DP MST with the + * path property the MST manager created. Userspace cannot change this + * property. + * + * In the case of DP MST, the property has the format + * ``mst:<parent>-<ports>`` where ``<parent>`` is the KMS object ID of the + * parent connector and ``<ports>`` is a hyphen-separated list of DP MST + * port numbers. Note, KMS object IDs are not guaranteed to be stable + * across reboots. * TILE: - * Connector tile group property to indicate how a set of DRM connector - * compose together into one logical screen. This is used by both high-res - * external screens (often only using a single cable, but exposing multiple - * DP MST sinks), or high-res integrated panels (like dual-link DSI) which - * are not gen-locked. Note that for tiled panels which are genlocked, like - * dual-link LVDS or dual-link DSI, the driver should try to not expose the - * tiling and virtualise both &drm_crtc and &drm_plane if needed. Drivers - * should update this value using drm_connector_set_tile_property(). - * Userspace cannot change this property. + * Connector tile group property to indicate how a set of DRM connector + * compose together into one logical screen. This is used by both high-res + * external screens (often only using a single cable, but exposing multiple + * DP MST sinks), or high-res integrated panels (like dual-link DSI) which + * are not gen-locked. Note that for tiled panels which are genlocked, like + * dual-link LVDS or dual-link DSI, the driver should try to not expose the + * tiling and virtualise both &drm_crtc and &drm_plane if needed. Drivers + * should update this value using drm_connector_set_tile_property(). + * Userspace cannot change this property. * link-status: * Connector link-status property to indicate the status of link. The * default value of link-status is "GOOD". If something fails during or @@ -1247,258 +1247,258 @@ static const u32 dp_colorspaces = * to how it might fail if a different screen has been connected in the * interim. * non_desktop: - * Indicates the output should be ignored for purposes of displaying a - * standard desktop environment or console. This is most likely because - * the output device is not rectilinear. + * Indicates the output should be ignored for purposes of displaying a + * standard desktop environment or console. This is most likely because + * the output device is not rectilinear. * Content Protection: - * This property is used by userspace to request the kernel protect future - * content communicated over the link. When requested, kernel will apply - * the appropriate means of protection (most often HDCP), and use the - * property to tell userspace the protection is active. - * - * Drivers can set this up by calling - * drm_connector_attach_content_protection_property() on initialization. - * - * The value of this property can be one of the following: - * - * DRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0 - * The link is not protected, content is transmitted in the clear. - * DRM_MODE_CONTENT_PROTECTION_DESIRED = 1 - * Userspace has requested content protection, but the link is not - * currently protected. When in this state, kernel should enable - * Content Protection as soon as possible. - * DRM_MODE_CONTENT_PROTECTION_ENABLED = 2 - * Userspace has requested content protection, and the link is - * protected. Only the driver can set the property to this value. - * If userspace attempts to set to ENABLED, kernel will return - * -EINVAL. - * - * A few guidelines: - * - * - DESIRED state should be preserved until userspace de-asserts it by - * setting the property to UNDESIRED. This means ENABLED should only - * transition to UNDESIRED when the user explicitly requests it. - * - If the state is DESIRED, kernel should attempt to re-authenticate the - * link whenever possible. This includes across disable/enable, dpms, - * hotplug, downstream device changes, link status failures, etc.. - * - Kernel sends uevent with the connector id and property id through - * @drm_hdcp_update_content_protection, upon below kernel triggered - * scenarios: - * - * - DESIRED -> ENABLED (authentication success) - * - ENABLED -> DESIRED (termination of authentication) - * - Please note no uevents for userspace triggered property state changes, - * which can't fail such as - * - * - DESIRED/ENABLED -> UNDESIRED - * - UNDESIRED -> DESIRED - * - Userspace is responsible for polling the property or listen to uevents - * to determine when the value transitions from ENABLED to DESIRED. - * This signifies the link is no longer protected and userspace should - * take appropriate action (whatever that might be). + * This property is used by userspace to request the kernel protect future + * content communicated over the link. When requested, kernel will apply + * the appropriate means of protection (most often HDCP), and use the + * property to tell userspace the protection is active. + * + * Drivers can set this up by calling + * drm_connector_attach_content_protection_property() on initialization. + * + * The value of this property can be one of the following: + * + * DRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0 + * The link is not protected, content is transmitted in the clear. + * DRM_MODE_CONTENT_PROTECTION_DESIRED = 1 + * Userspace has requested content protection, but the link is not + * currently protected. When in this state, kernel should enable + * Content Protection as soon as possible. + * DRM_MODE_CONTENT_PROTECTION_ENABLED = 2 + * Userspace has requested content protection, and the link is + * protected. Only the driver can set the property to this value. + * If userspace attempts to set to ENABLED, kernel will return + * -EINVAL. + * + * A few guidelines: + * + * - DESIRED state should be preserved until userspace de-asserts it by + * setting the property to UNDESIRED. This means ENABLED should only + * transition to UNDESIRED when the user explicitly requests it. + * - If the state is DESIRED, kernel should attempt to re-authenticate the + * link whenever possible. This includes across disable/enable, dpms, + * hotplug, downstream device changes, link status failures, etc.. + * - Kernel sends uevent with the connector id and property id through + * @drm_hdcp_update_content_protection, upon below kernel triggered + * scenarios: + * + * - DESIRED -> ENABLED (authentication success) + * - ENABLED -> DESIRED (termination of authentication) + * - Please note no uevents for userspace triggered property state changes, + * which can't fail such as + * + * - DESIRED/ENABLED -> UNDESIRED + * - UNDESIRED -> DESIRED + * - Userspace is responsible for polling the property or listen to uevents + * to determine when the value transitions from ENABLED to DESIRED. + * This signifies the link is no longer protected and userspace should + * take appropriate action (whatever that might be). * * HDCP Content Type: - * This Enum property is used by the userspace to declare the content type - * of the display stream, to kernel. Here display stream stands for any - * display content that userspace intended to display through HDCP - * encryption. - * - * Content Type of a stream is decided by the owner of the stream, as - * "HDCP Type0" or "HDCP Type1". - * - * The value of the property can be one of the below: - * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0 - * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1 - * - * When kernel starts the HDCP authentication (see "Content Protection" - * for details), it uses the content type in "HDCP Content Type" - * for performing the HDCP authentication with the display sink. - * - * Please note in HDCP spec versions, a link can be authenticated with - * HDCP 2.2 for Content Type 0/Content Type 1. Where as a link can be - * authenticated with HDCP1.4 only for Content Type 0(though it is implicit - * in nature. As there is no reference for Content Type in HDCP1.4). - * - * HDCP2.2 authentication protocol itself takes the "Content Type" as a - * parameter, which is a input for the DP HDCP2.2 encryption algo. - * - * In case of Type 0 content protection request, kernel driver can choose - * either of HDCP spec versions 1.4 and 2.2. When HDCP2.2 is used for - * "HDCP Type 0", a HDCP 2.2 capable repeater in the downstream can send - * that content to a HDCP 1.4 authenticated HDCP sink (Type0 link). - * But if the content is classified as "HDCP Type 1", above mentioned - * HDCP 2.2 repeater wont send the content to the HDCP sink as it can't - * authenticate the HDCP1.4 capable sink for "HDCP Type 1". - * - * Please note userspace can be ignorant of the HDCP versions used by the - * kernel driver to achieve the "HDCP Content Type". - * - * At current scenario, classifying a content as Type 1 ensures that the - * content will be displayed only through the HDCP2.2 encrypted link. - * - * Note that the HDCP Content Type property is introduced at HDCP 2.2, and - * defaults to type 0. It is only exposed by drivers supporting HDCP 2.2 - * (hence supporting Type 0 and Type 1). Based on how next versions of - * HDCP specs are defined content Type could be used for higher versions - * too. - * - * If content type is changed when "Content Protection" is not UNDESIRED, - * then kernel will disable the HDCP and re-enable with new type in the - * same atomic commit. And when "Content Protection" is ENABLED, it means - * that link is HDCP authenticated and encrypted, for the transmission of - * the Type of stream mentioned at "HDCP Content Type". + * This Enum property is used by the userspace to declare the content type + * of the display stream, to kernel. Here display stream stands for any + * display content that userspace intended to display through HDCP + * encryption. + * + * Content Type of a stream is decided by the owner of the stream, as + * "HDCP Type0" or "HDCP Type1". + * + * The value of the property can be one of the below: + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0 + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1 + * + * When kernel starts the HDCP authentication (see "Content Protection" + * for details), it uses the content type in "HDCP Content Type" + * for performing the HDCP authentication with the display sink. + * + * Please note in HDCP spec versions, a link can be authenticated with + * HDCP 2.2 for Content Type 0/Content Type 1. Where as a link can be + * authenticated with HDCP1.4 only for Content Type 0(though it is implicit + * in nature. As there is no reference for Content Type in HDCP1.4). + * + * HDCP2.2 authentication protocol itself takes the "Content Type" as a + * parameter, which is a input for the DP HDCP2.2 encryption algo. + * + * In case of Type 0 content protection request, kernel driver can choose + * either of HDCP spec versions 1.4 and 2.2. When HDCP2.2 is used for + * "HDCP Type 0", a HDCP 2.2 capable repeater in the downstream can send + * that content to a HDCP 1.4 authenticated HDCP sink (Type0 link). + * But if the content is classified as "HDCP Type 1", above mentioned + * HDCP 2.2 repeater wont send the content to the HDCP sink as it can't + * authenticate the HDCP1.4 capable sink for "HDCP Type 1". + * + * Please note userspace can be ignorant of the HDCP versions used by the + * kernel driver to achieve the "HDCP Content Type". + * + * At current scenario, classifying a content as Type 1 ensures that the + * content will be displayed only through the HDCP2.2 encrypted link. + * + * Note that the HDCP Content Type property is introduced at HDCP 2.2, and + * defaults to type 0. It is only exposed by drivers supporting HDCP 2.2 + * (hence supporting Type 0 and Type 1). Based on how next versions of + * HDCP specs are defined content Type could be used for higher versions + * too. + * + * If content type is changed when "Content Protection" is not UNDESIRED, + * then kernel will disable the HDCP and re-enable with new type in the + * same atomic commit. And when "Content Protection" is ENABLED, it means + * that link is HDCP authenticated and encrypted, for the transmission of + * the Type of stream mentioned at "HDCP Content Type". * * HDR_OUTPUT_METADATA: - * Connector property to enable userspace to send HDR Metadata to - * driver. This metadata is based on the composition and blending - * policies decided by user, taking into account the hardware and - * sink capabilities. The driver gets this metadata and creates a - * Dynamic Range and Mastering Infoframe (DRM) in case of HDMI, - * SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then - * sent to sink. This notifies the sink of the upcoming frame's Color - * Encoding and Luminance parameters. - * - * Userspace first need to detect the HDR capabilities of sink by - * reading and parsing the EDID. Details of HDR metadata for HDMI - * are added in CTA 861.G spec. For DP , its defined in VESA DP - * Standard v1.4. It needs to then get the metadata information - * of the video/game/app content which are encoded in HDR (basically - * using HDR transfer functions). With this information it needs to - * decide on a blending policy and compose the relevant - * layers/overlays into a common format. Once this blending is done, - * userspace will be aware of the metadata of the composed frame to - * be send to sink. It then uses this property to communicate this - * metadata to driver which then make a Infoframe packet and sends - * to sink based on the type of encoder connected. - * - * Userspace will be responsible to do Tone mapping operation in case: - * - Some layers are HDR and others are SDR - * - HDR layers luminance is not same as sink - * - * It will even need to do colorspace conversion and get all layers - * to one common colorspace for blending. It can use either GL, Media - * or display engine to get this done based on the capabilities of the - * associated hardware. - * - * Driver expects metadata to be put in &struct hdr_output_metadata - * structure from userspace. This is received as blob and stored in - * &drm_connector_state.hdr_output_metadata. It parses EDID and saves the - * sink metadata in &struct hdr_sink_metadata, as - * &drm_connector.hdr_sink_metadata. Driver uses - * drm_hdmi_infoframe_set_hdr_metadata() helper to set the HDR metadata, - * hdmi_drm_infoframe_pack() to pack the infoframe as per spec, in case of - * HDMI encoder. + * Connector property to enable userspace to send HDR Metadata to + * driver. This metadata is based on the composition and blending + * policies decided by user, taking into account the hardware and + * sink capabilities. The driver gets this metadata and creates a + * Dynamic Range and Mastering Infoframe (DRM) in case of HDMI, + * SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then + * sent to sink. This notifies the sink of the upcoming frame's Color + * Encoding and Luminance parameters. + * + * Userspace first need to detect the HDR capabilities of sink by + * reading and parsing the EDID. Details of HDR metadata for HDMI + * are added in CTA 861.G spec. For DP , its defined in VESA DP + * Standard v1.4. It needs to then get the metadata information + * of the video/game/app content which are encoded in HDR (basically + * using HDR transfer functions). With this information it needs to + * decide on a blending policy and compose the relevant + * layers/overlays into a common format. Once this blending is done, + * userspace will be aware of the metadata of the composed frame to + * be send to sink. It then uses this property to communicate this + * metadata to driver which then make a Infoframe packet and sends + * to sink based on the type of encoder connected. + * + * Userspace will be responsible to do Tone mapping operation in case: + * - Some layers are HDR and others are SDR + * - HDR layers luminance is not same as sink + * + * It will even need to do colorspace conversion and get all layers + * to one common colorspace for blending. It can use either GL, Media + * or display engine to get this done based on the capabilities of the + * associated hardware. + * + * Driver expects metadata to be put in &struct hdr_output_metadata + * structure from userspace. This is received as blob and stored in + * &drm_connector_state.hdr_output_metadata. It parses EDID and saves the + * sink metadata in &struct hdr_sink_metadata, as + * &drm_connector.hdr_sink_metadata. Driver uses + * drm_hdmi_infoframe_set_hdr_metadata() helper to set the HDR metadata, + * hdmi_drm_infoframe_pack() to pack the infoframe as per spec, in case of + * HDMI encoder. * * max bpc: - * This range property is used by userspace to limit the bit depth. When - * used the driver would limit the bpc in accordance with the valid range - * supported by the hardware and sink. Drivers to use the function - * drm_connector_attach_max_bpc_property() to create and attach the - * property to the connector during initialization. + * This range property is used by userspace to limit the bit depth. When + * used the driver would limit the bpc in accordance with the valid range + * supported by the hardware and sink. Drivers to use the function + * drm_connector_attach_max_bpc_property() to create and attach the + * property to the connector during initialization. * * Connectors also have one standardized atomic property: * * CRTC_ID: - * Mode object ID of the &drm_crtc this connector should be connected to. + * Mode object ID of the &drm_crtc this connector should be connected to. * * Connectors for LCD panels may also have one standardized property: * * panel orientation: - * On some devices the LCD panel is mounted in the casing in such a way - * that the up/top side of the panel does not match with the top side of - * the device. Userspace can use this property to check for this. - * Note that input coordinates from touchscreens (input devices with - * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel - * coordinates, so if userspace rotates the picture to adjust for - * the orientation it must also apply the same transformation to the - * touchscreen input coordinates. This property is initialized by calling - * drm_connector_set_panel_orientation() or - * drm_connector_set_panel_orientation_with_quirk() + * On some devices the LCD panel is mounted in the casing in such a way + * that the up/top side of the panel does not match with the top side of + * the device. Userspace can use this property to check for this. + * Note that input coordinates from touchscreens (input devices with + * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel + * coordinates, so if userspace rotates the picture to adjust for + * the orientation it must also apply the same transformation to the + * touchscreen input coordinates. This property is initialized by calling + * drm_connector_set_panel_orientation() or + * drm_connector_set_panel_orientation_with_quirk() * * scaling mode: - * This property defines how a non-native mode is upscaled to the native - * mode of an LCD panel: - * - * None: - * No upscaling happens, scaling is left to the panel. Not all - * drivers expose this mode. - * Full: - * The output is upscaled to the full resolution of the panel, - * ignoring the aspect ratio. - * Center: - * No upscaling happens, the output is centered within the native - * resolution the panel. - * Full aspect: - * The output is upscaled to maximize either the width or height - * while retaining the aspect ratio. - * - * This property should be set up by calling - * drm_connector_attach_scaling_mode_property(). Note that drivers - * can also expose this property to external outputs, in which case they - * must support "None", which should be the default (since external screens - * have a built-in scaler). + * This property defines how a non-native mode is upscaled to the native + * mode of an LCD panel: + * + * None: + * No upscaling happens, scaling is left to the panel. Not all + * drivers expose this mode. + * Full: + * The output is upscaled to the full resolution of the panel, + * ignoring the aspect ratio. + * Center: + * No upscaling happens, the output is centered within the native + * resolution the panel. + * Full aspect: + * The output is upscaled to maximize either the width or height + * while retaining the aspect ratio. + * + * This property should be set up by calling + * drm_connector_attach_scaling_mode_property(). Note that drivers + * can also expose this property to external outputs, in which case they + * must support "None", which should be the default (since external screens + * have a built-in scaler). * * subconnector: - * This property is used by DVI-I, TVout and DisplayPort to indicate different - * connector subtypes. Enum values more or less match with those from main - * connector types. - * For DVI-I and TVout there is also a matching property "select subconnector" - * allowing to switch between signal types. - * DP subconnector corresponds to a downstream port. + * This property is used by DVI-I, TVout and DisplayPort to indicate different + * connector subtypes. Enum values more or less match with those from main + * connector types. + * For DVI-I and TVout there is also a matching property "select subconnector" + * allowing to switch between signal types. + * DP subconnector corresponds to a downstream port. * * privacy-screen sw-state, privacy-screen hw-state: - * These 2 optional properties can be used to query the state of the - * electronic privacy screen that is available on some displays; and in - * some cases also control the state. If a driver implements these - * properties then both properties must be present. - * - * "privacy-screen hw-state" is read-only and reflects the actual state - * of the privacy-screen, possible values: "Enabled", "Disabled, - * "Enabled-locked", "Disabled-locked". The locked states indicate - * that the state cannot be changed through the DRM API. E.g. there - * might be devices where the firmware-setup options, or a hardware - * slider-switch, offer always on / off modes. - * - * "privacy-screen sw-state" can be set to change the privacy-screen state - * when not locked. In this case the driver must update the hw-state - * property to reflect the new state on completion of the commit of the - * sw-state property. Setting the sw-state property when the hw-state is - * locked must be interpreted by the driver as a request to change the - * state to the set state when the hw-state becomes unlocked. E.g. if - * "privacy-screen hw-state" is "Enabled-locked" and the sw-state - * gets set to "Disabled" followed by the user unlocking the state by - * changing the slider-switch position, then the driver must set the - * state to "Disabled" upon receiving the unlock event. - * - * In some cases the privacy-screen's actual state might change outside of - * control of the DRM code. E.g. there might be a firmware handled hotkey - * which toggles the actual state, or the actual state might be changed - * through another userspace API such as writing /proc/acpi/ibm/lcdshadow. - * In this case the driver must update both the hw-state and the sw-state - * to reflect the new value, overwriting any pending state requests in the - * sw-state. Any pending sw-state requests are thus discarded. - * - * Note that the ability for the state to change outside of control of - * the DRM master process means that userspace must not cache the value - * of the sw-state. Caching the sw-state value and including it in later - * atomic commits may lead to overriding a state change done through e.g. - * a firmware handled hotkey. Therefor userspace must not include the - * privacy-screen sw-state in an atomic commit unless it wants to change - * its value. + * These 2 optional properties can be used to query the state of the + * electronic privacy screen that is available on some displays; and in + * some cases also control the state. If a driver implements these + * properties then both properties must be present. + * + * "privacy-screen hw-state" is read-only and reflects the actual state + * of the privacy-screen, possible values: "Enabled", "Disabled, + * "Enabled-locked", "Disabled-locked". The locked states indicate + * that the state cannot be changed through the DRM API. E.g. there + * might be devices where the firmware-setup options, or a hardware + * slider-switch, offer always on / off modes. + * + * "privacy-screen sw-state" can be set to change the privacy-screen state + * when not locked. In this case the driver must update the hw-state + * property to reflect the new state on completion of the commit of the + * sw-state property. Setting the sw-state property when the hw-state is + * locked must be interpreted by the driver as a request to change the + * state to the set state when the hw-state becomes unlocked. E.g. if + * "privacy-screen hw-state" is "Enabled-locked" and the sw-state + * gets set to "Disabled" followed by the user unlocking the state by + * changing the slider-switch position, then the driver must set the + * state to "Disabled" upon receiving the unlock event. + * + * In some cases the privacy-screen's actual state might change outside of + * control of the DRM code. E.g. there might be a firmware handled hotkey + * which toggles the actual state, or the actual state might be changed + * through another userspace API such as writing /proc/acpi/ibm/lcdshadow. + * In this case the driver must update both the hw-state and the sw-state + * to reflect the new value, overwriting any pending state requests in the + * sw-state. Any pending sw-state requests are thus discarded. + * + * Note that the ability for the state to change outside of control of + * the DRM master process means that userspace must not cache the value + * of the sw-state. Caching the sw-state value and including it in later + * atomic commits may lead to overriding a state change done through e.g. + * a firmware handled hotkey. Therefor userspace must not include the + * privacy-screen sw-state in an atomic commit unless it wants to change + * its value. * * left margin, right margin, top margin, bottom margin: - * Add margins to the connector's viewport. This is typically used to - * mitigate overscan on TVs. + * Add margins to the connector's viewport. This is typically used to + * mitigate overscan on TVs. * - * The value is the size in pixels of the black border which will be - * added. The attached CRTC's content will be scaled to fill the whole - * area inside the margin. + * The value is the size in pixels of the black border which will be + * added. The attached CRTC's content will be scaled to fill the whole + * area inside the margin. * - * The margins configuration might be sent to the sink, e.g. via HDMI AVI - * InfoFrames. + * The margins configuration might be sent to the sink, e.g. via HDMI AVI + * InfoFrames. * - * Drivers can set up these properties by calling - * drm_mode_create_tv_margin_properties(). + * Drivers can set up these properties by calling + * drm_mode_create_tv_margin_properties(). */ int drm_connector_create_standard_properties(struct drm_device *dev) @@ -1617,28 +1617,28 @@ EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property); * DOC: HDMI connector properties * * content type (HDMI specific): - * Indicates content type setting to be used in HDMI infoframes to indicate - * content type for the external device, so that it adjusts its display - * settings accordingly. + * Indicates content type setting to be used in HDMI infoframes to indicate + * content type for the external device, so that it adjusts its display + * settings accordingly. * - * The value of this property can be one of the following: + * The value of this property can be one of the following: * - * No Data: - * Content type is unknown - * Graphics: - * Content type is graphics - * Photo: - * Content type is photo - * Cinema: - * Content type is cinema - * Game: - * Content type is game + * No Data: + * Content type is unknown + * Graphics: + * Content type is graphics + * Photo: + * Content type is photo + * Cinema: + * Content type is cinema + * Game: + * Content type is game * - * The meaning of each content type is defined in CTA-861-G table 15. + * The meaning of each content type is defined in CTA-861-G table 15. * - * Drivers can set up this property by calling - * drm_connector_attach_content_type_property(). Decoding to - * infoframe values is done through drm_hdmi_avi_infoframe_content_type(). + * Drivers can set up this property by calling + * drm_connector_attach_content_type_property(). Decoding to + * infoframe values is done through drm_hdmi_avi_infoframe_content_type(). */ /* @@ -1656,49 +1656,49 @@ EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property); * DOC: Analog TV Connector Properties * * TV Mode: - * Indicates the TV Mode used on an analog TV connector. The value - * of this property can be one of the following: + * Indicates the TV Mode used on an analog TV connector. The value + * of this property can be one of the following: * - * NTSC: - * TV Mode is CCIR System M (aka 525-lines) together with - * the NTSC Color Encoding. + * NTSC: + * TV Mode is CCIR System M (aka 525-lines) together with + * the NTSC Color Encoding. * - * NTSC-443: + * NTSC-443: * - * TV Mode is CCIR System M (aka 525-lines) together with - * the NTSC Color Encoding, but with a color subcarrier - * frequency of 4.43MHz + * TV Mode is CCIR System M (aka 525-lines) together with + * the NTSC Color Encoding, but with a color subcarrier + * frequency of 4.43MHz * - * NTSC-J: + * NTSC-J: * - * TV Mode is CCIR System M (aka 525-lines) together with - * the NTSC Color Encoding, but with a black level equal to - * the blanking level. + * TV Mode is CCIR System M (aka 525-lines) together with + * the NTSC Color Encoding, but with a black level equal to + * the blanking level. * - * PAL: + * PAL: * - * TV Mode is CCIR System B (aka 625-lines) together with - * the PAL Color Encoding. + * TV Mode is CCIR System B (aka 625-lines) together with + * the PAL Color Encoding. * - * PAL-M: + * PAL-M: * - * TV Mode is CCIR System M (aka 525-lines) together with - * the PAL Color Encoding. + * TV Mode is CCIR System M (aka 525-lines) together with + * the PAL Color Encoding. * - * PAL-N: + * PAL-N: * - * TV Mode is CCIR System N together with the PAL Color - * Encoding, a color subcarrier frequency of 3.58MHz, the - * SECAM color space, and narrower channels than other PAL - * variants. + * TV Mode is CCIR System N together with the PAL Color + * Encoding, a color subcarrier frequency of 3.58MHz, the + * SECAM color space, and narrower channels than other PAL + * variants. * - * SECAM: + * SECAM: * - * TV Mode is CCIR System B (aka 625-lines) together with - * the SECAM Color Encoding. + * TV Mode is CCIR System B (aka 625-lines) together with + * the SECAM Color Encoding. * - * Drivers can set up this property by calling - * drm_mode_create_tv_properties(). + * Drivers can set up this property by calling + * drm_mode_create_tv_properties(). */ /** @@ -1721,7 +1721,7 @@ EXPORT_SYMBOL(drm_connector_attach_content_type_property); /** * drm_connector_attach_tv_margin_properties - attach TV connector margin - * properties + * properties * @connector: DRM connector * * Called by a driver when it needs to attach TV margin props to a connector. @@ -1998,31 +1998,31 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); * on the &drm_connector and &drm_crtc objects. * * "vrr_capable": - * Optional &drm_connector boolean property that drivers should attach - * with drm_connector_attach_vrr_capable_property() on connectors that - * could support variable refresh rates. Drivers should update the - * property value by calling drm_connector_set_vrr_capable_property(). + * Optional &drm_connector boolean property that drivers should attach + * with drm_connector_attach_vrr_capable_property() on connectors that + * could support variable refresh rates. Drivers should update the + * property value by calling drm_connector_set_vrr_capable_property(). * - * Absence of the property should indicate absence of support. + * Absence of the property should indicate absence of support. * * "VRR_ENABLED": - * Default &drm_crtc boolean property that notifies the driver that the - * content on the CRTC is suitable for variable refresh rate presentation. - * The driver will take this property as a hint to enable variable - * refresh rate support if the receiver supports it, ie. if the - * "vrr_capable" property is true on the &drm_connector object. The - * vertical front porch duration will be extended until page-flip or - * timeout when enabled. + * Default &drm_crtc boolean property that notifies the driver that the + * content on the CRTC is suitable for variable refresh rate presentation. + * The driver will take this property as a hint to enable variable + * refresh rate support if the receiver supports it, ie. if the + * "vrr_capable" property is true on the &drm_connector object. The + * vertical front porch duration will be extended until page-flip or + * timeout when enabled. * - * The minimum vertical front porch duration is defined as the vertical - * front porch duration for the current mode. + * The minimum vertical front porch duration is defined as the vertical + * front porch duration for the current mode. * - * The maximum vertical front porch duration is greater than or equal to - * the minimum vertical front porch duration. The duration is derived - * from the minimum supported variable refresh rate for the connector. + * The maximum vertical front porch duration is greater than or equal to + * the minimum vertical front porch duration. The duration is derived + * from the minimum supported variable refresh rate for the connector. * - * The driver may place further restrictions within these minimum - * and maximum bounds. + * The driver may place further restrictions within these minimum + * and maximum bounds. */ /** @@ -2606,7 +2606,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation); /** * drm_connector_set_panel_orientation_with_quirk - set the - * connector's panel_orientation after checking for quirks + * connector's panel_orientation after checking for quirks * @connector: connector for which to init the panel-orientation property. * @panel_orientation: drm_panel_orientation value to set * @width: width in pixels of the panel, used for panel quirk detection @@ -2636,7 +2636,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk); /** * drm_connector_set_orientation_from_panel - - * set the connector's panel_orientation from panel's callback. + * set the connector's panel_orientation from panel's callback. * @connector: connector for which to init the panel-orientation property. * @panel: panel that can provide orientation information. * -- 2.42.0
