* [PATCH 4/4] gpu/drm: Replace tabs with spaces in comments
2024-04-02 22:43 [PATCH 0/4] gpu/drm: Fix checkpatch warnings in drm_connector.c Nicolas Devos
` (2 preceding siblings ...)
2024-04-02 22:43 ` [PATCH 3/4] gpu/drm: Prefer `unsigned int` over `unsigned` Nicolas Devos
@ 2024-04-02 22:43 ` Nicolas Devos
3 siblings, 0 replies; 6+ messages in thread
From: Nicolas Devos @ 2024-04-02 22:43 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, dri-devel, linux-kernel
Cc: Nicolas Devos
This commit fixes following warnings found by checkpatch:
WARNING: please, no space before tabs
Signed-off-by: Nicolas Devos <ndevos-dev@pm.me>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread