On Tue, 17 Sep 2019 10:02:44 +0000 Simon Ser <cont...@emersion.fr> wrote:
> 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. Sure, an overlay plane failing is not an issue. A primary plane failing when no overlays on *that* CRTC are in used is an issue. To clarify, let's assume we have outputs A and B, and CRTCs A and B respectively. Output A is active, using one primary plane and three overlays on CRTC A. Output B is off. Output B needs to be activated. It needs a primary plane on CRTC B. However, no primary planes are actually usable, because output A is using them all. The compositor probably does not guess that it needs to stop using overlays on output A to be able to turn output B on.(*) If previously it was impossible for output A to use up all primary planes, enabling output B always succeeded. If the kernel driver then offers all primary planes on all CRTCs, allowing CRTC A to use them all up, then enabling output B will fail. By definition, this is a kernel induced regression: it used to work, then you upgraded the kernel, and now it doesn't work. (*) Or should it guess? If we think of global bandwidth limitations, it probably should. But if it doesn't, we are still facing a situation where the kernel regressed, because userspace stopped working. Thanks, pq
pgpvT8Thr7Pbg.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel