[PATCH] drm/atomic-helper: Calculate normalized zpos values

[Thierry Reding]

On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> > will automatically calculate the normalized zpos values, but it won't
> > currently do so. Modify the atomic helpers to behave as documented.
> 
> NAK
> 
> See commit  38d868e41c4b ("drm: Don't force all planes to be added to
> the state due to zpos")

Thanks, that's interesting background. It's a little unfortunate that
I'll have to go and add a custom ->atomic_check() just because of this.

This is something in general that's been bugging me. How are we supposed
to keep all of the custom ->atomic_check() implementations in sync with
the atomic helpers? It looks to me like most drivers will at some point
copy the atomic helper to their driver and then make driver-specific
changes to them. But then when one of the helpers gets updated, the same
changes are usually not propagated to the drivers that originally copied
from the helpers.

One way I've seen used (and have used myself) occasionally is for the
driver-specific implementations to "subclass" the helpers by calling the
helper first and then calling the driver-specific bits. That helps a lot
but will obviously not work if ordering is important.

Any ideas on how we can improve that? Other than periodically checking
the git log for the helpers and updating drivers? I suppose if one were
to closely follow the mailing list one might notice early on, and maybe
speak up and have the changes applied to the drivers in the same patch
as the helpers. But I don't think that's going to work for every driver.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20171113/3c4cd32b/attachment.sig>