From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH] drm/atomic-helper: Calculate normalized zpos values Date: Mon, 13 Nov 2017 21:56:19 +0100 Message-ID: <20171113205619.GA7600@ulmo> References: <20171113134820.5673-1-thierry.reding@gmail.com> <20171113141405.GN10981@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1259883013==" Return-path: Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) by gabe.freedesktop.org (Postfix) with ESMTPS id 090346EC2C for ; Mon, 13 Nov 2017 20:56:23 +0000 (UTC) Received: by mail-wm0-x22b.google.com with SMTP id r68so17443138wmr.1 for ; Mon, 13 Nov 2017 12:56:22 -0800 (PST) In-Reply-To: <20171113141405.GN10981@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ville =?utf-8?B?U3lyasOkbMOk?= Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1259883013== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrj=C3=A4l=C3=A4 wrote: > On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote: > > From: Thierry Reding > >=20 > > 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. >=20 > NAK >=20 > 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 =66rom 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 --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAloKBvMACgkQ3SOs138+ s6ETMw/7B6S74GUzGxRbOP7w6Pfnu+oXy2D2KUN5sF7quZJlwGdzHyKKDrBykLSY rnWR1qfMW1ZHcbRvsPgxURfLF1MRPgI11ZYHwYAOJXUq5InCCWOBSLpW/esTSTvJ WCqx+D1Ok15sPnbCsyaBW2EEJWGFUy+F9o3U4I/95W+l6nIZLM27W6oy0LsI36uf h7avuEKfh6ZmpYnmY1Qc7Co7YbxB/NmB/+vvZ5HlcXkAUe5whIWeGJF1pVWcE/HY LhBZqGr4J0P0q95LODMQOSed3wUE6g3ZFQqCDbTmgUU4qgmbQNahwlgRQiEVhlcC svf1fFcD9X+91Jodkn4I97wp7IMpn/j3KWBT8bPynL68Ii4BGXYYejivHeSRrz0s nsKGFwBfP8lqTF50IuDczy7MeyFeDksNL3QQNEjPuWlubUQL5ArH3S6hvKX4+ZII t4MT1RaqTSVdrs1yj9T7sF60cVUIBg9s8le/z8KkBaR4Phi+qYm7Jv+3c/23ukxS bGsIxfHtcecNadUFAKBT8VRtkD5UHC+RglNOFwk5YmnWByLuE9kl+NpJCuI1c75Q 3I6E30Hh9emZwKmLQtcYIFqK7uTNZ/mKe8L+0xYdGRhawdsXev5k3y3ftUH6nECa EAa3snno+FC/Z5Z0l8OPJ35CUH0TJPGBl86EuP2+yx6LzvQdm1I= =21l7 -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- --===============1259883013== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1259883013==--