[PATCH] drm: drivers may provide multiple primary planes per CRTC

[Simon Ser]

On Friday, August 7, 2020 11:07 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Aug 06, 2020 at 10:33:31AM +0000, Simon Ser wrote:
> > Some drivers may expose primary planes compatible with multiple CRTCs.
> > Make this clear in the docs: the current wording may be misunderstood as
> > "exactly one primary plane per CRTC".
> >
> > Signed-off-by: Simon Ser <contact at emersion.fr>
> > Cc: Daniel Vetter <daniel at ffwll.ch>
> > ---
> >  drivers/gpu/drm/drm_plane.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index b7b90b3a2e38..108a922e8c23 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -49,8 +49,8 @@
> >   * &struct drm_plane (possibly as part of a larger structure) and registers it
> >   * with a call to drm_universal_plane_init().
> >   *
> > - * Cursor and overlay planes are optional. All drivers should provide one
> > - * primary plane per CRTC to avoid surprising userspace too much. See enum
> > + * Cursor and overlay planes are optional. All drivers should provide at least
> > + * one primary plane per CRTC to avoid surprising userspace too much. See enum
>
> I think that's even more confusing, since this reads like there could be
> multiple primary planes for a specific CRTC. That's not the case, there'
> only one pointer going from drm_crtc->primary to a drm_plane in the
> kernel.
>
> The problem is that userspace doesn't have a drm_property to read this
> pointer, and needs to guess.
>
> I thought the rule is:
>
> Nth primary plane (or cursor) is the primary plane for the Nth crtc.
> Enumaration with increasing drm kms object ids.
>
> And I guess we should explain that on some hw any plane (including primary
> ones, since that's only a sw construct) can be freely assinged to crtc.

Eh, wow. Okay, I didn't expect that. :P

What does drm_crtc->primary mean in case a GPU exposes more than one CRTC in
the primary planes' possible_crtcs bitfield? Does this pointer change if I
assign primary plane 2 to CRTC 1? Is the primary n → CRTC n assignment just a
default?

Maybe we can just say that at most a single primary plane may be assigned to a
CRTC, and that a primary plane may be compatible with multiple CRTCs?

> Yes it's probably the most gloriously bonkers uapi we've come up with.
> Might be so bad that a libdrm helper to look up the primary plane for a
> crtc (or it's cursor plane if it exists) would be in order :-)

Well, if user-space can change drm_crtc->primary, I'm not sure this is a good
idea.