Re: [PATCH v3 4/4] drm: require each CRTC to have a unique primary plane

[Simon Ser <contact@emersion.fr>]

On Monday, December 14th, 2020 at 9:41 AM, Pekka Paalanen <ppaalanen@gmail.com> wrote:

> On Fri, 11 Dec 2020 14:39:35 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
> > On Friday, December 11th, 2020 at 2:50 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > > is there a reason why one cannot have more primary planes than CRTCs in
> > > existence?
> > >
> > > Daniel implied that in <20201209003637.GK401619@phenom.ffwll.local>,
> > > but I didn't get the reason for it yet.
> > >
> > > E.g. if all your planes are interchangeable in the sense that you can
> > > turn on a CRTC with any one of them, would one not then expose all the
> > > planes as "Primary"?
> >
> > I'm thinking of primary as a hint for simple user-space: "you can likely
> > light up a CRTC if you attach this plane and don't do anything crazy".
> > For anything more complicated, user-space uses atomic commits and can
> > completely ignore whether a plane is primary, cursor or overlay.
>
> That's a nice reason, do we have those written down anywhere?

Doesn't seem like it. The docs for enum drm_plane_type incorrectly say that the
a plane of type "Primary" will be used for legacy IOCTLs. Also, there are no
docs for the "type" property at all. I'm not even sure where to document it, as
there's no section for plane properties.

> - plane type "Primary" is a hint to userspace that using this plane
>   alone on a CRTC has the highest probability of being able to turn on
>   the CRTC
>
> - plane types are just a hint to userspace, userspace can and *should*
>   use atomic test_only commits to discover more ways of making use of
>   the planes (note: if this applies to cursor planes, it will invalidate
>   some "optimizations" that virtual hardware drivers like vmwgfx(?)
>   might do by having the cursor plane position controller directly from
>   the host rather than looped through the guest)

Yes. In an old thread, I suggested having a DRM cap that needs to be enabled
to allow the driver to de-synchronize a cursor plane's CRTC_X/Y.

> > > If the planes have other differences, like supported formats or
> > > scaling, then marking them all "Primary" would let userspace know that
> > > it can pick any plane with the suitable properties and expect to turn
> > > on the CRTC with it.
> >
> > That's interesting, but I'd bet no user-space does that. If new user-space
> > wants to, it's better to rely on test-only commits instead.
>
> Ok. So plane types are not a good reason to prune a compositor's testing
> matrix to avoid testing some combinations.

They are a hint, so in this sense they do help pruning the testing matrix. For
instance it would be impossible for user-space to figure out the right cursor
buffer parameters without DRM_CAP_CURSOR_{WIDTH,HEIGHT}. I also think there's
an undocumented assumption that the cursor buffer must be allocated with a
LINEAR layout when the driver doesn't support modifiers.

However, for this particular case I don't think the hint would be helpful.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel