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
prev 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