dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Simon Ser <contact@emersion.fr>
Cc: daniel.vetter@ffwll.ch, daniels@collabora.com,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: two planes with the same zpos have undefined ordering
Date: Tue, 10 Sep 2019 13:38:10 +0300	[thread overview]
Message-ID: <20190910133810.64e973f4@eldfell.localdomain> (raw)
In-Reply-To: <KJRi1ROX2_eM1WjtEQ1e1-f--VK4hwMQJQt1nPaS6lcmt3v4yIfdttLIu_EOGdkwXwEMAEo66Xa7ksp7iQABWT5GuMu6UgKoiuEm6EU2N1U=@emersion.fr>


[-- Attachment #1.1: Type: text/plain, Size: 2925 bytes --]

On Tue, 10 Sep 2019 10:09:55 +0000
Simon Ser <contact@emersion.fr> wrote:

> 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 rule mentionned in the past was to disambiguate with object IDs. However
> some drivers break this rule (that's why the ordering is documented as
> unspecified in case the zpos property is missing). Additionally it doesn't
> really make sense for a driver to user identical zpos values if it knows their
> relative position: the driver can just pick different values instead.
> 
> So two solutions would make sense: either disallow completely identical zpos
> values for two different planes, either make the ordering unspecified. To allow
> drivers that don't know the relative ordering between two planes to still
> expose the zpos property, choose the latter solution.
> 
> Signed-off-by: Simon Ser <contact@emersion.fr>
> ---
> 
> Err, I'm sorry about the double-post. I sent this to intel-gfx by mistake.
> 
>  drivers/gpu/drm/drm_blend.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index d02709dd2d4a..51bd5454e50a 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -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 overlay planes, see drm_plane_create_zpos_immutable_property().
>   *
>   * pixel blend mode:
>   *	Pixel blend mode is set up with drm_plane_create_blend_mode_property().

Hi,

this seems to contradict what the docs say in another place:

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.

    See drm_plane_create_zpos_property() and
    drm_plane_create_zpos_immutable_property() for more details.

from https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-09-10 10:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10 10:09 [PATCH] drm: two planes with the same zpos have undefined ordering Simon Ser
2019-09-10 10:38 ` Pekka Paalanen [this message]
2019-09-10 11:20   ` Simon Ser
2019-09-11  7:36     ` Pekka Paalanen
2019-09-16  9:19       ` Simon Ser
2019-09-19  7:18         ` Pekka Paalanen
2019-09-19  8:18           ` Daniel Vetter
2019-09-19  9:01             ` Pekka Paalanen
2019-09-19  9:36               ` Daniel Vetter
2019-09-16  9:48   ` Daniel Vetter
2019-09-17 17:24     ` [PATCH v2] " Simon Ser
2019-09-18 11:13       ` Marius Vlad
2019-09-18 12:20         ` Daniel Vetter
2019-09-18 16:33           ` [PATCH v3] " Simon Ser
2019-09-19  7:34             ` Pekka Paalanen
2019-09-23 12:39               ` [PATCH v4] " Simon Ser
2019-09-24  7:26                 ` Pekka Paalanen
2019-09-24  7:34                   ` Simon Ser
2019-09-24  8:48                     ` Pekka Paalanen
2019-09-24  8:57                       ` Simon Ser
2019-09-29  6:15                 ` [v4] " james qian wang (Arm Technology China)
2019-09-29 20:30                   ` Simon Ser
2019-09-30  7:07                     ` Pekka Paalanen
2019-10-08  9:59                       ` Daniel Vetter
2019-10-08 11:39                         ` Pekka Paalanen
2019-10-08 15:03                           ` Daniel Vetter
2019-10-08 15:11                             ` Simon Ser
2019-10-08 15:16                               ` Daniel Vetter
2019-10-08 15:23                                 ` Simon Ser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190910133810.64e973f4@eldfell.localdomain \
    --to=ppaalanen@gmail.com \
    --cc=contact@emersion.fr \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox