All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Ser <contact@emersion.fr>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: rework description of primary and cursor planes
Date: Wed, 09 Dec 2020 16:29:04 +0000	[thread overview]
Message-ID: <bO04K9yKix_WKPi_kWNVG89Byfn59pvY1OKaXbB0gQeAAEyuUDaVGX_PIgzNcLRU83SCzPe4Vm7V2O1-sm8X65CkoU3nmKcM5plDntx6FtU=@emersion.fr> (raw)
In-Reply-To: <20201209160223.GT401619@phenom.ffwll.local>

On Wednesday, December 9th, 2020 at 5:02 PM, Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, Dec 09, 2020 at 03:58:17PM +0000, Simon Ser wrote:
> > Thanks for the review!
> >
> > On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > > I think maybe a follow up patch should document how userspace should
> > > figure out how to line up the primary planes with the right crtcs (if it
> > > wishes to know that information, it's not super useful aside from probably
> > > good choice for a fullscreen fallback plane). See my reply on the old
> > > thread.
> >
> > Yeah, as I've already replied, I won't volunteer to document legacy bits,
> > documenting atomic is already enough. :P
>
> This is also somewhat useful as a hint for atomic userspace.

How so? Atomic can just pick the first compatible primary plane for CRTC 1,
the first available primary plane from the rest for CRTC 2, and so on.

> > > And that patch should also add the code to drm_mode_config_validate() to
> > > validate the possible_crtc masks for these. Something like
> > >
> > > 	num_primary = 0; num_cursor = 0;
> > >
> > > 	for_each_plane(plane) {
> > > 		if (plane->type == primary) {
> > > 			WARN_ON(!(plane->possible_crtcs & BIT(num_primary)));
> > > 			num_primary++;
> > > 		}
> > >
> > > 		/* same for cursor */
> > > 	}
> > >
> > > 	WARN_ON(num_primary != dev->mode_config.num_crtcs);
> > > }
> >
> > Thanks for the suggestion. However I don't see why a driver should ensure
> > this. Isn't it perfectly fine for a driver to use primary plane 2 for CRTC 1,
> > and primary plane 1 for CRTC 2, for the purposes of legacy uAPI?
>
> Yeah but it's a mess. Messes don't make good uapi.
>
> > If we're trying here to invent a new uAPI to let user-space discover the
> > internal legacy primary/cursor pointers, I'm not signing up for this. The
> > requirement you're describing seems like something current drivers ensure
> > "by chance", not an established uAPI. In other words, writing a new driver
> > that doesn't do the same wouldn't break uAPI contracts.
>
> I'm more seeing this as general uapi lock-down. "Everything goes" doesn't
> work great. And it's all the same topic really. Like if your userspace
> really doesn't care about what the primary plane is (like you seem to
> imply), then ofc none of this matters to you, but then also your doc patch
> here doesn't matter.

My patch makes it clear the "one primary plane per CRTC" requirement is just
for legacy uAPI. See the commit message.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-12-09 16:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-06 16:34 [PATCH] drm: rework description of primary and cursor planes Simon Ser
2020-12-09  0:42 ` Daniel Vetter
2020-12-09  8:38   ` Pekka Paalanen
2020-12-09 15:58   ` Simon Ser
2020-12-09 16:02     ` Daniel Vetter
2020-12-09 16:29       ` Simon Ser [this message]
2020-12-09 16:35       ` Simon Ser
2020-12-09 19:40         ` Daniel Vetter
2020-12-10 15:45           ` Simon Ser
2020-12-10 15:47             ` Simon Ser
2020-12-10 15:56             ` Daniel Vetter
2020-12-10 16:01               ` Simon Ser
2020-12-10 16:27               ` Alex Deucher

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='bO04K9yKix_WKPi_kWNVG89Byfn59pvY1OKaXbB0gQeAAEyuUDaVGX_PIgzNcLRU83SCzPe4Vm7V2O1-sm8X65CkoU3nmKcM5plDntx6FtU=@emersion.fr' \
    --to=contact@emersion.fr \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.