<div dir="ltr">Hi all<div> </div><div>Thank you for your feedback.</div><div> </div><div>From your opinions, the drm backend reserve primary plane for each CRTC to avoid the failure in hotplug cases. However, as weston already enabled DRM_CLIENT_CAP_ATOMIC and DRM_CLIENT_CAP_UNIVERSAL_PLANES, the concept of primary/overlay is no necessary <a href="https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#c.drm_plane_type" style="font-family:Calibri,sans-serif;font-size:11pt;color:rgb(5,99,193)">https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#c.drm_plane_type</a>:</div><div> For historical reasons not all planes are made the same. This enumeration is used to tell the different types of planes apart to implement the different uapi semantics for them. For userspace which is universal plane aware and which is using that atomic IOCTL there's no difference between these planes (beyong what the driver and hardware can support of course). So weston should add the proper way to handle the case when output B is newly connected while output A is using up all planes, e.g. trigger a repaint for output A with less plane staged if new output B is hotplugged. This will optimize the general performance of weston and avoid h/w resource waste. It’s popular that the number of CRTCs is more than the number of outputs. A typical use case is DP-MST, where there could be multiple outputs in the daisy chain but total link rate is limited, e.g. H/W can either support 2 monitors with 4K output, or 4 monitors with 2K output. 4 CRTCs will be created at boot to support the 4 monitors with 2K output use case, but for 2 monitors with 4K output use case two planes will be completely wasted. Thank you! Best RegardsNancy</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> 于2019年9月18日周三下午3:54写道： </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 17 Sep 2019 10:02:44 +0000 Simon Ser <<a href="mailto:contact@emersion.fr" target="_blank">contact@emersion.fr</a>> wrote: > On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: > > > On Tue, 17 Sep 2019 19:50:01 +1200 > > Scott Anderson <a href="mailto:scott.anderson@collabora.com" target="_blank">scott.anderson@collabora.com</a> 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: > > > <a href="https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-abstraction" rel="noreferrer" target="_blank">https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-abstraction</a> > > > > > > > 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 </blockquote></div>