Thanks for the review!
On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter <dan...@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
