Re: wayland-protocols scope and governance
On Tue, Sep 17, 2019 at 05:46:49PM +, Simon Ser wrote: > On Friday, September 6, 2019 10:45 AM, Jonas Ådahl wrote: > > > > 2.2. Protocol inclusion requirements > > > > > > > > > a. All protocols found in the "xdg" and "wp" namespaces at the time of > > > writing > > > are grandfathered into their respective namespace without further > > > discussion. > > > b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion > > > only if > > > ACKed by at least 3 members. > > > c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion > > > if > > > if NACKed by any member. > > > d. Protocols in the "xdg" and "wp" namespaces must have at least one > > > open-source > > > client implementation & two open-source server implementations to be > > > eligible > > > for inclusion. > > > > Maybe this was discussed in the past, but why two? If we'd travel back > > in time, it'd stall the introduction of xdg-foreign (took quite a while > > for a second server implementation to show up), which falls within the > > xdg namespace scope, and it'd block addition of protocols only > > interesting to a single compositor but multiple clients/toolkits (e.g. > > something very tiling specific that maybe only wlroots would care about, > > or something currently in gtk-shell that may be relevant for GNOME > > Shell, gtk and Qt, but not for other compositors). > > > > Same for protocols like the tablet interface; I think it's too much of a > > requirement to require the protocol author to provide TWO > > implementations for such a protocol, and relying on others to implement > > your protocol in their own compositors is quite a lot to ask IMHO. The > > end result is more likely we end up with more things like > > `gtk_primary_selection` instead of going upstream first. > > That's a very fair point. I think it would make sense to require more > implementations for unstable → stable upgrades (which are very > important, we can't fix those later). But for unstable protocols, you > do have a point. > > I guess the original intention was to make a difference between xdg/wp > inclusion and other namespaces: it should be harder to get a protocol > merged in xdg/wp. > > Thoughts? I think both for stable and unstable the same limitation can be as problematic. A protocol that fits in xdg/wp may still only be relevant for a single compositor and multiple toolkits, or vice versa, even when declared stable. Seems to me like the wrong method to keep quality of wp/xdg protocols high. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Friday, September 6, 2019 10:45 AM, Jonas Ådahl wrote: > > 2.2. Protocol inclusion requirements > > > > > > a. All protocols found in the "xdg" and "wp" namespaces at the time of > > writing > > are grandfathered into their respective namespace without further > > discussion. > > b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion > > only if > > ACKed by at least 3 members. > > c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if > > if NACKed by any member. > > d. Protocols in the "xdg" and "wp" namespaces must have at least one > > open-source > > client implementation & two open-source server implementations to be > > eligible > > for inclusion. > > Maybe this was discussed in the past, but why two? If we'd travel back > in time, it'd stall the introduction of xdg-foreign (took quite a while > for a second server implementation to show up), which falls within the > xdg namespace scope, and it'd block addition of protocols only > interesting to a single compositor but multiple clients/toolkits (e.g. > something very tiling specific that maybe only wlroots would care about, > or something currently in gtk-shell that may be relevant for GNOME > Shell, gtk and Qt, but not for other compositors). > > Same for protocols like the tablet interface; I think it's too much of a > requirement to require the protocol author to provide TWO > implementations for such a protocol, and relying on others to implement > your protocol in their own compositors is quite a lot to ask IMHO. The > end result is more likely we end up with more things like > `gtk_primary_selection` instead of going upstream first. That's a very fair point. I think it would make sense to require more implementations for unstable → stable upgrades (which are very important, we can't fix those later). But for unstable protocols, you do have a point. I guess the original intention was to make a difference between xdg/wp inclusion and other namespaces: it should be harder to get a protocol merged in xdg/wp. Thoughts? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: universal planes in drm backend
On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen 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
Re: universal planes in drm backend
On Tue, 17 Sep 2019 19:50:01 +1200 Scott Anderson 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 pgpkqEbcr9c1T.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: universal planes in drm backend
Hi scott yes, one CRTC bind to one primary plane. But if not all the crtcs are connected and universal planes is enable, the spare primary plane could be an overlay plane. for example, plane 0 ~ 5 for 6 CRTCs, they are all primary planes. But weston only enable 3 output, then plane 3 ~ 5 could treat as overlay plane. Thank you! Best regards Nancy Scott Anderson 于2019年9月17日周二 下午3:50写道： > 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. > > Scott > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: universal planes in drm backend
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. Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
universal planes in drm backend
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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
