universal planes in drm backend

Pekka Paalanen ppaalanen at gmail.com
Tue Sep 17 09:29:29 UTC 2019


On Tue, 17 Sep 2019 19:50:01 +1200
Scott Anderson <scott.anderson at collabora.com> wrote:

> On 17/09/19 7:38 pm, zou lan wrote:
> > Hi Daniel & all
> > 
> > I find the function drm_output_prepare_overlay_view() only use the plane 
> > type of WDRM_PLANE_TYPE_OVERLAY. it could be a waste for some planes of 
> > type WDRM_PLANE_TYPE_PRIMARY if the universal planes is enable.
> > 
> > For example, the kernel define 6 crtcs, and each crtc will have one 
> > primary type plane, but not all of the crtcs are used by weston_output. 
> > Some crtcs may never used, if we reserve  all the primary type planes as 
> > scanout plane, that could waste some of them.
> > 
> > Could the open source drm backend modify the logic of judge the overlay 
> > plane? let the primary plane equal to overlay plane or judge in 
> > drm_output_prepare_overlay_view(), if the plane is not used by outputs, 
> > it could be used by overlay?
> > 
> > Thank you!
> > 
> > Best regards
> > Nancy  
> Hi,
> 
> As far as I'm aware, the kernel never advertises more than one primary 
> plane per CRTC and they're never possible to be used with multiple 
> CRTCs: 
> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-abstraction
> 
>  >All drivers should provide one primary plane per CRTC to avoid   
> surprising userspace too much
> 
> Perhaps that restriction is not as strict as I interpret it to be, but 
> I'm not aware of anything which does not have a one-to-one relationship 
> between primary planes and CRTCs.

If the kernel actually did expose multiple primary planes on the same
CRTC, they would also need zpos property to tell their stacking order,
and Weston needs to use it (which it does not yet).

However, given the special expectations that all userspace likely has
for primary planes, the kernel driver might be better exposing more
planes of type OVERLAY while internally mapping them to the "other
primary planes".

However, that would still pose a problem, that userspace would need to
know to disable some/all overlay planes when activating a new output
fails and try again with the hope that a primary plane was made
available under the hood. That would be pretty special. So it is
possible that exposing the additional planes would break existing
userspace for hotplug output activation under special circumstances
(overlay planes used on old outputs).


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/wayland-devel/attachments/20190917/b19704bf/attachment.sig>


More information about the wayland-devel mailing list