On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Tue, 17 Sep 2019 19:50:01 +1200 > Scott Anderson scott.ander...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel