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

[Pekka Paalanen]

On Fri, 11 Dec 2020 14:39:35 +0000
Simon Ser <contact at emersion.fr> wrote:

> On Friday, December 11th, 2020 at 2:50 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > is there a reason why one cannot have more primary planes than CRTCs in
> > existence?
> >
> > Daniel implied that in <20201209003637.GK401619 at 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?

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

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

> > Or does marking a plane as "Primary" imply something else too, like
> > "cannot scale"? I think Weston does make this assumption in an attempt
> > to hit fewer causes for failure.  
> 
> No, AFAIK "Primary" doesn't imply something else, e.g. on amdgpu you can do
> scaling on the primary plane.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20201214/f2c0e75e/attachment.sig>