linux.git/drivers/gpu/drm/drm_blend.c, branch v5.8

drm: plane: Verify that no or all planes have a zpos property

2020-05-13T23:10:52+00:00

The zpos property is used by userspace to sort the order of planes.
While the property is not mandatory for drivers to implement, mixing
planes with and without zpos confuses userspace, and shall not be
allowed. Clarify this in the documentation and warn at runtime if the
drivers mixes planes with and without zpos properties.

Signed-off-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Daniel Vetter

drm: add docs about the IN_FORMATS plane property

2020-03-31T09:12:42+00:00

This is a standard property attached to planes in drm_universal_plane_init
when drm_mode_config.allow_fb_modifiers is true.

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/mHOtz80Wa-x3A5Lz5ETTM65VUMfW1j6b-iCuvIy1RzOM1EloHPqAb2MnbU8ygZi0ABaLrxuN6pzu0v3QRn83125C0bXuHoo-DQWWEd80fdw=@emersion.fr

drm: two planes with the same zpos have undefined ordering

2019-10-09T18:04:55+00:00

Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.

The unspoken, legacy rule used in the past was to make user-space figure
out the zpos from object IDs. However some drivers break this rule,
that's why the ordering is documented as unspecified in case the zpos
property is missing. User-space should rely on the zpos property only.

There are some cases in which user-space might read identical zpos
values for different planes.

For instance, in case the property is mutable, user-space might set two
planes' zpos to the same value. This is necessary to support user-space
using the legacy DRM API where atomic commits are not possible:
user-space needs to update the planes' zpos one by one.

Because of this, user-space should handle multiple planes with the same
zpos.

While at it, remove the assumption that zpos is only for overlay planes.

Additionally, update the drm_plane_state.zpos docs to clarify that zpos
disambiguation via plane object IDs is a recommendation for drivers, not
something user-space can rely on. In other words, when user-space sets
the same zpos on two planes, drivers should rely on the plane object ID.

v2: clarify drm_plane_state.zpos docs (Daniel)

v3: zpos is for all planes (Marius, Daniel)

v4: completely reword the drm_plane_state.zpos docs to make it clear the
recommendation to use plane IDs is for drivers in case user-space uses
duplicate zpos values (Pekka)

v5: reword commit message (Pekka, James)

v6: remove mention of Arm GPUs having planes which can't overlap,
because this isn't uAPI yet (Daniel)

Signed-off-by: Simon Ser 
Reviewed-by: Pekka Paalanen 
Cc: Marius Vlad 
Cc: Daniel Vetter 
Cc: James Qian Wang 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr

drm/blend: Define the direction of Z position values

2019-09-06T18:23:21+00:00

We forgot that.

Proof is the one igt testcase we have:

https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280

While at it also document that we have immutable zpos properties in
some cases.

Reported-by: Pekka Paalanen 
Cc: Pekka Paalanen 
Reviewed-by: Pekka Paalanen 
Cc: Ilia Mirkin 
Acked-by: Ilia Mirkin 
Reviewed-by: Daniel Stone 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20190906144459.16025-1-daniel.vetter@ffwll.ch

drm: drop use of drmP.h in drm/*

2019-05-27T16:07:03+00:00

The use of the drmP.h header file is deprecated.
Remove use from all files in drm/*
so people do not look there and follow a bad example.

Build tested allyesconfig,allmodconfig on x86, arm etc.
Including alpha that is as always more challenging than
the rest.

Signed-off-by: Sam Ravnborg 
Acked-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org

drm: Clarify DRM_MODE_REFLECT_X/Y documentation

2018-09-11T10:21:30+00:00

DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
to me, so try to clarify that with a bit of ascii graphics.

Changes since v1:
  - Move the ascii graphics in the kerneldoc where all plane
    properties are already documented and make sure it's properly
    rendered, suggestested by Daniel Vetter.

Signed-off-by: Alexandru Gheorghe 
Reviewed-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20180910172946.18539-1-alexandru-cosmin.gheorghe@arm.com

drm: Add per-plane pixel blend mode property

2018-08-24T16:31:37+00:00

Pixel blend modes represent the alpha blending equation
selection, describing how the pixels from the current
plane are composited with the background.

Adds a pixel_blend_mode to drm_plane_state and a
blend_mode_property to drm_plane, and related support
functions.

Defines three blend modes in drm_blend.h.

Changes since v1:
 - Moves the blending equation into the DOC comment
 - Refines the comments of drm_plane_create_blend_mode_property to not
   enumerate the #defines, but instead the string values
 - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
Changes since v2:
 - Refines the comments of drm_plane_create_blend_mode_property:
      1) Puts the descriptions (after the ":") on a new line
      2) Adds explaining why @supported_modes need PREMUL as default
Changes since v3:
 - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
   can calculate the index itself just fine, so no point in having the
   caller pass it in.
 - Since the current DRM assumption is that alpha is premultiplied
   as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
 - Refines some comments.
Changes since v4:
 - Adds comments in drm_blend.h.
 - Removes setting default value in drm_plane_create_blend_mode_property()
   as it is already in __drm_atomic_helper_plane_reset().
 - Fixes to use state->pixel_blend_mode instead of using
   plane->state->pixel_blend_mode in reset function.
 - Rebases on drm-misc-next.

Reviewed-by: Liviu Dudau 
Signed-off-by: Lowry Li 
Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/245734/

drm/blend: Add a generic alpha property

2018-04-16T19:17:29+00:00

Some drivers duplicate the logic to create a property to store a per-plane
alpha.

This is especially useful if we ever want to support extra protocols for
Wayland like:
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html

Let's create a helper in order to move that to the core.

Acked-by: Maarten Lankhorst 
Acked-by: Sean Paul 
Reviewed-by: Boris Brezillon 
Reviewed-by: Eric Anholt 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/6e1ce0db78fcfc407e94913c64819e65109d034d.1523432341.git-series.maxime.ripard@bootlin.com

drm/docs: Align layout of optional plane blending properties

2018-02-20T11:10:46+00:00

Just a bit of drive-by OCD. All the other property docs use enumerations,
for some nice visual consistency. It also neatly highlights the property
name.

Reviewed-by: Thierry Reding 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-2-daniel.vetter@ffwll.ch

drm/atomic-helper: Make zpos property kerneldoc less misleading

2017-12-14T13:20:35+00:00

kerneldoc for drm_plane_create_zpos_property() says that the DRM core
will automatically calculate the normalized zpos values, but it doesn't
actually do that anymore since commit 38d868e41c4b ("drm: Don't force
all planes to be added to the state due to zpos"). Instead, drivers are
supposed to explicitly call the drm_atomic_normalize_zpos() function.
Change the kerneldoc comment to reflect that.

v2: reference the commit that introduced the kerneldoc unclarity

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
Link: https://patchwork.freedesktop.org/patch/msgid/20171120150959.26913-1-thierry.reding@gmail.com