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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, December 11th, 2020 at 2:50 PM, Pekka Paalanen <ppaalanen@xxxxxxxxx> 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.

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

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



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux