Re: [PATCH] drm: rework description of primary and cursor planes

[Simon Ser <contact@emersion.fr>]

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

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

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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel