Hello, On Monday, 8 January 2018 10:59:29 EET Tomi Valkeinen wrote: > On 08/01/18 10:20, 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?). > > For DSS it's clear. It is an invalid HW configuration to have multiple > planes with the same zpos in the same crtc. I believe the result is > undefined HW behavior. > > So we either return an error, or the kernel normalizes zpos'es. > Normalizing means the kernel is guessing what the end result should be, > so I like error better. I wouldn't call that guessing :-) Duplicate zpos values result in plane being sorted based on the plane ID (this is obviously implementation-dependent, I mean this is the currently implemented behaviour), which I don't think is an issue in itself. A userspace zpos API that resolves conflicting zpos values that way isn't a broken API, even if its behaviour might be considered a bit complex or cumbersome. I'm not against forbidding duplicate zpos values, but I think the rationale should be captured in the kernel message. There's also a risk of breaking non-atomic userspace (as explained in my previous e-mail), as well as atomic userspace that doesn't set zpos explicitly if run after an application that changed the zpos values. True, that would today result in an undefined behaviour, so this might not be considered a problem. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
