Commit 8f6ea27b authored Oct 09, 2019 by Simon Ser Committed by Daniel Vetter Oct 09, 2019

drm: two planes with the same zpos have undefined ordering



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 <contact@emersion.fr>
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Marius Vlad <marius.vlad@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: James Qian Wang <james.qian.wang@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr

parent f2a4a13a

drivers/gpu/drm/drm_blend.c

+4 −4

Original line number	Diff line number	Diff line
		@@ -132,10 +132,10 @@
		* planes. Without this property the primary plane is always below the cursor
		* plane, and ordering between all other planes is undefined. The positive
		* Z axis points towards the user, i.e. planes with lower Z position values
		* are underneath planes with higher Z position values. Note that the Z
		* position value can also be immutable, to inform userspace about the
		* hard-coded stacking of overlay planes, see
		* drm_plane_create_zpos_immutable_property().
		* are underneath planes with higher Z position values. Two planes with the
		* same Z position value have undefined ordering. Note that the Z position
		* value can also be immutable, to inform userspace about the hard-coded
		* stacking of planes, see drm_plane_create_zpos_immutable_property().
		*
		* pixel blend mode:
		* Pixel blend mode is set up with drm_plane_create_blend_mode_property().

include/drm/drm_plane.h

+5 −4

Original line number	Diff line number	Diff line
		@@ -140,10 +140,11 @@ struct drm_plane_state {
		* @zpos:
		* Priority of the given plane on crtc (optional).
		*
		* Note that multiple active planes on the same crtc can have an
		* identical zpos value. The rule to solving the conflict is to compare
		* the plane object IDs; the plane with a higher ID must be stacked on
		* top of a plane with a lower ID.
		* User-space may set mutable zpos properties so that multiple active
		* planes on the same CRTC have identical zpos values. This is a
		* user-space bug, but drivers can solve the conflict by comparing the
		* plane object IDs; the plane with a higher ID is stacked on top of a
		* plane with a lower ID.
		*
		* See drm_plane_create_zpos_property() and
		* drm_plane_create_zpos_immutable_property() for more details.

Admin message