dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: tomi.valkeinen@ti.com, jsarha@ti.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4] drm/omap: plane zpos/zorder management improvements
Date: Mon, 08 Jan 2018 12:47:53 +0200	[thread overview]
Message-ID: <11779814.ABnxGQLWmM@avalon> (raw)
In-Reply-To: <6b58bd8b-fd93-6c0b-80a8-56f48c09afbf@ti.com>

Hi Peter,

On Monday, 8 January 2018 10:20:24 EET Peter Ujfalusi wrote:
> On 2018-01-05 16:04, Laurent Pinchart wrote:
> > On Friday, 5 January 2018 13:30:37 EET Peter Ujfalusi wrote:
> >> Use the plane index as default zpos for all planes. Even if the
> >> application is not setting zpos/zorder explicitly we will have unique
> >> zpos for each plane.
> >> 
> >> Enforce that all planes must have unique zpos on the given crtc.
> > 
> > Could you explain the rationale for that in the commit message, what's
> > wrong with duplicate zpos values ?
> 
> Planes with identical zpos is only 'valid' _if_ they are not
> overlapping, if they do overlap then it is - imho - not a valid
> configuration anyway (which one should be on top?).
> Based on my tests the plane with lower planeID is going to disappear
> from the screen if we have duplicated zpos.

Please see my reply to Tomi on this topic. I'm not against the change, but I 
think the rationale should be captured in the commit message.

> > Isn't there a risk of breaking the non-atomic userspace with this ?
> > Without atomic commits userspace can't change the zpos of multiple planes
> > in one go, so it might be impossible to reorder planes without going
> > through a state that has duplicated zpos values.
> 
> Two planes occupying the same position on the screen is not valid
> (again, imho).

At the hardware level for the DSS, sure. According to the KMS API, however, it 
is valid, even if the conflict resolution is driver-dependent.

> If application wants to swap two planes, then it must disable one, move the
> other to the new position, then enable and move the first plane.

Applications don't do that at the moment, so there's a risk of breakage. As 
the current behaviour is undefined we might not considered that as a problem, 
but there's a risk of returning an error for an operation that currently 
succeeds.

Personally I think all applications should move to the atomic API and handle 
zpos explicitly so I don't mind too much :)

> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> >> ---
> >> Hi,
> >> 
> >> Changes since v3:
> >> - Use drm_plane_index() instead of storing the same index wothin
> >>   omap_plane struct
> >> - Optimize the zpos validation loop so we avoid extra checks.
> >> 
> >> Changes since v2:
> >> - The check for duplicate zpos is moved to omap_crtc
> >> 
> >> Changes since v1:
> >> - Dropped the zpos normalization related patches
> >> - New patch based on the discussion, see commit message.
> >> 
> >> Regards,
> >> Peter
> >> 
> >>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 36 +++++++++++++++++++++++++++++-
> >>  drivers/gpu/drm/omapdrm/omap_plane.c | 15 ++++-----------
> >>  2 files changed, 39 insertions(+), 12 deletions(-)

-- 
Regards,

Laurent Pinchart

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

      parent reply	other threads:[~2018-01-08 10:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-05 11:30 [PATCH v4] drm/omap: plane zpos/zorder management improvements Peter Ujfalusi
2018-01-05 14:04 ` Laurent Pinchart
2018-01-08  8:20   ` Peter Ujfalusi
2018-01-08  8:59     ` Tomi Valkeinen
2018-01-08 10:43       ` Laurent Pinchart
2018-01-08 10:58         ` Tomi Valkeinen
2018-01-08 11:07           ` Laurent Pinchart
2018-01-09  8:11             ` Tomi Valkeinen
2018-01-08 10:47     ` Laurent Pinchart [this message]

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=11779814.ABnxGQLWmM@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=tomi.valkeinen@ti.com \
    /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