All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.