public inbox for dri-devel@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/atomic-helper: Calculate normalized zpos values
Date: Mon, 13 Nov 2017 21:56:19 +0100	[thread overview]
Message-ID: <20171113205619.GA7600@ulmo> (raw)
In-Reply-To: <20171113141405.GN10981@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 1782 bytes --]

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@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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-11-13 20:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 13:48 [PATCH] drm/atomic-helper: Calculate normalized zpos values Thierry Reding
2017-11-13 14:14 ` Ville Syrjälä
2017-11-13 20:56   ` Thierry Reding [this message]
2017-11-13 21:24     ` Ville Syrjälä
2017-11-20  7:50     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171113205619.GA7600@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox