[v4] drm: two planes with the same zpos have undefined ordering

[Simon Ser]

On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter <daniel at ffwll.ch> wrote:

> > > > > In any case, this doesn't change the patch itself. Probably something worth
> > > > > mentionning in the commit message.
> > > >
> > > > Yes, recording these use cases would be very nice.
> > >
> > > There's a lot more hw that does the same tricks (qualcom is one for sure).
> > > Imo before we encode this we should make sure that:
> > > a) everyone is happy with this new uapi
> >
> > Sorry, what new UAPI?
> > We're just trying to make the documentation match what currently
> > happens, right?
>
> It's so much new uapi that I've sent out a few reverts for 5.4 (it
> landed in that merge window) to undo the stuff the arm driver team has
> done (it didn't come with userspace, proper discussion on dri-devel,
> docs or testcases in igt). I also just spotted that a leftover is that
> arm/komeda still computes its own version of normalized_zpos, which
> probably should be ditched too (it's not actually different from the
> one in helpers without the reverted uapi).
>
> So yeah, separate patch :-)

I don't get it. Do you want to split the docs changes for user-space,
only keeping the doc changes for drivers in this patch?

User-space could already see duplicate zpos because of the non-atomic
API. I don't think this introduces a new uAPI.