On Tuesday, October 8, 2019 6:16 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Oct 8, 2019 at 5:11 PM Simon Ser contact@emersion.fr wrote:
On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter daniel@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.
I'm talking specifically about the "duplicated zpos values indicate special cloned planes like in the arm example" clarification. Not about splitting the zpos documentation any more, that's indeed just documenting existing uapi. But assigning the special meaning to duplicated zpos values (instead of just "can happen because non-atomic legacy userspace"), that is new uapi. Especially if we allow duplicated zpos for immutable properties (afaik that doesn't exist yet).
Oh, I see. That makes sense, will send a new version.