universal planes in drm backend

[Simon Ser]

On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

I don't think that's an issue. Enabling overlay planes can fail for a
lot of other reasons, including for instance bandwidth limitations.

> Thanks,
> pq
>
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel