RE: Blank screen observed when running Weston with pixman renderer and drm-backend
Hi Marius, We are using pure upstream Weston 10.0.2. Will open a gitlab issue. Thanks, Namit -Original Message- From: Marius Vlad Sent: Friday, July 5, 2024 3:37 PM To: Namit Solanki (QUIC) Cc: Pritama Biswas (QUIC) ; wayland-devel@lists.freedesktop.org Subject: Re: Blank screen observed when running Weston with pixman renderer and drm-backend Hi Pritama, Namit, On Fri, Jul 05, 2024 at 07:14:35AM +, Namit Solanki (QUIC) wrote: > Hi Weston team, > > Can you please let us know if you faced this issue on Weston 10? No. I've tried this with 10.0.2 and 10.0.5 (our latest bug-fix release Weston 10). > > Or else can you please give some pointers to debug this issue? Are you using the upstream Weston version or something like the NXP fork? I'd suggesting opening a gitlab issue if this with Weston upstream. Possibly this might be a display driver issues if I can't observe it on i915. You could try disabling the animation entirely as a temporary work-around: Under [shell] section add startup-animation=none. > > Thanks, > Namit > > From: Pritama Biswas (QUIC) > Sent: Wednesday, July 3, 2024 6:29 PM > To: wayland-devel@lists.freedesktop.org > Cc: Namit Solanki (QUIC) > Subject: Blank screen observed when running Weston with pixman > renderer and drm-backend > > Hi Team, > > We are observing the following issue on Weston 10.0.2: > > When we launch Weston with drm-backend and pixman renderer, we are seeing > blank screen. Upon doing hotplug, display is coming up. > > In layer dumps, we can see that a fully opaque layer is getting created > during issue case as shown below: > > Layer 0 (pos 0x): > View 0 (role (null), PID 0, surface ID 0, [no description available], > 0x55968bdfc0): > position: (0, 0) -> (1920, 1080) > [fully opaque] > outputs: 0 (DSI-1) (primary) > [buffer not available] > > > It is caused due to creation of fade layer in desktop-shell. Once the > desktop-shell client is ready, the layer should fade in. But we suspect that > the layer is not getting faded in properly. > To confirm, we made the following change to disable the creation of fade > layer. With this change, the issue is getting resolved and Weston UI is up > everytime. > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index > 63e1431..b391d00 100644 > --- a/desktop-shell/shell.c > +++ b/desktop-shell/shell.c > @@ -4154,6 +4154,8 @@ shell_fade_init(struct desktop_shell *shell) > struct wl_event_loop *loop; > struct shell_output *shell_output; > > + return; > + > if (shell->startup_animation_type == ANIMATION_NONE) > return; > > > Can you please help us debug or fix this issue. > > Thanks and Regards, > Pritama Biswas
Re: Blank screen observed when running Weston with pixman renderer and drm-backend
Hi Pritama, Namit, On Fri, Jul 05, 2024 at 07:14:35AM +, Namit Solanki (QUIC) wrote: > Hi Weston team, > > Can you please let us know if you faced this issue on Weston 10? No. I've tried this with 10.0.2 and 10.0.5 (our latest bug-fix release Weston 10). > > Or else can you please give some pointers to debug this issue? Are you using the upstream Weston version or something like the NXP fork? I'd suggesting opening a gitlab issue if this with Weston upstream. Possibly this might be a display driver issues if I can't observe it on i915. You could try disabling the animation entirely as a temporary work-around: Under [shell] section add startup-animation=none. > > Thanks, > Namit > > From: Pritama Biswas (QUIC) > Sent: Wednesday, July 3, 2024 6:29 PM > To: wayland-devel@lists.freedesktop.org > Cc: Namit Solanki (QUIC) > Subject: Blank screen observed when running Weston with pixman renderer and > drm-backend > > Hi Team, > > We are observing the following issue on Weston 10.0.2: > > When we launch Weston with drm-backend and pixman renderer, we are seeing > blank screen. Upon doing hotplug, display is coming up. > > In layer dumps, we can see that a fully opaque layer is getting created > during issue case as shown below: > > Layer 0 (pos 0x): > View 0 (role (null), PID 0, surface ID 0, [no description available], > 0x55968bdfc0): > position: (0, 0) -> (1920, 1080) > [fully opaque] > outputs: 0 (DSI-1) (primary) > [buffer not available] > > > It is caused due to creation of fade layer in desktop-shell. Once the > desktop-shell client is ready, the layer should fade in. But we suspect that > the layer is not getting faded in properly. > To confirm, we made the following change to disable the creation of fade > layer. With this change, the issue is getting resolved and Weston UI is up > everytime. > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c > index 63e1431..b391d00 100644 > --- a/desktop-shell/shell.c > +++ b/desktop-shell/shell.c > @@ -4154,6 +4154,8 @@ shell_fade_init(struct desktop_shell *shell) > struct wl_event_loop *loop; > struct shell_output *shell_output; > > + return; > + > if (shell->startup_animation_type == ANIMATION_NONE) > return; > > > Can you please help us debug or fix this issue. > > Thanks and Regards, > Pritama Biswas signature.asc Description: PGP signature
RE: Blank screen observed when running Weston with pixman renderer and drm-backend
Hi Weston team, Can you please let us know if you faced this issue on Weston 10? Or else can you please give some pointers to debug this issue? Thanks, Namit From: Pritama Biswas (QUIC) Sent: Wednesday, July 3, 2024 6:29 PM To: wayland-devel@lists.freedesktop.org Cc: Namit Solanki (QUIC) Subject: Blank screen observed when running Weston with pixman renderer and drm-backend Hi Team, We are observing the following issue on Weston 10.0.2: When we launch Weston with drm-backend and pixman renderer, we are seeing blank screen. Upon doing hotplug, display is coming up. In layer dumps, we can see that a fully opaque layer is getting created during issue case as shown below: Layer 0 (pos 0x): View 0 (role (null), PID 0, surface ID 0, [no description available], 0x55968bdfc0): position: (0, 0) -> (1920, 1080) [fully opaque] outputs: 0 (DSI-1) (primary) [buffer not available] It is caused due to creation of fade layer in desktop-shell. Once the desktop-shell client is ready, the layer should fade in. But we suspect that the layer is not getting faded in properly. To confirm, we made the following change to disable the creation of fade layer. With this change, the issue is getting resolved and Weston UI is up everytime. diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index 63e1431..b391d00 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -4154,6 +4154,8 @@ shell_fade_init(struct desktop_shell *shell) struct wl_event_loop *loop; struct shell_output *shell_output; + return; + if (shell->startup_animation_type == ANIMATION_NONE) return; Can you please help us debug or fix this issue. Thanks and Regards, Pritama Biswas
Blank screen observed when running Weston with pixman renderer and drm-backend
Hi Team, We are observing the following issue on Weston 10.0.2: When we launch Weston with drm-backend and pixman renderer, we are seeing blank screen. Upon doing hotplug, display is coming up. In layer dumps, we can see that a fully opaque layer is getting created during issue case as shown below: Layer 0 (pos 0x): View 0 (role (null), PID 0, surface ID 0, [no description available], 0x55968bdfc0): position: (0, 0) -> (1920, 1080) [fully opaque] outputs: 0 (DSI-1) (primary) [buffer not available] It is caused due to creation of fade layer in desktop-shell. Once the desktop-shell client is ready, the layer should fade in. But we suspect that the layer is not getting faded in properly. To confirm, we made the following change to disable the creation of fade layer. With this change, the issue is getting resolved and Weston UI is up everytime. diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index 63e1431..b391d00 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -4154,6 +4154,8 @@ shell_fade_init(struct desktop_shell *shell) struct wl_event_loop *loop; struct shell_output *shell_output; + return; + if (shell->startup_animation_type == ANIMATION_NONE) return; Can you please help us debug or fix this issue. Thanks and Regards, Pritama Biswas
Blank screen observed when running Weston with pixman renderer and drm-backend
Hi Team, We are observing the following issue on Weston 10.0.2: When we launch Weston with drm-backend and pixman renderer, we are seeing blank screen. Upon doing hotplug, display is coming up. In layer dumps, we can see that a fully opaque layer is getting created during issue case as shown below: Layer 0 (pos 0x): View 0 (role (null), PID 0, surface ID 0, [no description available], 0x55968bdfc0): position: (0, 0) -> (1920, 1080) [fully opaque] outputs: 0 (DSI-1) (primary) [buffer not available] It is caused due to creation of fade layer in desktop-shell. Once the desktop-shell client is ready, the layer should fade in. But we suspect that the layer is not getting faded in properly. To confirm, we made the following change to disable the creation of fade layer. With this change, the issue is getting resolved and Weston UI is up everytime. diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index 63e1431..b391d00 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -4154,6 +4154,8 @@ shell_fade_init(struct desktop_shell *shell) struct wl_event_loop *loop; struct shell_output *shell_output; + return; + if (shell->startup_animation_type == ANIMATION_NONE) return; Can you please help us debug or fix this issue. Thanks and Regards, Pritama Biswas
RE: Full-motion zero-copy screen capture in Weston
>> >> >> -Original Message- >> From: Hoosier, Matt >> Sent: Monday, June 17, 2024 8:28 AM >> To: Pekka Paalanen >> Cc: 'Marius Vlad' ; >> 'wayland-devel@lists.freedesktop.org' ; >> 'Daniel Stone' >> Subject: RE: Full-motion zero-copy screen capture in Weston >> >> > -Original Message- >> > From: Pekka Paalanen >> > Sent: Monday, June 17, 2024 3:28 AM >> > To: Hoosier, Matt >> > Cc: 's...@cmpwn.com' ; 'cont...@emersion.fr' >> > ; 'Marius Vlad' ; >> > 'wayland-devel@lists.freedesktop.org' > > de...@lists.freedesktop.org>; 'Daniel Stone' >> > Subject: Re: Full-motion zero-copy screen capture in Weston >> > >> > On Fri, 14 Jun 2024 18:36:57 + >> > "Hoosier, Matt" wrote: >> > >> > > >> > > Hmm. As I read through the history of the original support for >> > > writeback screenshots >> > > (https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458) >> > > and get some initial results just trying to drive a steady stream of >> > > writeback composition, I'm not sure this can work effectively. >> > > >> > > MR 458 has a fairly long discussion about the restriction that no >> > > further commits must be made to the source CRTC or any of the other >> > > KMS objects reachable on its graph, while a writeback composition >> > > referencing that CRTC is still in flight. >> > > >> > > Daniel Vetter confirmed that interpretation. >> > > >> > > I think this means that unless you are extremely lucky that: >> > > >> > > (a) your hardware's writeback mechanism is synchronous with scanout, >> > > and (b) the fence fd manages to fire and get dispatched immediately >> > > upon scanout/writeback passing through the final scanline, and (c) >> > > there's a really large vertical back porch >> > > >> > > , there will be no time left to enqueue a page flip for the >> > > immediately succeeding vblank. >> > > >> > > Seems like this will almost always cut the frame achievable update >> > > rate on the main connector in half. >> > > >> > > Did I misinterpret something in there? Early results look like the >> > > kernel state machine gets confused (with VKMS anyway) if I queue up >> > > two writeback operations in flight at the same time. >> > >> > Hi Matt, >> > >> > I really don't know. If hardware and drivers require that, and cannot >> > stream at full refresh rate, then there is not much we can do. >> > >> > Not much, because I got one idea: Weston could repaint pre-emptively >> > according to its own schedule, but KMS-flip only when the writeback >> > situation allows. That should reduce the time needed between the >> > writeback completion fence firing and the KMS deadline for the flip. >> > >> > VKMS might rely on the above rules, or maybe it's not fully developed, >> > I'm not sure. You'd have to ask its developers. OTOH, if all hardware >> > drivers need the above rules, then VKMS should too. Maybe it just >> > needs to check and fail better. >> > >> > >> > Thanks, >> > pq >> >> Okay. I think maybe it makes sense to figure out who originally added this >> kernel documentation and see whether the situation is really so grim. >> >> I'll see about writing something to whoever that was, perhaps with dri-devel >> CC'ed. >> It turns out that the official interpretation of the documentation on the KMS writeback connector's properties is that the framerate of the CRTC driving the writeback operations will almost always be cut in half: https://lists.freedesktop.org/archives/dri-devel/2024-June/458351.html This isn't a hit that the use-cases I have in mind can afford, so I probably won't continue trying to make an implementation of this Pipewire stream driven by the writeback connector. Some of the responders to that thread over on dri-devel are beginning to speculate about updated DRM uAPI properties that would better support streaming of those writeback connectors whose hardware can do it. Maybe I'll revisit if that discussion goes far and something new lands in the framework. Thanks to everybody for the advice along the way. -Matt
RE: Full-motion zero-copy screen capture in Weston
> -Original Message- > From: Pekka Paalanen > Sent: Monday, June 17, 2024 3:28 AM > To: Hoosier, Matt > Cc: 's...@cmpwn.com' ; 'cont...@emersion.fr' > ; 'Marius Vlad' ; > 'wayland-devel@lists.freedesktop.org' de...@lists.freedesktop.org>; 'Daniel Stone' > Subject: Re: Full-motion zero-copy screen capture in Weston > > On Fri, 14 Jun 2024 18:36:57 + > "Hoosier, Matt" wrote: > > > > > Hmm. As I read through the history of the original support for > > writeback screenshots > > (https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458) > > and get some initial results just trying to drive a steady stream of > > writeback composition, I'm not sure this can work effectively. > > > > MR 458 has a fairly long discussion about the restriction that no > > further commits must be made to the source CRTC or any of the other > > KMS objects reachable on its graph, while a writeback composition > > referencing that CRTC is still in flight. > > > > Daniel Vetter confirmed that interpretation. > > > > I think this means that unless you are extremely lucky that: > > > > (a) your hardware's writeback mechanism is synchronous with scanout, > > and (b) the fence fd manages to fire and get dispatched immediately > > upon scanout/writeback passing through the final scanline, and (c) > > there's a really large vertical back porch > > > > , there will be no time left to enqueue a page flip for the > > immediately succeeding vblank. > > > > Seems like this will almost always cut the frame achievable update > > rate on the main connector in half. > > > > Did I misinterpret something in there? Early results look like the > > kernel state machine gets confused (with VKMS anyway) if I queue up > > two writeback operations in flight at the same time. > > Hi Matt, > > I really don't know. If hardware and drivers require that, and cannot stream > at > full refresh rate, then there is not much we can do. > > Not much, because I got one idea: Weston could repaint pre-emptively > according to its own schedule, but KMS-flip only when the writeback situation > allows. That should reduce the time needed between the writeback > completion fence firing and the KMS deadline for the flip. > > VKMS might rely on the above rules, or maybe it's not fully developed, I'm not > sure. You'd have to ask its developers. OTOH, if all hardware drivers need the > above rules, then VKMS should too. Maybe it just needs to check and fail > better. > > > Thanks, > pq Okay. I think maybe it makes sense to figure out who originally added this kernel documentation and see whether the situation is really so grim. I'll see about writing something to whoever that was, perhaps with dri-devel CC'ed.
Re: Full-motion zero-copy screen capture in Weston
On Fri, 14 Jun 2024 18:36:57 + "Hoosier, Matt" wrote: > > Hmm. As I read through the history of the original support for > writeback screenshots > (https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458) > and get some initial results just trying to drive a steady stream of > writeback composition, I'm not sure this can work effectively. > > MR 458 has a fairly long discussion about the restriction that no > further commits must be made to the source CRTC or any of the other > KMS objects reachable on its graph, while a writeback composition > referencing that CRTC is still in flight. > > Daniel Vetter confirmed that interpretation. > > I think this means that unless you are extremely lucky that: > > (a) your hardware's writeback mechanism is synchronous with scanout, > and (b) the fence fd manages to fire and get dispatched immediately > upon scanout/writeback passing through the final scanline, and (c) > there's a really large vertical back porch > > , there will be no time left to enqueue a page flip for the > immediately succeeding vblank. > > Seems like this will almost always cut the frame achievable update > rate on the main connector in half. > > Did I misinterpret something in there? Early results look like the > kernel state machine gets confused (with VKMS anyway) if I queue up > two writeback operations in flight at the same time. Hi Matt, I really don't know. If hardware and drivers require that, and cannot stream at full refresh rate, then there is not much we can do. Not much, because I got one idea: Weston could repaint pre-emptively according to its own schedule, but KMS-flip only when the writeback situation allows. That should reduce the time needed between the writeback completion fence firing and the KMS deadline for the flip. VKMS might rely on the above rules, or maybe it's not fully developed, I'm not sure. You'd have to ask its developers. OTOH, if all hardware drivers need the above rules, then VKMS should too. Maybe it just needs to check and fail better. Thanks, pq pgpoe7g0nY5K_.pgp Description: OpenPGP digital signature
RE: Full-motion zero-copy screen capture in Weston
> -Original Message- > From: Pekka Paalanen > Sent: Thursday, June 13, 2024 3:32 AM > To: Hoosier, Matt > Cc: 's...@cmpwn.com' ; 'cont...@emersion.fr' > ; 'Marius Vlad' ; > 'wayland-devel@lists.freedesktop.org' de...@lists.freedesktop.org>; 'Daniel Stone' > Subject: Re: Full-motion zero-copy screen capture in Weston > > On Wed, 12 Jun 2024 21:35:48 + > "Hoosier, Matt" wrote: > > > > -Original Message- > > > From: Hoosier, Matt > > > Sent: Wednesday, June 12, 2024 8:37 AM > > > To: Pekka Paalanen > > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > > ; wayland-devel@lists.freedesktop.org; > > > Daniel Stone > > > Subject: RE: Full-motion zero-copy screen capture in Weston > > > > > > > -Original Message- > > > > From: Pekka Paalanen > > > > Sent: Wednesday, June 12, 2024 4:03 AM > > > > To: Hoosier, Matt > > > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > > > ; wayland-devel@lists.freedesktop.org; > > > > Daniel Stone > > > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > > > > > On Mon, 10 Jun 2024 14:18:39 + "Hoosier, Matt" > > > > wrote: > > > > > > > > > Yes, the native Linux driver for the hardware still does end up > > > > > being responsible for one or more planes. > > > > > > > > > > Other than trying to arrange the pieces so that there's some API > > > > > that offers the client an option to guarantee that the source of > > > > > the screen capture involves the writeback connector (similar to > > > > > what you've done with weston_output_capture), I don't really > > > > > think it would be a good idea to make Weston explicitly aware of > > > > > any of this funny hypervisor business going on. > > > > > > > > > > > > > I very much agree. > > > > > > Ack > > > > > > > > > > > > > > > The title on this email conversation was probably poorly chosen, > > > > > in retrospect. I'm not so much concerned with keeping absolutely > > > > > to a zero-copy mechanism as I am to using hardware mechanisms > > > > > (GL rendering, DRI writeback, hardware-accelerated blits as > > > > > necessary) all the way through. > > > > > > > > > > After seeing the way that the Pipewire backend handles streaming > > > > > (especially with > > > > > https://gitlab.freedesktop.org/wayland/weston/- > > > /merge_requests/1366), > > > > > I'm almost thinking that it would be preferable to maybe > > > > > structure the design of this feature something like this: > > > > > > > > > > * Add some sort of API on weston_output by which it can > > > > > advertise the ability to lay hands on the explicit renderbuffer (e.g. > > > > > gbm_surface_get_front_buffer()). This roughly equates to whether > > > > > it's a primary, non-nested backend. That is, DRM. > > > > > > > > > > * When processing the weston.ini mirror-of relationships at > > > > > startup, check whether the source output of the mirror-of > > > > > declaration supports that ability above. If so: > > > > > - Wire up a signal so that the source output announces each > > > > > newly rendered frame to any/all mirror-of outputs. > > > > > - The virtual output's backend allocates its own buffer pool > > > > > in exactly the same way that MR 1366 already does. > > > > > - Upon receipt of each signal announcing a new frame's > > > > > renderbuffer from the source output, the virtual output does a > > > > > very cheap > > > > > glBlitFramebuffer() to get the contents into its own buffer pool. > > > > > This avoids the possibility of an unresponsive client tying up > > > > > the source output's buffer. > > > > > > > > > > * If the source output isn't one that supports exposing the > > > > > underlying renderbuffer, then the mirror-of relationship > > > > > continues as with MR > > > > > 1476 just to invoke an explicit weston_renderer pass to draw the > > > > > correct logical contents. > > > > > > > > > > How does this
Re: Full-motion zero-copy screen capture in Weston
On Wed, Jun 12, 2024 at 09:35:48PM +, Hoosier, Matt wrote: > > -Original Message- > > From: Hoosier, Matt > > Sent: Wednesday, June 12, 2024 8:37 AM > > To: Pekka Paalanen > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > ; wayland-devel@lists.freedesktop.org; Daniel > > Stone > > Subject: RE: Full-motion zero-copy screen capture in Weston > > > > > -Original Message- > > > From: Pekka Paalanen > > > Sent: Wednesday, June 12, 2024 4:03 AM > > > To: Hoosier, Matt > > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > > ; wayland-devel@lists.freedesktop.org; Daniel > > > Stone > > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > > > On Mon, 10 Jun 2024 14:18:39 + > > > "Hoosier, Matt" wrote: > > > > > > > Yes, the native Linux driver for the hardware still does end up being > > > > responsible for one or more planes. > > > > > > > > Other than trying to arrange the pieces so that there's some API that > > > > offers the client an option to guarantee that the source of the screen > > > > capture involves the writeback connector (similar to what you've done > > > > with weston_output_capture), I don't really think it would be a good > > > > idea to make Weston explicitly aware of any of this funny hypervisor > > > > business going on. > > > > > > > > > > I very much agree. > > > > Ack > > > > > > > > > > > The title on this email conversation was probably poorly chosen, in > > > > retrospect. I'm not so much concerned with keeping absolutely to a > > > > zero-copy mechanism as I am to using hardware mechanisms (GL > > > > rendering, DRI writeback, hardware-accelerated blits as necessary) all > > > > the way through. > > > > > > > > After seeing the way that the Pipewire backend handles streaming > > > > (especially with > > > > https://gitlab.freedesktop.org/wayland/weston/- > > /merge_requests/1366), > > > > I'm almost thinking that it would be preferable to maybe structure the > > > > design of this feature something like this: > > > > > > > > * Add some sort of API on weston_output by which it can advertise the > > > > ability to lay hands on the explicit renderbuffer (e.g. > > > > gbm_surface_get_front_buffer()). This roughly equates to whether it's > > > > a primary, non-nested backend. That is, DRM. > > > > > > > > * When processing the weston.ini mirror-of relationships at startup, > > > > check whether the source output of the mirror-of declaration supports > > > > that ability above. If so: > > > > - Wire up a signal so that the source output announces each newly > > > > rendered frame to any/all mirror-of outputs. > > > > - The virtual output's backend allocates its own buffer pool in > > > > exactly the same way that MR 1366 already does. > > > > - Upon receipt of each signal announcing a new frame's renderbuffer > > > > from the source output, the virtual output does a very cheap > > > > glBlitFramebuffer() to get the contents into its own buffer pool. > > > > This avoids the possibility of an unresponsive client tying up the > > > > source output's buffer. > > > > > > > > * If the source output isn't one that supports exposing the underlying > > > > renderbuffer, then the mirror-of relationship continues as with MR > > > > 1476 just to invoke an explicit weston_renderer pass to draw the > > > > correct logical contents. > > > > > > > > How does this strike you? > > > > > > Sorry, I don't understand how that idea is relevant to the KMS writeback > > case. > > > Did you imply that DRM-backend could deliver a KMS-writeback FB instead > > of > > > the rendered FB? > > > > Just for the same of argument, yes. But I take your point below that this > > entire > > idea to drive the mirroring output directly from the source output's > > rendering > > doesn't fit the plan for the mirror-of semantics. > > > > > > > > This is not the current plan for mirror-of. It does not allow the mirror > > > output > > to > > > run on its own pace independently of the source output. Re-using the > > > source > > > output's
Re: Full-motion zero-copy screen capture in Weston
On Wed, 12 Jun 2024 21:35:48 + "Hoosier, Matt" wrote: > > -Original Message- > > From: Hoosier, Matt > > Sent: Wednesday, June 12, 2024 8:37 AM > > To: Pekka Paalanen > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > ; wayland-devel@lists.freedesktop.org; Daniel > > Stone > > Subject: RE: Full-motion zero-copy screen capture in Weston > > > > > -Original Message- > > > From: Pekka Paalanen > > > Sent: Wednesday, June 12, 2024 4:03 AM > > > To: Hoosier, Matt > > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > > ; wayland-devel@lists.freedesktop.org; Daniel > > > Stone > > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > > > On Mon, 10 Jun 2024 14:18:39 + > > > "Hoosier, Matt" wrote: > > > > > > > Yes, the native Linux driver for the hardware still does end up being > > > > responsible for one or more planes. > > > > > > > > Other than trying to arrange the pieces so that there's some API that > > > > offers the client an option to guarantee that the source of the screen > > > > capture involves the writeback connector (similar to what you've done > > > > with weston_output_capture), I don't really think it would be a good > > > > idea to make Weston explicitly aware of any of this funny hypervisor > > > > business going on. > > > > > > > > > > I very much agree. > > > > Ack > > > > > > > > > > > The title on this email conversation was probably poorly chosen, in > > > > retrospect. I'm not so much concerned with keeping absolutely to a > > > > zero-copy mechanism as I am to using hardware mechanisms (GL > > > > rendering, DRI writeback, hardware-accelerated blits as necessary) all > > > > the way through. > > > > > > > > After seeing the way that the Pipewire backend handles streaming > > > > (especially with > > > > https://gitlab.freedesktop.org/wayland/weston/- > > /merge_requests/1366), > > > > I'm almost thinking that it would be preferable to maybe structure the > > > > design of this feature something like this: > > > > > > > > * Add some sort of API on weston_output by which it can advertise the > > > > ability to lay hands on the explicit renderbuffer (e.g. > > > > gbm_surface_get_front_buffer()). This roughly equates to whether it's > > > > a primary, non-nested backend. That is, DRM. > > > > > > > > * When processing the weston.ini mirror-of relationships at startup, > > > > check whether the source output of the mirror-of declaration supports > > > > that ability above. If so: > > > > - Wire up a signal so that the source output announces each newly > > > > rendered frame to any/all mirror-of outputs. > > > > - The virtual output's backend allocates its own buffer pool in > > > > exactly the same way that MR 1366 already does. > > > > - Upon receipt of each signal announcing a new frame's renderbuffer > > > > from the source output, the virtual output does a very cheap > > > > glBlitFramebuffer() to get the contents into its own buffer pool. > > > > This avoids the possibility of an unresponsive client tying up the > > > > source output's buffer. > > > > > > > > * If the source output isn't one that supports exposing the underlying > > > > renderbuffer, then the mirror-of relationship continues as with MR > > > > 1476 just to invoke an explicit weston_renderer pass to draw the > > > > correct logical contents. > > > > > > > > How does this strike you? > > > > > > Sorry, I don't understand how that idea is relevant to the KMS writeback > > case. > > > Did you imply that DRM-backend could deliver a KMS-writeback FB instead > > of > > > the rendered FB? > > > > Just for the same of argument, yes. But I take your point below that this > > entire > > idea to drive the mirroring output directly from the source output's > > rendering > > doesn't fit the plan for the mirror-of semantics. > > > > > > > > This is not the current plan for mirror-of. It does not allow the mirror > > > output > > to > > > run on its own pace independently of the source output. Re-using the >
RE: Full-motion zero-copy screen capture in Weston
> -Original Message- > From: Hoosier, Matt > Sent: Wednesday, June 12, 2024 8:37 AM > To: Pekka Paalanen > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > ; wayland-devel@lists.freedesktop.org; Daniel > Stone > Subject: RE: Full-motion zero-copy screen capture in Weston > > > -Original Message- > > From: Pekka Paalanen > > Sent: Wednesday, June 12, 2024 4:03 AM > > To: Hoosier, Matt > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > ; wayland-devel@lists.freedesktop.org; Daniel > > Stone > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > On Mon, 10 Jun 2024 14:18:39 + > > "Hoosier, Matt" wrote: > > > > > Yes, the native Linux driver for the hardware still does end up being > > > responsible for one or more planes. > > > > > > Other than trying to arrange the pieces so that there's some API that > > > offers the client an option to guarantee that the source of the screen > > > capture involves the writeback connector (similar to what you've done > > > with weston_output_capture), I don't really think it would be a good > > > idea to make Weston explicitly aware of any of this funny hypervisor > > > business going on. > > > > > > > I very much agree. > > Ack > > > > > > > The title on this email conversation was probably poorly chosen, in > > > retrospect. I'm not so much concerned with keeping absolutely to a > > > zero-copy mechanism as I am to using hardware mechanisms (GL > > > rendering, DRI writeback, hardware-accelerated blits as necessary) all > > > the way through. > > > > > > After seeing the way that the Pipewire backend handles streaming > > > (especially with > > > https://gitlab.freedesktop.org/wayland/weston/- > /merge_requests/1366), > > > I'm almost thinking that it would be preferable to maybe structure the > > > design of this feature something like this: > > > > > > * Add some sort of API on weston_output by which it can advertise the > > > ability to lay hands on the explicit renderbuffer (e.g. > > > gbm_surface_get_front_buffer()). This roughly equates to whether it's > > > a primary, non-nested backend. That is, DRM. > > > > > > * When processing the weston.ini mirror-of relationships at startup, > > > check whether the source output of the mirror-of declaration supports > > > that ability above. If so: > > > - Wire up a signal so that the source output announces each newly > > > rendered frame to any/all mirror-of outputs. > > > - The virtual output's backend allocates its own buffer pool in > > > exactly the same way that MR 1366 already does. > > > - Upon receipt of each signal announcing a new frame's renderbuffer > > > from the source output, the virtual output does a very cheap > > > glBlitFramebuffer() to get the contents into its own buffer pool. > > > This avoids the possibility of an unresponsive client tying up the > > > source output's buffer. > > > > > > * If the source output isn't one that supports exposing the underlying > > > renderbuffer, then the mirror-of relationship continues as with MR > > > 1476 just to invoke an explicit weston_renderer pass to draw the > > > correct logical contents. > > > > > > How does this strike you? > > > > Sorry, I don't understand how that idea is relevant to the KMS writeback > case. > > Did you imply that DRM-backend could deliver a KMS-writeback FB instead > of > > the rendered FB? > > Just for the same of argument, yes. But I take your point below that this > entire > idea to drive the mirroring output directly from the source output's rendering > doesn't fit the plan for the mirror-of semantics. > > > > > This is not the current plan for mirror-of. It does not allow the mirror > > output > to > > run on its own pace independently of the source output. Re-using the source > > output's rendered FB would also be a problem for color management. The FB > > is rendered for that output, and the color properties of the mirror may be > > different, needing an independent rendering anyway. > > > > The fundamental difference is who defines the properties of the stream. > > KMS writeback steam properties are necessarily defined by the KMS output. > > Mirror-of is for the opposite, for full flexibility. E.g. a remote mirror > > may not > > want to run at the full framerate, the physical monitor
RE: Full-motion zero-copy screen capture in Weston
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 12, 2024 4:03 AM > To: Hoosier, Matt > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > ; wayland-devel@lists.freedesktop.org; Daniel > Stone > Subject: Re: Full-motion zero-copy screen capture in Weston > > On Mon, 10 Jun 2024 14:18:39 + > "Hoosier, Matt" wrote: > > > Yes, the native Linux driver for the hardware still does end up being > > responsible for one or more planes. > > > > Other than trying to arrange the pieces so that there's some API that > > offers the client an option to guarantee that the source of the screen > > capture involves the writeback connector (similar to what you've done > > with weston_output_capture), I don't really think it would be a good > > idea to make Weston explicitly aware of any of this funny hypervisor > > business going on. > > > > I very much agree. Ack > > > The title on this email conversation was probably poorly chosen, in > > retrospect. I'm not so much concerned with keeping absolutely to a > > zero-copy mechanism as I am to using hardware mechanisms (GL > > rendering, DRI writeback, hardware-accelerated blits as necessary) all > > the way through. > > > > After seeing the way that the Pipewire backend handles streaming > > (especially with > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366), > > I'm almost thinking that it would be preferable to maybe structure the > > design of this feature something like this: > > > > * Add some sort of API on weston_output by which it can advertise the > > ability to lay hands on the explicit renderbuffer (e.g. > > gbm_surface_get_front_buffer()). This roughly equates to whether it's > > a primary, non-nested backend. That is, DRM. > > > > * When processing the weston.ini mirror-of relationships at startup, > > check whether the source output of the mirror-of declaration supports > > that ability above. If so: > > - Wire up a signal so that the source output announces each newly > > rendered frame to any/all mirror-of outputs. > > - The virtual output's backend allocates its own buffer pool in > > exactly the same way that MR 1366 already does. > > - Upon receipt of each signal announcing a new frame's renderbuffer > > from the source output, the virtual output does a very cheap > > glBlitFramebuffer() to get the contents into its own buffer pool. > > This avoids the possibility of an unresponsive client tying up the > > source output's buffer. > > > > * If the source output isn't one that supports exposing the underlying > > renderbuffer, then the mirror-of relationship continues as with MR > > 1476 just to invoke an explicit weston_renderer pass to draw the > > correct logical contents. > > > > How does this strike you? > > Sorry, I don't understand how that idea is relevant to the KMS writeback case. > Did you imply that DRM-backend could deliver a KMS-writeback FB instead of > the rendered FB? Just for the same of argument, yes. But I take your point below that this entire idea to drive the mirroring output directly from the source output's rendering doesn't fit the plan for the mirror-of semantics. > > This is not the current plan for mirror-of. It does not allow the mirror > output to > run on its own pace independently of the source output. Re-using the source > output's rendered FB would also be a problem for color management. The FB > is rendered for that output, and the color properties of the mirror may be > different, needing an independent rendering anyway. > > The fundamental difference is who defines the properties of the stream. > KMS writeback steam properties are necessarily defined by the KMS output. > Mirror-of is for the opposite, for full flexibility. E.g. a remote mirror may > not > want to run at the full framerate, the physical monitor resolution, or with > the > color capabilities of the source output in order to save bandwidth and improve > latency. Okay, understood. Although I'm a bit curious how you can say that one output "mirrors" another whose resolution doesn't even match. Maybe you have scaling in mind? > > It seems to me that we will need two different mechanisms for the two cases. I > believe KMS writeback streaming is worthwhile to support, but not via mirror- > of key. Maybe the writeback streaming should be built into the DRM-backend > as a special pipewire source? Then it would also be guaranteed to be KMS > writeback. It is some amount of code and testing duplication, but I think it > would be the simplest. Fair enough. I had t
Re: Full-motion zero-copy screen capture in Weston
On Mon, 10 Jun 2024 14:18:39 + "Hoosier, Matt" wrote: > Yes, the native Linux driver for the hardware still does end up being > responsible for one or more planes. > > Other than trying to arrange the pieces so that there's some API that > offers the client an option to guarantee that the source of the > screen capture involves the writeback connector (similar to what > you've done with weston_output_capture), I don't really think it > would be a good idea to make Weston explicitly aware of any of this > funny hypervisor business going on. > I very much agree. > The title on this email conversation was probably poorly chosen, in > retrospect. I'm not so much concerned with keeping absolutely to a > zero-copy mechanism as I am to using hardware mechanisms (GL > rendering, DRI writeback, hardware-accelerated blits as necessary) > all the way through. > > After seeing the way that the Pipewire backend handles streaming > (especially with > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366), > I'm almost thinking that it would be preferable to maybe structure > the design of this feature something like this: > > * Add some sort of API on weston_output by which it can advertise the > ability to lay hands on the explicit renderbuffer (e.g. > gbm_surface_get_front_buffer()). This roughly equates to whether it's > a primary, non-nested backend. That is, DRM. > > * When processing the weston.ini mirror-of relationships at startup, > check whether the source output of the mirror-of declaration supports > that ability above. If so: > - Wire up a signal so that the source output announces each newly > rendered frame to any/all mirror-of outputs. > - The virtual output's backend allocates its own buffer pool in > exactly the same way that MR 1366 already does. > - Upon receipt of each signal announcing a new frame's renderbuffer > from the source output, the virtual output does a very cheap > glBlitFramebuffer() to get the contents into its own buffer pool. > This avoids the possibility of an unresponsive client tying up the > source output's buffer. > > * If the source output isn't one that supports exposing the > underlying renderbuffer, then the mirror-of relationship continues as > with MR 1476 just to invoke an explicit weston_renderer pass to draw > the correct logical contents. > > How does this strike you? Sorry, I don't understand how that idea is relevant to the KMS writeback case. Did you imply that DRM-backend could deliver a KMS-writeback FB instead of the rendered FB? This is not the current plan for mirror-of. It does not allow the mirror output to run on its own pace independently of the source output. Re-using the source output's rendered FB would also be a problem for color management. The FB is rendered for that output, and the color properties of the mirror may be different, needing an independent rendering anyway. The fundamental difference is who defines the properties of the stream. KMS writeback steam properties are necessarily defined by the KMS output. Mirror-of is for the opposite, for full flexibility. E.g. a remote mirror may not want to run at the full framerate, the physical monitor resolution, or with the color capabilities of the source output in order to save bandwidth and improve latency. It seems to me that we will need two different mechanisms for the two cases. I believe KMS writeback streaming is worthwhile to support, but not via mirror-of key. Maybe the writeback streaming should be built into the DRM-backend as a special pipewire source? Then it would also be guaranteed to be KMS writeback. It is some amount of code and testing duplication, but I think it would be the simplest. I don't see KMS writeback streaming as specific to your curious virtualization case. I can imagine it being useful in general, to ensure that display controller output is correct for example, or when overall rendering efficiency is more important than optimal stream format. Thanks, pq pgpvurOu3w1aS.pgp Description: OpenPGP digital signature
Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)
Hi Matt, On Fri, 7 Jun 2024 at 16:30, Hoosier, Matt wrote: > Okay, makes sense that you don’t want to have to repeat the dependencies’ > builds for every CI test. I’m not arguing that you should – it was just more > a thought experiment to see whether riding Meson subprojects is a reasonable > idea for establishing a development environment. > > I get your point that that can become a deep rabbit hole. But it seems that > you didn’t have any need to build LLVM and similar just to support the > hand-built copy of Mesa that’s in the CI. Is there some reason why a deeper > set of transitive dependencies would be needed using Meson subprojects than > when building by hand? Seems like I could probably just mimic what you’ve > done. Maybe your point is that the CI is a very constrained environment > that’s known not to need ATI or llvmpipe, but a general developer situation > with physical machines would? Oh no, the CI environment absolutely needs llvmpipe! We install quite a few development packages (cf .gitlab-ci/debian-install.sh) into the CI environment though, so although we don't build LLVM, we do absolutely depend on distro LLVM development packages which aren't present in a clean distro install. You're completely right though that it makes no difference to the dependency chain whether the dependencies come from Meson subprojects or previous installs though. Cheers, Daniel
RE: Full-motion zero-copy screen capture in Weston
Yes, the native Linux driver for the hardware still does end up being responsible for one or more planes. Other than trying to arrange the pieces so that there's some API that offers the client an option to guarantee that the source of the screen capture involves the writeback connector (similar to what you've done with weston_output_capture), I don't really think it would be a good idea to make Weston explicitly aware of any of this funny hypervisor business going on. The title on this email conversation was probably poorly chosen, in retrospect. I'm not so much concerned with keeping absolutely to a zero-copy mechanism as I am to using hardware mechanisms (GL rendering, DRI writeback, hardware-accelerated blits as necessary) all the way through. After seeing the way that the Pipewire backend handles streaming (especially with https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366), I'm almost thinking that it would be preferable to maybe structure the design of this feature something like this: * Add some sort of API on weston_output by which it can advertise the ability to lay hands on the explicit renderbuffer (e.g. gbm_surface_get_front_buffer()). This roughly equates to whether it's a primary, non-nested backend. That is, DRM. * When processing the weston.ini mirror-of relationships at startup, check whether the source output of the mirror-of declaration supports that ability above. If so: - Wire up a signal so that the source output announces each newly rendered frame to any/all mirror-of outputs. - The virtual output's backend allocates its own buffer pool in exactly the same way that MR 1366 already does. - Upon receipt of each signal announcing a new frame's renderbuffer from the source output, the virtual output does a very cheap glBlitFramebuffer() to get the contents into its own buffer pool. This avoids the possibility of an unresponsive client tying up the source output's buffer. * If the source output isn't one that supports exposing the underlying renderbuffer, then the mirror-of relationship continues as with MR 1476 just to invoke an explicit weston_renderer pass to draw the correct logical contents. How does this strike you? -Matt > -Original Message- > From: Pekka Paalanen > Sent: Monday, June 10, 2024 3:03 AM > To: Hoosier, Matt > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > ; wayland-devel@lists.freedesktop.org > Subject: Re: Full-motion zero-copy screen capture in Weston > > On Fri, 7 Jun 2024 14:16:32 + > "Hoosier, Matt" wrote: > > > > What do you mean you can capture all virtual machines with KMS > > > writeback? > > > > > > What's the architecture there? How do virtual machines access KMS > > > hardware? Why would Weston be able to capture their outputs at all? > > > > The world of virtualization on commercially supported embedded SOCs > > for big-scale production use is wild. Every vendor typically has only > > a narrow range of supported hypervisors. Usually, one -- and an > > in-house model at that. There will typically be at least one bizarre > > twist on the virtualization method for display controllers. > > > > One fad is for one of the virtual machines -- typically, the one > > running a normal-style GNU/Linux Yocto system -- to own privileged I/O > > maps of most of the hardware, and it more or less runs the same > > drivers inside this VM that the SOC maker has already written for > > their bare-metal Linux deployment. Most hardware peripherals are just > > exposed to the other guest VMs by having the privileged Linux VM host > > export some sort of hypervisor-integrated VirtIO-style backend for the > > hardware. The guests see VirtIO devices. This approach goes by the > > name of "paravirtualization". > > > > But for graphics and display, there is almost always some additional > > mechanism to sidestep this pure paravirtualization because it's > > perceived as too expensive. So the vendor may do something like > > designate some subset of planes on each connector to be "directly" > > manipulated by the non-GNU/Linux guest VMs. The hypervisor executive > > runs a tiny little server that receives the stream of plane updates, > > and during the vsync it programs the appropriate display controller > > hardware registers to refer to the new frame's contents. It's very > > limited -- the guests VMs whose scene updates are couched using this > > mechanism are not able to do modesets or reconfigure the overall DRI > > scene topology. > > > > The key point here is that because Linux is running a full physical > > driver, the writeback connector gets the results of blending all the > > layers -- e
Re: Full-motion zero-copy screen capture in Weston
On Fri, 7 Jun 2024 14:16:32 + "Hoosier, Matt" wrote: > > What do you mean you can capture all virtual machines with KMS > > writeback? > > > > What's the architecture there? How do virtual machines access KMS > > hardware? Why would Weston be able to capture their outputs at all? > > The world of virtualization on commercially supported embedded SOCs > for big-scale production use is wild. Every vendor typically has only > a narrow range of supported hypervisors. Usually, one -- and an > in-house model at that. There will typically be at least one bizarre > twist on the virtualization method for display controllers. > > One fad is for one of the virtual machines -- typically, the one > running a normal-style GNU/Linux Yocto system -- to own privileged > I/O maps of most of the hardware, and it more or less runs the same > drivers inside this VM that the SOC maker has already written for > their bare-metal Linux deployment. Most hardware peripherals are just > exposed to the other guest VMs by having the privileged Linux VM host > export some sort of hypervisor-integrated VirtIO-style backend for > the hardware. The guests see VirtIO devices. This approach goes by > the name of "paravirtualization". > > But for graphics and display, there is almost always some additional > mechanism to sidestep this pure paravirtualization because it's > perceived as too expensive. So the vendor may do something like > designate some subset of planes on each connector to be "directly" > manipulated by the non-GNU/Linux guest VMs. The hypervisor executive > runs a tiny little server that receives the stream of plane updates, > and during the vsync it programs the appropriate display controller > hardware registers to refer to the new frame's contents. It's very > limited -- the guests VMs whose scene updates are couched using this > mechanism are not able to do modesets or reconfigure the overall DRI > scene topology. > > The key point here is that because Linux is running a full physical > driver, the writeback connector gets the results of blending all the > layers -- even those whose contents are programmed using the awkward > side channel. > > I'm not a big fan on this approach. But it is there, and I'd like to > cope with it. I have a use-case that requires Linux to get a complete > picture of the physical contents getting scanned out by the connector. > I see. On such connectors, does Weston still paint at least one KMS plane? If we can pretend that the connector is still a normal output for Weston, just with less planes, I feel that this should be implementable in upstream Weston. Thanks, pq pgpqzxgORl36l.pgp Description: OpenPGP digital signature
RE: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)
Hi Daniel, Okay, makes sense that you don’t want to have to repeat the dependencies’ builds for every CI test. I’m not arguing that you should – it was just more a thought experiment to see whether riding Meson subprojects is a reasonable idea for establishing a development environment. I get your point that that can become a deep rabbit hole. But it seems that you didn’t have any need to build LLVM and similar just to support the hand-built copy of Mesa that’s in the CI. Is there some reason why a deeper set of transitive dependencies would be needed using Meson subprojects than when building by hand? Seems like I could probably just mimic what you’ve done. Maybe your point is that the CI is a very constrained environment that’s known not to need ATI or llvmpipe, but a general developer situation with physical machines would? -Matt From: Daniel Stone Sent: Friday, June 7, 2024 10:17 AM To: Hoosier, Matt Cc: Pekka Paalanen ; Marius Vlad ; wayland-devel@lists.freedesktop.org Subject: Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston) Hi Matt, On Fri, 7 Jun 2024 at 15: 30, Hoosier, Matt wrote: > Would Meson’s dependency wrapping capabilities be a viable solution here? I think that most of Weston’s dependencies that have aggressive version jQcmQRYFpfptBannerStart Hi Matt, On Fri, 7 Jun 2024 at 15:30, Hoosier, Matt mailto:matt.hoos...@garmin.com>> wrote: > Would Meson’s dependency wrapping capabilities be a viable solution here? I > think that most of Weston’s dependencies that have aggressive version > requirements are themselves also Meson projects. > > The Weston CI configuration builds a bunch of its dependencies (Mesa, libdrm, > libwayland …) manually. I wonder why Meson wrapping was not used for this? We don't want to rebuild Mesa every time. We could've built it as a subproject and cached it, but it didn't seem to offer much any advantage over just installing it into the system. We could probably add some subprojects, but you'd probably end up pulling in more components as well - e.g. if you want to run Mesa with its software renderer or the AMD drivers, you'll also need to use LLVM - and at what point does your easy subproject build turn into, well, a full distribution? I guess one thing we could do is to jazz the CI build up a little so it's easier to pull the OCI and run it inside a toolbox, as well as reuse those scripts locally. Cheers, Daniel
Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)
Hi Matt, On Fri, 7 Jun 2024 at 15:30, Hoosier, Matt wrote: > Would Meson’s dependency wrapping capabilities be a viable solution here? I > think that most of Weston’s dependencies that have aggressive version > requirements are themselves also Meson projects. > > The Weston CI configuration builds a bunch of its dependencies (Mesa, libdrm, > libwayland …) manually. I wonder why Meson wrapping was not used for this? We don't want to rebuild Mesa every time. We could've built it as a subproject and cached it, but it didn't seem to offer much any advantage over just installing it into the system. We could probably add some subprojects, but you'd probably end up pulling in more components as well - e.g. if you want to run Mesa with its software renderer or the AMD drivers, you'll also need to use LLVM - and at what point does your easy subproject build turn into, well, a full distribution? I guess one thing we could do is to jazz the CI build up a little so it's easier to pull the OCI and run it inside a toolbox, as well as reuse those scripts locally. Cheers, Daniel
RE: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)
Would Meson’s dependency wrapping capabilities be a viable solution here? I think that most of Weston’s dependencies that have aggressive version requirements are themselves also Meson projects. The Weston CI configuration builds a bunch of its dependencies (Mesa, libdrm, libwayland …) manually. I wonder why Meson wrapping was not used for this? -Matt From: Hoosier, Matt Sent: Wednesday, June 5, 2024 7:44 AM To: Daniel Stone ; Pekka Paalanen Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad ; wayland-devel@lists.freedesktop.org Subject: Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston) Thanks, everybody. After some trial and error, I find that if I install seatd in the host and the seatd dev package in the Toolbox container and I then symlink the host seatd socket into /tmp on the container, Weston seems to start up okay on my physical KMS connectors: user@host:~$ toolbox enter … user@toolbox:~$ sudo ln -s /run/host/run/seatd.socket /run/ user@toolbox:~$ weston --backend=drm -Matt From: Daniel Stone mailto:dan...@fooishbar.org>> Date: Wednesday, June 5, 2024 at 5:07 AM To: Pekka Paalanen mailto:pekka.paala...@collabora.com>> Cc: "Hoosier, Matt" mailto:matt.hoos...@garmin.com>>, "s...@cmpwn.com<mailto:s...@cmpwn.com>" mailto:s...@cmpwn.com>>, "cont...@emersion.fr<mailto:cont...@emersion.fr>" mailto:cont...@emersion.fr>>, Marius Vlad mailto:marius.v...@collabora.com>>, "wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org>" mailto:wayland-devel@lists.freedesktop.org>> Subject: Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston) Hi, On Wed, 5 Jun 2024 at 09: 09, Pekka Paalanen wrote: > On Tue, 4 Jun 2024 20: 33: 48 + > "Hoosier, Matt" wrote: > > Tactical question: I somehow missed until Hi, On Wed, 5 Jun 2024 at 09:09, Pekka Paalanen mailto:pekka.paala...@collabora.com>> wrote: > On Tue, 4 Jun 2024 20:33:48 + > "Hoosier, Matt" mailto:matt.hoos...@garmin.com>> > wrote: > > Tactical question: I somehow missed until this point that the remote > > and pipewire plugins will only run if the DRM backend is being used. > > > > But the DRM backend *really* doesn't want to start nowadays unless > > you're running on a system with seatd and/or logind available. > > Toolbox [1] is the de facto way to develop on bleeding edge copies of > > components these days. But it logind and seatd aren't exposed into it. > > > > How do Weston people interactively develop on the Weston DRM backend > > nowadays? > > > > [1] > > https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2SJoQzfs$<https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2SJoQzfs$> > > I'm doing it old-school on my workstation, without any containers. What > dependencies my distribution does not provide, I build and install > manually into a prefix under $HOME: > > https://urldefense.com/v3/__https://www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2Y5E0gB4$<https://urldefense.com/v3/__https:/www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2Y5E0gB4$> > > The "clean and reliable" is probably outdated in this era of > containers... Yes, doing it in containers is a little bit tricky since it's not exactly the design case. Honestly, on my Silverblue systems, I just install a bunch of relevant dependencies into the system image with rpm-ostree, and have a pile of self-built dependencies in a local prefix. This might give you some insight however: https://urldefense.com/v3/__https://github.com/containers/toolbox/issues/992__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK21Tr-34M$<https://urldefense.com/v3/__https:/github.com/containers/toolbox/issues/992__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK21Tr-34M$> It probably needs some minor changes in Weston but does at least seem doable ... Cheers, Daniel
Re: Full-motion zero-copy screen capture in Weston
> What do you mean you can capture all virtual machines with KMS writeback? > > What's the architecture there? How do virtual machines access KMS hardware? Why would Weston be able to capture their outputs at all? The world of virtualization on commercially supported embedded SOCs for big-scale production use is wild. Every vendor typically has only a narrow range of supported hypervisors. Usually, one -- and an in-house model at that. There will typically be at least one bizarre twist on the virtualization method for display controllers. One fad is for one of the virtual machines -- typically, the one running a normal-style GNU/Linux Yocto system -- to own privileged I/O maps of most of the hardware, and it more or less runs the same drivers inside this VM that the SOC maker has already written for their bare-metal Linux deployment. Most hardware peripherals are just exposed to the other guest VMs by having the privileged Linux VM host export some sort of hypervisor-integrated VirtIO-style backend for the hardware. The guests see VirtIO devices. This approach goes by the name of "paravirtualization". But for graphics and display, there is almost always some additional mechanism to sidestep this pure paravirtualization because it's perceived as too expensive. So the vendor may do something like designate some subset of planes on each connector to be "directly" manipulated by the non-GNU/Linux guest VMs. The hypervisor executive runs a tiny little server that receives the stream of plane updates, and during the vsync it programs the appropriate display controller hardware registers to refer to the new frame's contents. It's very limited -- the guests VMs whose scene updates are couched using this mechanism are not able to do modesets or reconfigure the overall DRI scene topology. The key point here is that because Linux is running a full physical driver, the writeback connector gets the results of blending all the layers -- even those whose contents are programmed using the awkward side channel. I'm not a big fan on this approach. But it is there, and I'd like to cope with it. I have a use-case that requires Linux to get a complete picture of the physical contents getting scanned out by the connector. -Matt On 6/3/24, 3:54 AM, "Pekka Paalanen" mailto:pekka.paala...@collabora.com>> wrote: On Fri, 31 May 2024 13:26:12 + "Hoosier, Matt" mailto:matt.hoos...@garmin.com>> wrote: > > My goal is to implement this screen capture with a guarantee that the > copy comes from a KMS writeback connector. I know this sounds like an > odd thing to insist on. Let's say that in my industry, the system is > rarely only running Linux directly on the bare metal. Using the > writeback hardware on the display controller allows to get a copy of > content from all the virtual machines in the system. > What do you mean you can capture all virtual machines with KMS writeback? What's the architecture there? How do virtual machines access KMS hardware? Why would Weston be able to capture their outputs at all? > Frankly, weston_output_capture_v1's model that clients allocate the > buffers would make it very difficult to support efficient screen > capture for more than one simultaneous client. You can only target > one writeback framebuffer per page flip. Having the compositor manage > the buffers' lifetimes and just publishing out handles (in the style > of those two wlr extensions) to those probably fits better. That's certainly true. The disadvantage is that buffer allocations are accounted to the compositor (which can manage its own memory consumption, sure), and either the compositor allocates a new buffer for every frame (possibly serious overhead) or it needs to wait for all consumers to tell that they are done with the buffer before it can be used again. Clients might hold on to the buffer indefinitely or just a little too long, which is the risk. Thanks, pq
Re: [ANNOUNCE] Weston 13.0.1
Hi all, Further update on this, some folks reported that 13.0.1 tag was wrong, which prompted a new 13.0.2 point release. I managed to trip a few issues with the release script again and that one is botched as well. I've sent out a recent announcement for 13.0.3 so please use that one as the latest stable point release. Apologies if this caused issues/inconsistencies, but there were some cumulative factors that lead to this. On Tue, Apr 23, 2024 at 08:07:41PM +0300, Marius Vlad wrote: > Hi all, > > Someone pointed out that the tag was wrong, pointing apparently to > main branch. Had to delete the tag and re-create it. Should now point > correctly. All links are the same, with the same files. > > Thanks for heads-up Dylan! > > On Tue, Apr 23, 2024 at 06:55:45PM +0300, Marius Vlad wrote: > > Hi all, > > > > Weston 13.0.1, a bug fix release for 13.0.0 has been released. > > > > Full changelog below: > > > > Arnaud Vrac (3): > > desktop-shell: clamp view alpha correctly > > desktop-shell: set proper curtain size when no output is created yet > > clients/desktop-shell: fix crash on init when panel is disabled > > > > Derek Foreman (3): > > gl-renderer: apply output transform before readback in repaint > > libweston: Clip damage to paint node visible region > > libweston/backends: Move damage flush into backends > > > > Jeffy Chen (2): > > renderer-gl: Fix wrong stride error when reading pixels > > desktop-shell: Avoid using maximized size in fullscreen state > > > > Marius Vlad (3): > > backend-pipewire: Move region initialization at the start > > libweston: Add paint node destruction into weston_layer_entry_remove() > > build: bump to version 13.0.1 for the point release > > > > Michael Olbrich (1): > > ivi-shell: clear seat focus if necessary when a surface is destroyed > > > > Philipp Zabel (1): > > libweston-desktop: Work around crash when opening popup menu > > > > Ray Smith (1): > > backend-drm: fix confused fallback format handling > > > > Robert Mader (2): > > backend-drm: Don't force non-opaque overlays to primary plane > > backend-drm: Sort planes by faked zpos > > > > Wujian Sun (1): > > libweston-desktop: Fix weston crash when lost the shsurf > > > > git tag: 13.0.1 > > > > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz > > SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a > > weston-13.0.1.tar.xz > > SHA512: > > 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122 > > weston-13.0.1.tar.xz > > PGP: > > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig > > > > signature.asc Description: PGP signature
[ANNOUNCE] weston 13.0.3
Hi all, Due to a few issues (script missing to account for git log @upstream.. command, glab creating automatically tags with the default main branch when not find a remote tag, and me not having a branch entry in the git config), it made it so that 13.0.1 and 13.0.2 point releases were released based on the main branch rather than the correct, 13 branch. For the 13.0.1 point release I assumed that I could get away with it just by deleting and re-creating, but apparently some mirrors were quick to pick up that, and the recent fdo update made it so that people hit that mirror instead of fdo and managed use the wrong tag. That required a new 13.0.2 point release, but because I dismissed the initial issue, assuming that it was just something I might have done temporarily, I hit this again. The 13.0.2 release is still available, but now states the same thing as here, and that it is broken and recommends everyone to use the latest one, 13.0.3. I'm including the changelog from 13.0.1 until now (there no new changes just the meson.build bumps and a fix for CI to be able to do the release), but here there are: Marius Vlad (2): build: bump to version 13.0.2 for the point release build: bump to version 13.0.3 for the point release Pekka Paalanen (1): CI: work around LeakSanitizer crashes with use_tls=0 git tag: 13.0.3 https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.3/downloads/weston-13.0.3.tar.xz SHA256: 27f68d96e3b97d98daadef13a202356524924fa381418fa6716b9136ef099093 weston-13.0.3.tar.xz SHA512: 60e655b57cf418902ec6e4371883354165241d9a99a712aabe2165e11ac190dec22836fd885f5178def5416dc5f00e70042b022c96a8e0aa74827bbd4563f9cb weston-13.0.3.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.3/downloads/weston-13.0.3.tar.xz.sig signature.asc Description: PGP signature
Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)
Thanks, everybody. After some trial and error, I find that if I install seatd in the host and the seatd dev package in the Toolbox container and I then symlink the host seatd socket into /tmp on the container, Weston seems to start up okay on my physical KMS connectors: user@host:~$ toolbox enter … user@toolbox:~$ sudo ln -s /run/host/run/seatd.socket /run/ user@toolbox:~$ weston --backend=drm -Matt From: Daniel Stone Date: Wednesday, June 5, 2024 at 5:07 AM To: Pekka Paalanen Cc: "Hoosier, Matt" , "s...@cmpwn.com" , "cont...@emersion.fr" , Marius Vlad , "wayland-devel@lists.freedesktop.org" Subject: Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston) Hi, On Wed, 5 Jun 2024 at 09: 09, Pekka Paalanen wrote: > On Tue, 4 Jun 2024 20: 33: 48 + > "Hoosier, Matt" wrote: > > Tactical question: I somehow missed until Hi, On Wed, 5 Jun 2024 at 09:09, Pekka Paalanen wrote: > On Tue, 4 Jun 2024 20:33:48 + > "Hoosier, Matt" wrote: > > Tactical question: I somehow missed until this point that the remote > > and pipewire plugins will only run if the DRM backend is being used. > > > > But the DRM backend *really* doesn't want to start nowadays unless > > you're running on a system with seatd and/or logind available. > > Toolbox [1] is the de facto way to develop on bleeding edge copies of > > components these days. But it logind and seatd aren't exposed into it. > > > > How do Weston people interactively develop on the Weston DRM backend > > nowadays? > > > > [1] > > https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2SJoQzfs$<https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2SJoQzfs$> > > I'm doing it old-school on my workstation, without any containers. What > dependencies my distribution does not provide, I build and install > manually into a prefix under $HOME: > > https://urldefense.com/v3/__https://www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2Y5E0gB4$<https://urldefense.com/v3/__https:/www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2Y5E0gB4$> > > The "clean and reliable" is probably outdated in this era of > containers... Yes, doing it in containers is a little bit tricky since it's not exactly the design case. Honestly, on my Silverblue systems, I just install a bunch of relevant dependencies into the system image with rpm-ostree, and have a pile of self-built dependencies in a local prefix. This might give you some insight however: https://urldefense.com/v3/__https://github.com/containers/toolbox/issues/992__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK21Tr-34M$<https://urldefense.com/v3/__https:/github.com/containers/toolbox/issues/992__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK21Tr-34M$> It probably needs some minor changes in Weston but does at least seem doable ... Cheers, Daniel
Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)
Hi, On Wed, 5 Jun 2024 at 09:09, Pekka Paalanen wrote: > On Tue, 4 Jun 2024 20:33:48 + > "Hoosier, Matt" wrote: > > Tactical question: I somehow missed until this point that the remote > > and pipewire plugins will only run if the DRM backend is being used. > > > > But the DRM backend *really* doesn't want to start nowadays unless > > you're running on a system with seatd and/or logind available. > > Toolbox [1] is the de facto way to develop on bleeding edge copies of > > components these days. But it logind and seatd aren't exposed into it. > > > > How do Weston people interactively develop on the Weston DRM backend > > nowadays? > > > > [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/ > > I'm doing it old-school on my workstation, without any containers. What > dependencies my distribution does not provide, I build and install > manually into a prefix under $HOME: > > https://www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/ > > The "clean and reliable" is probably outdated in this era of > containers... Yes, doing it in containers is a little bit tricky since it's not exactly the design case. Honestly, on my Silverblue systems, I just install a bunch of relevant dependencies into the system image with rpm-ostree, and have a pile of self-built dependencies in a local prefix. This might give you some insight however: https://github.com/containers/toolbox/issues/992 It probably needs some minor changes in Weston but does at least seem doable ... Cheers, Daniel
Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)
On Tue, 4 Jun 2024 20:33:48 + "Hoosier, Matt" wrote: > Tactical question: I somehow missed until this point that the remote > and pipewire plugins will only run if the DRM backend is being used. > > But the DRM backend *really* doesn't want to start nowadays unless > you're running on a system with seatd and/or logind available. > Toolbox [1] is the de facto way to develop on bleeding edge copies of > components these days. But it logind and seatd aren't exposed into it. > > How do Weston people interactively develop on the Weston DRM backend > nowadays? > > [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/ Hi Matt, I'm doing it old-school on my workstation, without any containers. What dependencies my distribution does not provide, I build and install manually into a prefix under $HOME: https://www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/ The "clean and reliable" is probably outdated in this era of containers... There is also 'meson devenv', but since I need multiple manually built projects in the same session, I haven't really looked into how to make that work for me. https://mesonbuild.com/Commands.html#devenv When launching Weston, I have two different cases. Both need my prefix installed environment as in the blog post. - When I want to run on the same gfx card as my desktop, I VT-switch to a text mode login, log in, enter the environment, and simply run 'weston'. This gets input and output devices from logind. - When I want to run on my dedicated testing gfx card (no desktop there), I do it from a terminal window from my normal desktop: enter the environment, and run 'SEATD_VTBOUND=0 weston -Bdrm-backend.so --seat=seat-insecure -i0'. This requires prior setup: https://wayland.pages.freedesktop.org/weston/toc/running-weston.html#running-weston-on-a-different-seat-on-a-stand-alone-back-end It uses libseat's built-in backend, so no seatd and no logind. The prior setup gives my user direct access to the necessary device nodes. I have a separate monitor, keyboard and mouse reserved for this. Thanks, pq pgpi5sye1gU6b.pgp Description: OpenPGP digital signature
Re: Full-motion zero-copy screen capture in Weston
Hi, Note that systemd-udev will not work in a container. That usually has the side effect of libinput not working either. On Tue, Jun 04, 2024 at 08:33:48PM +, Hoosier, Matt wrote: > Tactical question: I somehow missed until this point that the remote and > pipewire plugins will only run if the DRM backend is being used. > > But the DRM backend *really* doesn't want to start nowadays unless you're > running on a system with seatd and/or logind available. Toolbox [1] is the de > facto way to develop on bleeding edge copies of components these days. But it > logind and seatd aren't exposed into it. > > How do Weston people interactively develop on the Weston DRM backend nowadays? With either seatd or logind. I suspect people use containers to build but run it on the device. > > [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/ > > > -Original Message- > > From: Pekka Paalanen > > Sent: Tuesday, June 4, 2024 3:20 AM > > To: Hoosier, Matt > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > ; wayland-devel@lists.freedesktop.org > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > On Mon, 3 Jun 2024 17:57:18 + > > "Hoosier, Matt" wrote: > > > > > > What do you mean you can capture all virtual machines with KMS > > > > writeback? > > > > > > > > What's the architecture there? How do virtual machines access KMS > > > > hardware? Why would Weston be able to capture their outputs at all? > > > > > > > > > > I hope to have more to say about this shortly. > > > > I'm interested because I worry whether it will work. I don't see how it > > could > > work with the traditional display controllers and DRM drivers. > > > > Maybe some kind of hardware assisted plane "leasing" that works around the > > DRM KMS software model limitations? > > > > > > The disadvantage is that buffer allocations are accounted to the > > > > compositor (which can manage its own memory consumption, sure), and > > > > either the compositor allocates a new buffer for every frame > > > > (possibly serious overhead) or it needs to wait for all consumers to > > > > tell that they are done with the buffer before it can be used again. > > > > Clients might hold on to the buffer indefinitely or just a little > > > > too long, which is the risk. > > > > > > It seems to me this would be a risk of the existing Pipewire backend, > > > no? At least, if I understood the buffering model of the dmabuf MR > > > that Marius linked earlier. > > > > > > > I haven't looked at any of that, so I can't say. I don't know if pipewire > > is only > > allocate-send-forget, or does it include consumers signalling they are done > > to > > allow re-use as well. Or maybe the sources trust that rotating N buffers is > > always enough, and if a sink needs the data for longer, it will make a copy > > in > > time. > > > > It's a trade-off. Sometimes the overhead of allocate-send-forget with the > > risk > > of OOM (KMS writeback might require a specific type of memory that could be > > scarce), maybe even with an added copy to avoid exhausting writeback- > > capable memory, may be justified. > > > > > > Thanks, > > pq signature.asc Description: PGP signature
RE: Full-motion zero-copy screen capture in Weston
Tactical question: I somehow missed until this point that the remote and pipewire plugins will only run if the DRM backend is being used. But the DRM backend *really* doesn't want to start nowadays unless you're running on a system with seatd and/or logind available. Toolbox [1] is the de facto way to develop on bleeding edge copies of components these days. But it logind and seatd aren't exposed into it. How do Weston people interactively develop on the Weston DRM backend nowadays? [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/ > -Original Message- > From: Pekka Paalanen > Sent: Tuesday, June 4, 2024 3:20 AM > To: Hoosier, Matt > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > ; wayland-devel@lists.freedesktop.org > Subject: Re: Full-motion zero-copy screen capture in Weston > > On Mon, 3 Jun 2024 17:57:18 + > "Hoosier, Matt" wrote: > > > > What do you mean you can capture all virtual machines with KMS > > > writeback? > > > > > > What's the architecture there? How do virtual machines access KMS > > > hardware? Why would Weston be able to capture their outputs at all? > > > > > > > I hope to have more to say about this shortly. > > I'm interested because I worry whether it will work. I don't see how it could > work with the traditional display controllers and DRM drivers. > > Maybe some kind of hardware assisted plane "leasing" that works around the > DRM KMS software model limitations? > > > > The disadvantage is that buffer allocations are accounted to the > > > compositor (which can manage its own memory consumption, sure), and > > > either the compositor allocates a new buffer for every frame > > > (possibly serious overhead) or it needs to wait for all consumers to > > > tell that they are done with the buffer before it can be used again. > > > Clients might hold on to the buffer indefinitely or just a little > > > too long, which is the risk. > > > > It seems to me this would be a risk of the existing Pipewire backend, > > no? At least, if I understood the buffering model of the dmabuf MR > > that Marius linked earlier. > > > > I haven't looked at any of that, so I can't say. I don't know if pipewire is > only > allocate-send-forget, or does it include consumers signalling they are done to > allow re-use as well. Or maybe the sources trust that rotating N buffers is > always enough, and if a sink needs the data for longer, it will make a copy in > time. > > It's a trade-off. Sometimes the overhead of allocate-send-forget with the risk > of OOM (KMS writeback might require a specific type of memory that could be > scarce), maybe even with an added copy to avoid exhausting writeback- > capable memory, may be justified. > > > Thanks, > pq
Re: Full-motion zero-copy screen capture in Weston
On Mon, 3 Jun 2024 17:57:18 + "Hoosier, Matt" wrote: > > What do you mean you can capture all virtual machines with KMS > > writeback? > > > > What's the architecture there? How do virtual machines access KMS > > hardware? Why would Weston be able to capture their outputs at all? > > > > I hope to have more to say about this shortly. I'm interested because I worry whether it will work. I don't see how it could work with the traditional display controllers and DRM drivers. Maybe some kind of hardware assisted plane "leasing" that works around the DRM KMS software model limitations? > > The disadvantage is that buffer allocations are accounted to the > > compositor (which can manage its own memory consumption, sure), and > > either the compositor allocates a new buffer for every frame > > (possibly serious overhead) or it needs to wait for all consumers > > to tell that they are done with the buffer before it can be used > > again. Clients might hold on to the buffer indefinitely or just a > > little too long, which is the risk. > > It seems to me this would be a risk of the existing Pipewire backend, > no? At least, if I understood the buffering model of the dmabuf MR > that Marius linked earlier. > I haven't looked at any of that, so I can't say. I don't know if pipewire is only allocate-send-forget, or does it include consumers signalling they are done to allow re-use as well. Or maybe the sources trust that rotating N buffers is always enough, and if a sink needs the data for longer, it will make a copy in time. It's a trade-off. Sometimes the overhead of allocate-send-forget with the risk of OOM (KMS writeback might require a specific type of memory that could be scarce), maybe even with an added copy to avoid exhausting writeback-capable memory, may be justified. Thanks, pq pgpUuGG4KCRnG.pgp Description: OpenPGP digital signature
Re: Full-motion zero-copy screen capture in Weston
> What do you mean you can capture all virtual machines with KMS > writeback? > > What's the architecture there? How do virtual machines access KMS > hardware? Why would Weston be able to capture their outputs at all? I hope to have more to say about this shortly. > The disadvantage is that buffer allocations are accounted to the > compositor (which can manage its own memory consumption, sure), and > either the compositor allocates a new buffer for every frame (possibly > serious overhead) or it needs to wait for all consumers to tell that > they are done with the buffer before it can be used again. Clients > might hold on to the buffer indefinitely or just a little too long, > which is the risk. It seems to me this would be a risk of the existing Pipewire backend, no? At least, if I understood the buffering model of the dmabuf MR that Marius linked earlier. On 6/3/24, 3:54 AM, "Pekka Paalanen" mailto:pekka.paala...@collabora.com>> wrote: On Fri, 31 May 2024 13:26:12 + "Hoosier, Matt" mailto:matt.hoos...@garmin.com>> wrote: > > My goal is to implement this screen capture with a guarantee that the > copy comes from a KMS writeback connector. I know this sounds like an > odd thing to insist on. Let's say that in my industry, the system is > rarely only running Linux directly on the bare metal. Using the > writeback hardware on the display controller allows to get a copy of > content from all the virtual machines in the system. > What do you mean you can capture all virtual machines with KMS writeback? What's the architecture there? How do virtual machines access KMS hardware? Why would Weston be able to capture their outputs at all? > Frankly, weston_output_capture_v1's model that clients allocate the > buffers would make it very difficult to support efficient screen > capture for more than one simultaneous client. You can only target > one writeback framebuffer per page flip. Having the compositor manage > the buffers' lifetimes and just publishing out handles (in the style > of those two wlr extensions) to those probably fits better. That's certainly true. The disadvantage is that buffer allocations are accounted to the compositor (which can manage its own memory consumption, sure), and either the compositor allocates a new buffer for every frame (possibly serious overhead) or it needs to wait for all consumers to tell that they are done with the buffer before it can be used again. Clients might hold on to the buffer indefinitely or just a little too long, which is the risk. Thanks, pq
Re: Full-motion zero-copy screen capture in Weston
On Fri, 31 May 2024 13:26:12 + "Hoosier, Matt" wrote: > > My goal is to implement this screen capture with a guarantee that the > copy comes from a KMS writeback connector. I know this sounds like an > odd thing to insist on. Let's say that in my industry, the system is > rarely only running Linux directly on the bare metal. Using the > writeback hardware on the display controller allows to get a copy of > content from all the virtual machines in the system. > What do you mean you can capture all virtual machines with KMS writeback? What's the architecture there? How do virtual machines access KMS hardware? Why would Weston be able to capture their outputs at all? > Frankly, weston_output_capture_v1's model that clients allocate the > buffers would make it very difficult to support efficient screen > capture for more than one simultaneous client. You can only target > one writeback framebuffer per page flip. Having the compositor manage > the buffers' lifetimes and just publishing out handles (in the style > of those two wlr extensions) to those probably fits better. That's certainly true. The disadvantage is that buffer allocations are accounted to the compositor (which can manage its own memory consumption, sure), and either the compositor allocates a new buffer for every frame (possibly serious overhead) or it needs to wait for all consumers to tell that they are done with the buffer before it can be used again. Clients might hold on to the buffer indefinitely or just a little too long, which is the risk. Thanks, pq pgpKFYV6jmA3W.pgp Description: OpenPGP digital signature
Re: Full-motion zero-copy screen capture in Weston
Hi Matt, fös., 31. maí 2024 kl. 15:34 skrifaði Hoosier, Matt : > > Thanks, understood. I would expect that I need to take some care in > allocating a buffer that my DRM driver accepts for writeback, in this usage. > > > > Do I interpret right that the wlroots screencopy extension wants the client > to create a fresh zwlr_screencopy_frame_v1 for each successive frame? I > wonder then: > > > > * Whether this might lead to the possibility of dropped frames, if the client > doesn’t manage to send back the requests to start capture for frame N+1 soon > enough after the delivery of the copied buffer for frame N; and If you send a frame request as soon as you receive an update, frames will not be dropped. > * Will the explicit request for each frame via zwlr_screencopy_frame_v1:: > copy(), result in artificial redraws to satisfy the request? Ideally I would > just like to receive a passive copy of each frame that naturally got drawn by > the compositor. Perhaps with one artificial redraw at the very beginning of > the screencopy stream just to have a defined starting point. For wlr-screencopy-v1, you can use the the "copy_with_damage" request to avoid "artificial redraws". See: https://wayland.app/protocols/wlr-screencopy-unstable-v1#zwlr_screencopy_frame_v1:request:copy_with_damage For ext-screencopy-v1, when you create a session, a redraw may be required for the first frame. After that, only damaged frames are copied for that session. See: https://wayland.app/protocols/wayland-protocols/124 Regards, Andri
Re: Full-motion zero-copy screen capture in Weston
Thanks, understood. I would expect that I need to take some care in allocating a buffer that my DRM driver accepts for writeback, in this usage. Do I interpret right that the wlroots screencopy extension wants the client to create a fresh zwlr_screencopy_frame_v1 for each successive frame? I wonder then: * Whether this might lead to the possibility of dropped frames, if the client doesn’t manage to send back the requests to start capture for frame N+1 soon enough after the delivery of the copied buffer for frame N; and * Will the explicit request for each frame via zwlr_screencopy_frame_v1:: copy(), result in artificial redraws to satisfy the request? Ideally I would just like to receive a passive copy of each frame that naturally got drawn by the compositor. Perhaps with one artificial redraw at the very beginning of the screencopy stream just to have a defined starting point. -Matt From: Simon Ser Date: Friday, May 31, 2024 at 10:16 AM To: Andri Yngvason Cc: "Hoosier, Matt" , Pekka Paalanen , "s...@cmpwn.com" , Marius Vlad , "wayland-devel@lists.freedesktop.org" Subject: Re: Full-motion zero-copy screen capture in Weston On Friday, May 31st, 2024 at 16: 45, Simon Ser wrote: > > See: https: //urldefense. com/v3/__https: //gitlab. freedesktop. org/wayland/wayland-protocols/-/merge_requests/124__;!!EJc4YC3iFmQ!WaOP607PgstX4CpWrn4DV6X4TIDRrqQW5XEZfczyVDFZdkpmCfNDh0lUQetO5TuCK5ct4NVlCqcAz4-8ehlw$ On Friday, May 31st, 2024 at 16:45, Simon Ser wrote: > > See: > > https://urldefense.com/v3/__https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124__;!!EJc4YC3iFmQ!WaOP607PgstX4CpWrn4DV6X4TIDRrqQW5XEZfczyVDFZdkpmCfNDh0lUQetO5TuCK5ct4NVlCqcAz4-8ehlw$<https://urldefense.com/v3/__https:/gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124__;!!EJc4YC3iFmQ!WaOP607PgstX4CpWrn4DV6X4TIDRrqQW5XEZfczyVDFZdkpmCfNDh0lUQetO5TuCK5ct4NVlCqcAz4-8ehlw$> > > > > > My goal is to implement this screen capture with a guarantee that the > > > copy comes from a KMS writeback connector. I know this sounds like an odd > > > thing to insist on. Let's say that in my industry, the system is rarely > > > only running Linux directly on the bare metal. Using the writeback > > > hardware on the display controller allows to get a copy of content from > > > all the virtual machines in the system. > > > > Although the protocol is called "screencopy", it does not need to be > > implemented via copying. I don't think anything precludes drm > > write-back or rendering directly to the client-submitted buffers. > > Not sure that's true… With screencopy the client necessarily provides > buffers that the compositor copies into. Correction: Andri said that it should be possible to pass client-allocated buffers to the writeback connector. There might be allocation considerations to take care of, but it might work fine indeed.
Re: Full-motion zero-copy screen capture in Weston
On Friday, May 31st, 2024 at 16:45, Simon Ser wrote: > > See: > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124 > > > > > My goal is to implement this screen capture with a guarantee that the > > > copy comes from a KMS writeback connector. I know this sounds like an odd > > > thing to insist on. Let's say that in my industry, the system is rarely > > > only running Linux directly on the bare metal. Using the writeback > > > hardware on the display controller allows to get a copy of content from > > > all the virtual machines in the system. > > > > Although the protocol is called "screencopy", it does not need to be > > implemented via copying. I don't think anything precludes drm > > write-back or rendering directly to the client-submitted buffers. > > Not sure that's true… With screencopy the client necessarily provides > buffers that the compositor copies into. Correction: Andri said that it should be possible to pass client-allocated buffers to the writeback connector. There might be allocation considerations to take care of, but it might work fine indeed.
Re: Full-motion zero-copy screen capture in Weston
On Friday, May 31st, 2024 at 16:39, Andri Yngvason wrote: > Hi Matt, > > fös., 31. maí 2024 kl. 13:26 skrifaði Hoosier, Matt matt.hoos...@garmin.com: > > > Hi, > > > > Yeah. I agree that although I can prototype something quick and dirty here > > as a change to weston_output_capture_v1, it's probably not a good fit there. > > > > Drew or Simon, does either of > > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml > > or > > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml > > strike you as a good fit for the use-case of getting a streamed copy of an > > output? They seem very similar – not sure what differentiates them from > > each other. > > > I'd say ext-screencopy-v1 is pretty close to being complete. It is > designed for both single shot capture and screen casting. It has 2 > acks and it has been implemented in wlroots, cosmic and wayvnc. > > I would not recommend wlr-export-dmabuf for anything as it suffers > from synchronisation issues. There are no guarantees for life-times of > the dmabufs. wlr-screencopy works well enough, but ext-screencopy-v1 > is better. For fixing the sync issue, there is: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/121 But not enough interest it seems. > See: > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124 > > > My goal is to implement this screen capture with a guarantee that the copy > > comes from a KMS writeback connector. I know this sounds like an odd thing > > to insist on. Let's say that in my industry, the system is rarely only > > running Linux directly on the bare metal. Using the writeback hardware on > > the display controller allows to get a copy of content from all the virtual > > machines in the system. > > > Although the protocol is called "screencopy", it does not need to be > implemented via copying. I don't think anything precludes drm > write-back or rendering directly to the client-submitted buffers. Not sure that's true… With screencopy the client necessarily provides buffers that the compositor copies into.
Re: Full-motion zero-copy screen capture in Weston
Hi Matt, fös., 31. maí 2024 kl. 13:26 skrifaði Hoosier, Matt : > > Hi, > > Yeah. I agree that although I can prototype something quick and dirty here as > a change to weston_output_capture_v1, it's probably not a good fit there. > > Drew or Simon, does either of > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml > or > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml > strike you as a good fit for the use-case of getting a streamed copy of an > output? They seem very similar – not sure what differentiates them from each > other. > I'd say ext-screencopy-v1 is pretty close to being complete. It is designed for both single shot capture and screen casting. It has 2 acks and it has been implemented in wlroots, cosmic and wayvnc. I would not recommend wlr-export-dmabuf for anything as it suffers from synchronisation issues. There are no guarantees for life-times of the dmabufs. wlr-screencopy works well enough, but ext-screencopy-v1 is better. See: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124 > My goal is to implement this screen capture with a guarantee that the copy > comes from a KMS writeback connector. I know this sounds like an odd thing to > insist on. Let's say that in my industry, the system is rarely only running > Linux directly on the bare metal. Using the writeback hardware on the display > controller allows to get a copy of content from all the virtual machines in > the system. Although the protocol is called "screencopy", it does not need to be implemented via copying. I don't think anything precludes drm write-back or rendering directly to the client-submitted buffers. Regards, Andri
Re: Full-motion zero-copy screen capture in Weston
On Friday, May 31st, 2024 at 15:26, Hoosier, Matt wrote: > Drew or Simon, does either of > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml > or > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml > strike you as a good fit for the use-case of getting a streamed copy of an > output? They seem very similar – not sure what differentiates them from each > other. screencopy is designed around client-allocated buffers. For compositor-allocated buffers, export-dmabuf is what's used in the wlroots ecosystem. > My goal is to implement this screen capture with a guarantee that the copy > comes from a KMS writeback connector. I know this sounds like an odd thing to > insist on. Let's say that in my industry, the system is rarely only running > Linux directly on the bare metal. Using the writeback hardware on the display > controller allows to get a copy of content from all the virtual machines in > the system. > Frankly, weston_output_capture_v1's model that clients allocate the buffers > would make it very difficult to support efficient screen capture for more > than one simultaneous client. You can only target one writeback framebuffer > per page flip. Having the compositor manage the buffers' lifetimes and just > publishing out handles (in the style of those two wlr extensions) to those > probably fits better. IIRC Weston is not interested in supporting the wlroots protocol, they'd prefer to use e.g. PipeWire. Should be possible to pass the result of the writeback into a PipeWire stream. > From: Pekka Paalanen > Sent: Friday, May 31, 2024 3:02 AM > To: Hoosier, Matt > Cc: Marius Vlad; wayland-devel@lists.freedesktop.org > Subject: Re: Full-motion zero-copy screen capture in Weston > On Thu, 30 May 2024 13:40:15 + > "Hoosier, Matt" wrote: > > > Okay, interesting thoughts on all of that. > > > > I'm not sure how far I'm going to get toward a complete overhaul of > > the capture mechanism. Maybe it would be useful to know a couple > > things about the current one (weston_output_capture_v1), so that I > > don't commit mistakes that somebody already considered and guarded > > against: > > > > * Why was it explicitly picked only for still shots? I can image that > > it wouldn't have been a whole lot more work to design this API with a > > bounce-buffering scheme rather than a setup/do-it-once/destroy model. > > > > There was no need for streaming, as it was purely for the test suite. > > The test suite is very particular about when and how the shot is taken: > it must be produced by the defined source, and it must be produced on > the very next repaint of the output, exactly once. > > Did you mean a buffer pool (queueing/dequeueing) rather than > bounce-buffering? Sure. > > > * Why was wl_shm explicitly picked for the buffer type? I was > > thinking here that it would have worked equally well to specify that > > the client must supply a linear-layout buffer manufactured through > > zwp_linux_dmabuf. This would be eligible for direct targeting by the > > GL renderer/KMS writeback, but also can be mapped with gbm_bo_map() > > in the compositor's Pixman backend and/or a client who wants to map > > it to the CPU upon delivery. > > Because the test suite specifically needs CPU access to the screenshot. > There was no use yet for dmabuf, and GL-renderer was already doing > glReadPixels() for screenshots. > > IOW, all the limitations are just "was not needed yet". > > Note, that re-using or extending the protocol extension > weston_capture_v1 for streaming outputs for non-test-suite use cases > may not be the best idea. If the interface needs to be a Wayland > extension, then maybe something from the wlr extensions would suit > better. OTOH, for e.g. Pipewire there would not be a Wayland extension > used at all. > > The internal API (weston_output_capture) is very much geared for > weston_capture_v1 only. The internal API might take improving rather > than weston_capture_v1. > > > Thanks, > pq
Re: Full-motion zero-copy screen capture in Weston
Hi, Yeah. I agree that although I can prototype something quick and dirty here as a change to weston_output_capture_v1, it's probably not a good fit there. Drew or Simon, does either of https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml or https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml strike you as a good fit for the use-case of getting a streamed copy of an output? They seem very similar – not sure what differentiates them from each other. My goal is to implement this screen capture with a guarantee that the copy comes from a KMS writeback connector. I know this sounds like an odd thing to insist on. Let's say that in my industry, the system is rarely only running Linux directly on the bare metal. Using the writeback hardware on the display controller allows to get a copy of content from all the virtual machines in the system. Frankly, weston_output_capture_v1's model that clients allocate the buffers would make it very difficult to support efficient screen capture for more than one simultaneous client. You can only target one writeback framebuffer per page flip. Having the compositor manage the buffers' lifetimes and just publishing out handles (in the style of those two wlr extensions) to those probably fits better. -Matt From: Pekka Paalanen Sent: Friday, May 31, 2024 3:02 AM To: Hoosier, Matt Cc: Marius Vlad; wayland-devel@lists.freedesktop.org Subject: Re: Full-motion zero-copy screen capture in Weston On Thu, 30 May 2024 13:40:15 + "Hoosier, Matt" wrote: > Okay, interesting thoughts on all of that. > > I'm not sure how far I'm going to get toward a complete overhaul of > the capture mechanism. Maybe it would be useful to know a couple > things about the current one (weston_output_capture_v1), so that I > don't commit mistakes that somebody already considered and guarded > against: > > * Why was it explicitly picked only for still shots? I can image that > it wouldn't have been a whole lot more work to design this API with a > bounce-buffering scheme rather than a setup/do-it-once/destroy model. > There was no need for streaming, as it was purely for the test suite. The test suite is very particular about when and how the shot is taken: it must be produced by the defined source, and it must be produced on the very next repaint of the output, exactly once. Did you mean a buffer pool (queueing/dequeueing) rather than bounce-buffering? Sure. > * Why was wl_shm explicitly picked for the buffer type? I was > thinking here that it would have worked equally well to specify that > the client must supply a linear-layout buffer manufactured through > zwp_linux_dmabuf. This would be eligible for direct targeting by the > GL renderer/KMS writeback, but also can be mapped with gbm_bo_map() > in the compositor's Pixman backend and/or a client who wants to map > it to the CPU upon delivery. Because the test suite specifically needs CPU access to the screenshot. There was no use yet for dmabuf, and GL-renderer was already doing glReadPixels() for screenshots. IOW, all the limitations are just "was not needed yet". Note, that re-using or extending the protocol extension weston_capture_v1 for streaming outputs for non-test-suite use cases may not be the best idea. If the interface needs to be a Wayland extension, then maybe something from the wlr extensions would suit better. OTOH, for e.g. Pipewire there would not be a Wayland extension used at all. The internal API (weston_output_capture) is very much geared for weston_capture_v1 only. The internal API might take improving rather than weston_capture_v1. Thanks, pq
Re: Full-motion zero-copy screen capture in Weston
On Thu, 30 May 2024 13:40:15 + "Hoosier, Matt" wrote: > Okay, interesting thoughts on all of that. > > I'm not sure how far I'm going to get toward a complete overhaul of > the capture mechanism. Maybe it would be useful to know a couple > things about the current one (weston_output_capture_v1), so that I > don't commit mistakes that somebody already considered and guarded > against: > > * Why was it explicitly picked only for still shots? I can image that > it wouldn't have been a whole lot more work to design this API with a > bounce-buffering scheme rather than a setup/do-it-once/destroy model. > There was no need for streaming, as it was purely for the test suite. The test suite is very particular about when and how the shot is taken: it must be produced by the defined source, and it must be produced on the very next repaint of the output, exactly once. Did you mean a buffer pool (queueing/dequeueing) rather than bounce-buffering? Sure. > * Why was wl_shm explicitly picked for the buffer type? I was > thinking here that it would have worked equally well to specify that > the client must supply a linear-layout buffer manufactured through > zwp_linux_dmabuf. This would be eligible for direct targeting by the > GL renderer/KMS writeback, but also can be mapped with gbm_bo_map() > in the compositor's Pixman backend and/or a client who wants to map > it to the CPU upon delivery. Because the test suite specifically needs CPU access to the screenshot. There was no use yet for dmabuf, and GL-renderer was already doing glReadPixels() for screenshots. IOW, all the limitations are just "was not needed yet". Note, that re-using or extending the protocol extension weston_capture_v1 for streaming outputs for non-test-suite use cases may not be the best idea. If the interface needs to be a Wayland extension, then maybe something from the wlr extensions would suit better. OTOH, for e.g. Pipewire there would not be a Wayland extension used at all. The internal API (weston_output_capture) is very much geared for weston_capture_v1 only. The internal API might take improving rather than weston_capture_v1. Thanks, pq pgpGdEI0WVF9N.pgp Description: OpenPGP digital signature
Re: Full-motion zero-copy screen capture in Weston
Okay, interesting thoughts on all of that. I'm not sure how far I'm going to get toward a complete overhaul of the capture mechanism. Maybe it would be useful to know a couple things about the current one (weston_output_capture_v1), so that I don't commit mistakes that somebody already considered and guarded against: * Why was it explicitly picked only for still shots? I can image that it wouldn't have been a whole lot more work to design this API with a bounce-buffering scheme rather than a setup/do-it-once/destroy model. * Why was wl_shm explicitly picked for the buffer type? I was thinking here that it would have worked equally well to specify that the client must supply a linear-layout buffer manufactured through zwp_linux_dmabuf. This would be eligible for direct targeting by the GL renderer/KMS writeback, but also can be mapped with gbm_bo_map() in the compositor's Pixman backend and/or a client who wants to map it to the CPU upon delivery. -Matt On 5/30/24, 3:22 AM, "Pekka Paalanen" mailto:pekka.paala...@collabora.com>> wrote: On Wed, 29 May 2024 15:18:16 + "Hoosier, Matt" mailto:matt.hoos...@garmin.com>> wrote: > Thanks, Pekka. > > So what would be an upstream-friendly way to put hooks deep down into > the DRM backend to exploit the KMS writeback connectors, but still > allow an XDG Desktop portal implementation to be usable on all the > backends? Hi Matt, I don't know how that would look like. "Hooks" feels like a side-channel to me, while I'd prefer a first class API. This probably requires adjusting some of the existing internal interfaces so that they can handle both one-shot and streaming captures (timestamps!), and even multiple capture consumers simultaneously. While the private screenshooting protocol currently explicitly defines how the screenshot must be taken, this improved API should be able to fall back as necessary and if desired: use KMS writeback when it works, fall back to renderer otherwise (which disables KMS planes composition). There is also the dmabuf vs. wl_shm buffer issue. All the external APIs should be implemented on top of such improved internal API: screenshots, screen streaming, anything that wants to get the contents of another backend's output and not create an independent output of its own with an independent update/rendering cadence. > Or maybe that's an unnecessary goal to begin with; a desktop session > somewhat implies the compositor is driving the physical hardware? I think the improved API needs to be usable on all backends, yes. Only KMS writeback needs backend support, the rest should be doable in the renderers which are shared by all backends. Non-DRM backends just don't have KMS writeback. Something like this would be ideal, I believe. Unfortunately I don't think I can personally spare time to help with this. This is more of a wish than a requirement. Thanks, pq > > > -Original Message- > > From: Pekka Paalanen > <mailto:pekka.paala...@collabora.com>> > > Sent: Wednesday, May 29, 2024 2:43 AM > > To: Marius Vlad > <mailto:marius.v...@collabora.com>>; Hoosier, Matt > > mailto:matt.hoos...@garmin.com>> > > Cc: wayland-devel@lists.freedesktop.org > > <mailto:wayland-devel@lists.freedesktop.org> > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > On Tue, 28 May 2024 20:04:45 +0300 > > Marius Vlad mailto:marius.v...@collabora.com>> > > wrote: > > > > > On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote: > > > > Hi Marius, > > > Hi, > > > > > > > > Okay, I guess that answers the bit about needing to screen-scrape to > > > > get > > content into Pipewire now. > > > > > > > > But I'm still a little unclear about a couple things, if I were to try > > > > to build on > > this PW backend as a starting point: > > > > > > > > First, it looks to me like when you use the PW backend to Weston, > > > > that becomes your display. That is, rendering directly targets it. I > > > > was hoping for a way to get it to broadcast the very same > > > > framebuffer(s) that are getting scanned out for the current frame by > > > > the DRM backend. > > > With > > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341 > > > <https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341> > > > the PipeWire output can mirror out the native DRM one. It aims at > > > having a way to configure VNC, RDP and PipeWire to screen-share the > > output. > > > > > > > > Second, I'm don't see the path to getting this to levera
Re: Full-motion zero-copy screen capture in Weston
On Wed, 29 May 2024 15:18:16 + "Hoosier, Matt" wrote: > Thanks, Pekka. > > So what would be an upstream-friendly way to put hooks deep down into > the DRM backend to exploit the KMS writeback connectors, but still > allow an XDG Desktop portal implementation to be usable on all the > backends? Hi Matt, I don't know how that would look like. "Hooks" feels like a side-channel to me, while I'd prefer a first class API. This probably requires adjusting some of the existing internal interfaces so that they can handle both one-shot and streaming captures (timestamps!), and even multiple capture consumers simultaneously. While the private screenshooting protocol currently explicitly defines how the screenshot must be taken, this improved API should be able to fall back as necessary and if desired: use KMS writeback when it works, fall back to renderer otherwise (which disables KMS planes composition). There is also the dmabuf vs. wl_shm buffer issue. All the external APIs should be implemented on top of such improved internal API: screenshots, screen streaming, anything that wants to get the contents of another backend's output and not create an independent output of its own with an independent update/rendering cadence. > Or maybe that's an unnecessary goal to begin with; a desktop session > somewhat implies the compositor is driving the physical hardware? I think the improved API needs to be usable on all backends, yes. Only KMS writeback needs backend support, the rest should be doable in the renderers which are shared by all backends. Non-DRM backends just don't have KMS writeback. Something like this would be ideal, I believe. Unfortunately I don't think I can personally spare time to help with this. This is more of a wish than a requirement. Thanks, pq > > > -Original Message- > > From: Pekka Paalanen > > Sent: Wednesday, May 29, 2024 2:43 AM > > To: Marius Vlad ; Hoosier, Matt > > > > Cc: wayland-devel@lists.freedesktop.org > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > On Tue, 28 May 2024 20:04:45 +0300 > > Marius Vlad wrote: > > > > > On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote: > > > > Hi Marius, > > > Hi, > > > > > > > > Okay, I guess that answers the bit about needing to screen-scrape to > > > > get > > content into Pipewire now. > > > > > > > > But I'm still a little unclear about a couple things, if I were to try > > > > to build on > > this PW backend as a starting point: > > > > > > > > First, it looks to me like when you use the PW backend to Weston, > > > > that becomes your display. That is, rendering directly targets it. I > > > > was hoping for a way to get it to broadcast the very same > > > > framebuffer(s) that are getting scanned out for the current frame by > > > > the DRM backend. > > > With > > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341 > > > the PipeWire output can mirror out the native DRM one. It aims at > > > having a way to configure VNC, RDP and PipeWire to screen-share the > > output. > > > > > > > > Second, I'm don't see the path to getting this to leverage the > > > > DRM_MODE_CONNECTOR_WRITEBACK hardware (like the > > > > weston_screen_recorder does). I think that any layering would be > > > > forced to be offloaded to the GPU ahead of time. Maybe I missed some > > > > implication of what you were pointing out here? > > > No sorry, I haven't really implied that, just pointed that out there's > > > some work for PipeWire gaining dmabuf. > > > > > > Screen-sharing an output is done > > > with multiple backends, and configuring Weston front-end is it with > > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341. > > > > Hi Matt, Marius, > > > > multiple backends necessarily means that each backend renders its own > > weston_output independently. While it's fine for most screen-sharing use > > cases, I don't think it can ever be as efficient as KMS writeback could be. > > > > Getting a dmabuf-based video stream from DRM-backend using KMS > > writeback needs integration in the DRM-backend. I don't know how that > > would look like, but I suspect these ideas would be good: > > > > - builds on and extends the existing writeback support instead of > > something new on the side > > > > - does not use the DRM-backend "virtual output" API; this was a > > workaround for the lack of multi-backend support in the past and has > > the same disadvantages as multi-backend. (I don't think the DRM > > virtual output API has any reason to exist anymore, multi-backend > > should supersede it after converting the users.) > > > > I also think that implementing the usual desktop portals in Weston would be > > a > > good thing, and not something to avoid, if those can provide a nice external > > interface for the use case. > > > > > > Thanks, > > pq pgpE2PXYICwdX.pgp Description: OpenPGP digital signature
RE: Full-motion zero-copy screen capture in Weston
Thanks, Pekka. So what would be an upstream-friendly way to put hooks deep down into the DRM backend to exploit the KMS writeback connectors, but still allow an XDG Desktop portal implementation to be usable on all the backends? Or maybe that's an unnecessary goal to begin with; a desktop session somewhat implies the compositor is driving the physical hardware? > -Original Message- > From: Pekka Paalanen > Sent: Wednesday, May 29, 2024 2:43 AM > To: Marius Vlad ; Hoosier, Matt > > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: Full-motion zero-copy screen capture in Weston > > On Tue, 28 May 2024 20:04:45 +0300 > Marius Vlad wrote: > > > On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote: > > > Hi Marius, > > Hi, > > > > > > Okay, I guess that answers the bit about needing to screen-scrape to get > content into Pipewire now. > > > > > > But I'm still a little unclear about a couple things, if I were to try to > > > build on > this PW backend as a starting point: > > > > > > First, it looks to me like when you use the PW backend to Weston, > > > that becomes your display. That is, rendering directly targets it. I > > > was hoping for a way to get it to broadcast the very same > > > framebuffer(s) that are getting scanned out for the current frame by > > > the DRM backend. > > With > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341 > > the PipeWire output can mirror out the native DRM one. It aims at > > having a way to configure VNC, RDP and PipeWire to screen-share the > output. > > > > > > Second, I'm don't see the path to getting this to leverage the > > > DRM_MODE_CONNECTOR_WRITEBACK hardware (like the > > > weston_screen_recorder does). I think that any layering would be > > > forced to be offloaded to the GPU ahead of time. Maybe I missed some > > > implication of what you were pointing out here? > > No sorry, I haven't really implied that, just pointed that out there's > > some work for PipeWire gaining dmabuf. > > > > Screen-sharing an output is done > > with multiple backends, and configuring Weston front-end is it with > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341. > > Hi Matt, Marius, > > multiple backends necessarily means that each backend renders its own > weston_output independently. While it's fine for most screen-sharing use > cases, I don't think it can ever be as efficient as KMS writeback could be. > > Getting a dmabuf-based video stream from DRM-backend using KMS > writeback needs integration in the DRM-backend. I don't know how that > would look like, but I suspect these ideas would be good: > > - builds on and extends the existing writeback support instead of > something new on the side > > - does not use the DRM-backend "virtual output" API; this was a > workaround for the lack of multi-backend support in the past and has > the same disadvantages as multi-backend. (I don't think the DRM > virtual output API has any reason to exist anymore, multi-backend > should supersede it after converting the users.) > > I also think that implementing the usual desktop portals in Weston would be a > good thing, and not something to avoid, if those can provide a nice external > interface for the use case. > > > Thanks, > pq
Re: Full-motion zero-copy screen capture in Weston
On Tue, 28 May 2024 20:04:45 +0300 Marius Vlad wrote: > On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote: > > Hi Marius, > Hi, > > > > Okay, I guess that answers the bit about needing to screen-scrape to get > > content into Pipewire now. > > > > But I'm still a little unclear about a couple things, if I were to try to > > build on this PW backend as a starting point: > > > > First, it looks to me like when you use the PW backend to Weston, that > > becomes your display. That is, rendering directly targets it. I was > > hoping for a way to get it to broadcast the very same framebuffer(s) > > that are getting scanned out for the current frame by the DRM > > backend. > With https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341 > the PipeWire output can mirror out the native DRM one. It aims at having > a way to configure VNC, RDP and PipeWire to screen-share the output. > > > > Second, I'm don't see the path to getting this to leverage the > > DRM_MODE_CONNECTOR_WRITEBACK hardware (like the weston_screen_recorder > > does). I think that any layering would be forced to > > be offloaded to the GPU ahead of time. Maybe I missed some implication > > of what you were pointing out here? > No sorry, I haven't really implied that, just pointed that out there's > some work for PipeWire gaining dmabuf. > > Screen-sharing an output is done > with multiple backends, and configuring Weston front-end is it with > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341. Hi Matt, Marius, multiple backends necessarily means that each backend renders its own weston_output independently. While it's fine for most screen-sharing use cases, I don't think it can ever be as efficient as KMS writeback could be. Getting a dmabuf-based video stream from DRM-backend using KMS writeback needs integration in the DRM-backend. I don't know how that would look like, but I suspect these ideas would be good: - builds on and extends the existing writeback support instead of something new on the side - does not use the DRM-backend "virtual output" API; this was a workaround for the lack of multi-backend support in the past and has the same disadvantages as multi-backend. (I don't think the DRM virtual output API has any reason to exist anymore, multi-backend should supersede it after converting the users.) I also think that implementing the usual desktop portals in Weston would be a good thing, and not something to avoid, if those can provide a nice external interface for the use case. Thanks, pq pgp2frA_CAvcb.pgp Description: OpenPGP digital signature
Re: Full-motion zero-copy screen capture in Weston
Hi again, The MR I'd like to link is actually at https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1476 On Tue, May 28, 2024 at 08:04:52PM +0300, Marius Vlad wrote: > On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote: > > Hi Marius, > Hi, > > > > Okay, I guess that answers the bit about needing to screen-scrape to get > > content into Pipewire now. > > > > But I'm still a little unclear about a couple things, if I were to try to > > build on this PW backend as a starting point: > > > > First, it looks to me like when you use the PW backend to Weston, that > > becomes your display. That is, rendering directly targets it. I was > > hoping for a way to get it to broadcast the very same framebuffer(s) > > that are getting scanned out for the current frame by the DRM > > backend. > With https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341 > the PipeWire output can mirror out the native DRM one. It aims at having > a way to configure VNC, RDP and PipeWire to screen-share the output. > > > > Second, I'm don't see the path to getting this to leverage the > > DRM_MODE_CONNECTOR_WRITEBACK hardware (like the weston_screen_recorder > > does). I think that any layering would be forced to > > be offloaded to the GPU ahead of time. Maybe I missed some implication > > of what you were pointing out here? > No sorry, I haven't really implied that, just pointed that out there's > some work for PipeWire gaining dmabuf. > > Screen-sharing an output is done > with multiple backends, and configuring Weston front-end is it with > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341. > > > > > > -Original Message- > > > From: Marius Vlad > > > Sent: Saturday, May 25, 2024 6:12 AM > > > To: Hoosier, Matt > > > Cc: wayland-devel@lists.freedesktop.org > > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > > > On Fri, May 24, 2024 at 09:43:58PM +, Hoosier, Matt wrote: > > > > Hi, > > > > > > > > I'm interested in finding or contributing some mechanism to get sort of > > > > the > > > same effect as a cross between: > > > > > > > > > > > > * > > > > weston_output_capture's support for using the > > > > DRM_MODE_CONNECTOR_WRITEBACK connectors, and > > > > > > > > * > > > > the streamed orientation of weston_screen_recorder, and > > > > > > > > * > > > > no forced reliance on the GPU to pre-blend the 2D scene – whatever > > > > plane blending would otherwise have occurred must still occur when the > > > > screen recording mechanism is active > > > > > > > > The desktop environments' compositors implement the XDG screencast > > > portal. If I read things correctly, that one deposits the stream of > > > dmabuf frame > > > fds into the Pipewire stream indicated by the user invoking the D-Bus > > > Screencast API. > > > > > > > > That doesn't really seem like a starter for doing this in Weston. > > > > There was conversation back in 2019 about trying to add zero-copy > > > > dmabuf support in Weston's own Pipewire integration, but I think that > > > > didn't happen? > > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366 > > > > > > > > Alternately, I see that the remoting plugin on today's main branch > > > > supports > > > GStreamer dmabuf allocators. Does this mean that I could build something > > > using a virtual weston_output in the drm-backend? > > > > > > > > Cheers, > > > > Matt signature.asc Description: PGP signature
Re: Full-motion zero-copy screen capture in Weston
On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote: > Hi Marius, Hi, > > Okay, I guess that answers the bit about needing to screen-scrape to get > content into Pipewire now. > > But I'm still a little unclear about a couple things, if I were to try to > build on this PW backend as a starting point: > > First, it looks to me like when you use the PW backend to Weston, that > becomes your display. That is, rendering directly targets it. I was > hoping for a way to get it to broadcast the very same framebuffer(s) > that are getting scanned out for the current frame by the DRM > backend. With https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341 the PipeWire output can mirror out the native DRM one. It aims at having a way to configure VNC, RDP and PipeWire to screen-share the output. > > Second, I'm don't see the path to getting this to leverage the > DRM_MODE_CONNECTOR_WRITEBACK hardware (like the weston_screen_recorder > does). I think that any layering would be forced to > be offloaded to the GPU ahead of time. Maybe I missed some implication > of what you were pointing out here? No sorry, I haven't really implied that, just pointed that out there's some work for PipeWire gaining dmabuf. Screen-sharing an output is done with multiple backends, and configuring Weston front-end is it with https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341. > > > -Original Message- > > From: Marius Vlad > > Sent: Saturday, May 25, 2024 6:12 AM > > To: Hoosier, Matt > > Cc: wayland-devel@lists.freedesktop.org > > Subject: Re: Full-motion zero-copy screen capture in Weston > > > > On Fri, May 24, 2024 at 09:43:58PM +, Hoosier, Matt wrote: > > > Hi, > > > > > > I'm interested in finding or contributing some mechanism to get sort of > > > the > > same effect as a cross between: > > > > > > > > > * > > > weston_output_capture's support for using the > > > DRM_MODE_CONNECTOR_WRITEBACK connectors, and > > > > > > * > > > the streamed orientation of weston_screen_recorder, and > > > > > > * > > > no forced reliance on the GPU to pre-blend the 2D scene – whatever > > > plane blending would otherwise have occurred must still occur when the > > > screen recording mechanism is active > > > > > > The desktop environments' compositors implement the XDG screencast > > portal. If I read things correctly, that one deposits the stream of dmabuf > > frame > > fds into the Pipewire stream indicated by the user invoking the D-Bus > > Screencast API. > > > > > > That doesn't really seem like a starter for doing this in Weston. > > > There was conversation back in 2019 about trying to add zero-copy > > > dmabuf support in Weston's own Pipewire integration, but I think that > > > didn't happen? > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366 > > > > > > Alternately, I see that the remoting plugin on today's main branch > > > supports > > GStreamer dmabuf allocators. Does this mean that I could build something > > using a virtual weston_output in the drm-backend? > > > > > > Cheers, > > > Matt signature.asc Description: PGP signature
RE: Full-motion zero-copy screen capture in Weston
Hi Marius, Okay, I guess that answers the bit about needing to screen-scrape to get content into Pipewire now. But I'm still a little unclear about a couple things, if I were to try to build on this PW backend as a starting point: First, it looks to me like when you use the PW backend to Weston, that becomes your display. That is, rendering directly targets it. I was hoping for a way to get it to broadcast the very same framebuffer(s) that are getting scanned out for the current frame by the DRM backend. Second, I'm don't see the path to getting this to leverage the DRM_MODE_CONNECTOR_WRITEBACK hardware (like the weston_screen_recorder does). I think that any layering would be forced to be offloaded to the GPU ahead of time. Maybe I missed some implication of what you were pointing out here? > -Original Message- > From: Marius Vlad > Sent: Saturday, May 25, 2024 6:12 AM > To: Hoosier, Matt > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: Full-motion zero-copy screen capture in Weston > > On Fri, May 24, 2024 at 09:43:58PM +, Hoosier, Matt wrote: > > Hi, > > > > I'm interested in finding or contributing some mechanism to get sort of the > same effect as a cross between: > > > > > > * > > weston_output_capture's support for using the > > DRM_MODE_CONNECTOR_WRITEBACK connectors, and > > > > * > > the streamed orientation of weston_screen_recorder, and > > > > * > > no forced reliance on the GPU to pre-blend the 2D scene – whatever > > plane blending would otherwise have occurred must still occur when the > > screen recording mechanism is active > > > > The desktop environments' compositors implement the XDG screencast > portal. If I read things correctly, that one deposits the stream of dmabuf > frame > fds into the Pipewire stream indicated by the user invoking the D-Bus > Screencast API. > > > > That doesn't really seem like a starter for doing this in Weston. > > There was conversation back in 2019 about trying to add zero-copy > > dmabuf support in Weston's own Pipewire integration, but I think that > > didn't happen? > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366 > > > > Alternately, I see that the remoting plugin on today's main branch supports > GStreamer dmabuf allocators. Does this mean that I could build something > using a virtual weston_output in the drm-backend? > > > > Cheers, > > Matt
Re: Full-motion zero-copy screen capture in Weston
On Fri, May 24, 2024 at 09:43:58PM +, Hoosier, Matt wrote: > Hi, > > I'm interested in finding or contributing some mechanism to get sort of the > same effect as a cross between: > > > * > weston_output_capture's support for using the DRM_MODE_CONNECTOR_WRITEBACK > connectors, and > > * > the streamed orientation of weston_screen_recorder, and > > * > no forced reliance on the GPU to pre-blend the 2D scene – whatever plane > blending would otherwise have occurred must still occur when the screen > recording mechanism is active > > The desktop environments' compositors implement the XDG screencast portal. If > I read things correctly, that one deposits the stream of dmabuf frame fds > into the Pipewire stream indicated by the user invoking the D-Bus Screencast > API. > > That doesn't really seem like a starter for doing this in Weston. > There was conversation back in 2019 about trying to add zero-copy > dmabuf support in Weston's own Pipewire integration, but I think that > didn't happen? https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366 > > Alternately, I see that the remoting plugin on today's main branch supports > GStreamer dmabuf allocators. Does this mean that I could build something > using a virtual weston_output in the drm-backend? > > Cheers, > Matt signature.asc Description: PGP signature
Full-motion zero-copy screen capture in Weston
Hi, I'm interested in finding or contributing some mechanism to get sort of the same effect as a cross between: * weston_output_capture's support for using the DRM_MODE_CONNECTOR_WRITEBACK connectors, and * the streamed orientation of weston_screen_recorder, and * no forced reliance on the GPU to pre-blend the 2D scene – whatever plane blending would otherwise have occurred must still occur when the screen recording mechanism is active The desktop environments' compositors implement the XDG screencast portal. If I read things correctly, that one deposits the stream of dmabuf frame fds into the Pipewire stream indicated by the user invoking the D-Bus Screencast API. That doesn't really seem like a starter for doing this in Weston. There was conversation back in 2019 about trying to add zero-copy dmabuf support in Weston's own Pipewire integration, but I think that didn't happen? Alternately, I see that the remoting plugin on today's main branch supports GStreamer dmabuf allocators. Does this mean that I could build something using a virtual weston_output in the drm-backend? Cheers, Matt
Re: Weston mirror/clone to 2 different displays
On Mon, Apr 29, 2024 at 08:55:31PM +, Dawn HOWE wrote: > Hello, Hi, > > I posted a question last year about mirroring/cloning to LVDS/hdmi on > an imx8, which is not supported by the display driver. This thread > suggests that a solution for this was being worked last June, but I > have not seen follow up on the topic since then. Is there any change > in the status? Yes, we landed that in Weston 13, but configuring was left out for the next version. That work is currently WIP at https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1476 > > thanks, > Dawn > > > > > From: Daniel Stone > Sent: Friday, June 23, 2023 10:04 AM > To: Dawn HOWE > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: Weston mirror/clone to 2 different displays > > Hi Dawn, > > On Thu, 22 Jun 2023 at 18:09, Dawn HOWE > mailto:dawn.h...@alten.com>> wrote: > > I am developing an (embedded) medical device which is required to have a > touchscreen display and also mirror the output to a monitor connected via > HDMI. The device is using Wayland/Weston on TorizonCore (based on a yocto > kirkstone). I am able to get the display extended from HDMI to LVDS, but not > have the output mirrored to both displays. I posted a query on the Toradex > community, and received a response that Weston may not be capable of doing > this. > (https://community.toradex.com/t/apalis-imx8-hdmi-and-lvds-display-not-mirroring-cloning/19869<https://secure-web.cisco.com/1qqKzDdWiU1WxNx_1TpOWJ-iSI2TjeLkxdsz1u3dTzFUAeGjZk3MkNig_jPd-wds8_naYOU4DgHGNY7S5gLnEomhCtYlxT2Eq_al1fYRbeKRSy6zzqhyt1iWUudR9EUtgBcffrsaAYdXc5X-ECue_LMusWt5iDW39uJpx_bAgRNkx-7vl34qGXQMz4V6KIJS6HdH8-LWCtucb0DMPb8SaHi0jKOWYo_ilZwTPLgtTatbmhhZD_TF8OXfOHBJYHKfHyysh0zQW8jT61c3-RbCCa06qQJkILh2etzkUWkhLeDO4UylwQaODEYrF7V8_ArLvfggwPmbCOKSeiDdDdLEk3GQx7o0FkC7v-_Jse1glUkfG7zVY5-BW2_bQjH36tMFiyOk34qW5ZO-_0IUIrMJ2Er4uR6XMnq2G-Ckh9nqomzu6DACKXMIiSqUS2F3P5EBxyO2nobhtO21X8vdB4hnxNjLZ4zHyDYuKQlatrGSo8yKlCT5lLng4yp1ztU5uWBUHf4WGFju4oXblCQMR30Xa5g/https%3A%2F%2Fcommunity.toradex.com%2Ft%2Fapalis-imx8-hdmi-and-lvds-display-not-mirroring-cloning%2F19869>). > > > > I have searched and found some old posts from several years ago indicating > that it was not supported, but may be with a patch. I understand that > “same-as” configuration in weston.ini does not work for my scenario. > > > > What is the current state of cloning/mirroring to two different outputs, but > on the same card. E.g (card1-HDMI-A-1 and card1-LVDS-1): > > > ls /sys/class/drm > > card0 card1 card1-HDMI-A-1 card1-LVDS-1 renderD128 > renderD129 version > > Weston can currently mirror it if the display driver directly supports it. > You can use the same-as configuration option (see man weston-drm) to enable > this. If your display driver doesn't support this in the kernel, then Weston > won't do it for now, but we are actively working on this and expect to have a > branch capable of this within the next couple of weeks or so. > > Cheers, > Daniel > The information contained in this e-mail and any attachments are intended > solely for the addressees. If you have received this email in error, please > contact the sender and delete the email from your system. signature.asc Description: PGP signature
Re: Weston mirror/clone to 2 different displays
Hello, I posted a question last year about mirroring/cloning to LVDS/hdmi on an imx8, which is not supported by the display driver. This thread suggests that a solution for this was being worked last June, but I have not seen follow up on the topic since then. Is there any change in the status? thanks, Dawn From: Daniel Stone Sent: Friday, June 23, 2023 10:04 AM To: Dawn HOWE Cc: wayland-devel@lists.freedesktop.org Subject: Re: Weston mirror/clone to 2 different displays Hi Dawn, On Thu, 22 Jun 2023 at 18:09, Dawn HOWE mailto:dawn.h...@alten.com>> wrote: I am developing an (embedded) medical device which is required to have a touchscreen display and also mirror the output to a monitor connected via HDMI. The device is using Wayland/Weston on TorizonCore (based on a yocto kirkstone). I am able to get the display extended from HDMI to LVDS, but not have the output mirrored to both displays. I posted a query on the Toradex community, and received a response that Weston may not be capable of doing this. (https://community.toradex.com/t/apalis-imx8-hdmi-and-lvds-display-not-mirroring-cloning/19869<https://secure-web.cisco.com/1qqKzDdWiU1WxNx_1TpOWJ-iSI2TjeLkxdsz1u3dTzFUAeGjZk3MkNig_jPd-wds8_naYOU4DgHGNY7S5gLnEomhCtYlxT2Eq_al1fYRbeKRSy6zzqhyt1iWUudR9EUtgBcffrsaAYdXc5X-ECue_LMusWt5iDW39uJpx_bAgRNkx-7vl34qGXQMz4V6KIJS6HdH8-LWCtucb0DMPb8SaHi0jKOWYo_ilZwTPLgtTatbmhhZD_TF8OXfOHBJYHKfHyysh0zQW8jT61c3-RbCCa06qQJkILh2etzkUWkhLeDO4UylwQaODEYrF7V8_ArLvfggwPmbCOKSeiDdDdLEk3GQx7o0FkC7v-_Jse1glUkfG7zVY5-BW2_bQjH36tMFiyOk34qW5ZO-_0IUIrMJ2Er4uR6XMnq2G-Ckh9nqomzu6DACKXMIiSqUS2F3P5EBxyO2nobhtO21X8vdB4hnxNjLZ4zHyDYuKQlatrGSo8yKlCT5lLng4yp1ztU5uWBUHf4WGFju4oXblCQMR30Xa5g/https%3A%2F%2Fcommunity.toradex.com%2Ft%2Fapalis-imx8-hdmi-and-lvds-display-not-mirroring-cloning%2F19869>). I have searched and found some old posts from several years ago indicating that it was not supported, but may be with a patch. I understand that “same-as” configuration in weston.ini does not work for my scenario. What is the current state of cloning/mirroring to two different outputs, but on the same card. E.g (card1-HDMI-A-1 and card1-LVDS-1): ls /sys/class/drm card0 card1 card1-HDMI-A-1 card1-LVDS-1 renderD128 renderD129 version Weston can currently mirror it if the display driver directly supports it. You can use the same-as configuration option (see man weston-drm) to enable this. If your display driver doesn't support this in the kernel, then Weston won't do it for now, but we are actively working on this and expect to have a branch capable of this within the next couple of weeks or so. Cheers, Daniel The information contained in this e-mail and any attachments are intended solely for the addressees. If you have received this email in error, please contact the sender and delete the email from your system.
Re: Weston backend support for non gpu boards
On Wed, 24 Apr 2024 14:06:17 +0530 Akshaya Maran said: > Hi, > > I am using the Weston 11 version. fbdev backend i s dropped in weston 11 . > Is there any alternative to the fb-dev backend since there is no drm device > in my custom board. add kms/drm driver for your display unit? the expectation is anything sensible should have one. if you have fbdev then there is some kind of driver there and a framebuffer of some sort. adapt it so it also exposes a drm device for the display unit. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Weston backend support for non gpu boards
Hi, I am using the Weston 11 version. fbdev backend i s dropped in weston 11 . Is there any alternative to the fb-dev backend since there is no drm device in my custom board. Thanks, Akshaya.M
Re: [ANNOUNCE] Weston 13.0.1
Hi all, Someone pointed out that the tag was wrong, pointing apparently to main branch. Had to delete the tag and re-create it. Should now point correctly. All links are the same, with the same files. Thanks for heads-up Dylan! On Tue, Apr 23, 2024 at 06:55:45PM +0300, Marius Vlad wrote: > Hi all, > > Weston 13.0.1, a bug fix release for 13.0.0 has been released. > > Full changelog below: > > Arnaud Vrac (3): > desktop-shell: clamp view alpha correctly > desktop-shell: set proper curtain size when no output is created yet > clients/desktop-shell: fix crash on init when panel is disabled > > Derek Foreman (3): > gl-renderer: apply output transform before readback in repaint > libweston: Clip damage to paint node visible region > libweston/backends: Move damage flush into backends > > Jeffy Chen (2): > renderer-gl: Fix wrong stride error when reading pixels > desktop-shell: Avoid using maximized size in fullscreen state > > Marius Vlad (3): > backend-pipewire: Move region initialization at the start > libweston: Add paint node destruction into weston_layer_entry_remove() > build: bump to version 13.0.1 for the point release > > Michael Olbrich (1): > ivi-shell: clear seat focus if necessary when a surface is destroyed > > Philipp Zabel (1): > libweston-desktop: Work around crash when opening popup menu > > Ray Smith (1): > backend-drm: fix confused fallback format handling > > Robert Mader (2): > backend-drm: Don't force non-opaque overlays to primary plane > backend-drm: Sort planes by faked zpos > > Wujian Sun (1): > libweston-desktop: Fix weston crash when lost the shsurf > > git tag: 13.0.1 > > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz > SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a > weston-13.0.1.tar.xz > SHA512: > 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122 > weston-13.0.1.tar.xz > PGP: > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig > signature.asc Description: PGP signature
[ANNOUNCE] Weston 13.0.1
Hi all, Weston 13.0.1, a bug fix release for 13.0.0 has been released. Full changelog below: Arnaud Vrac (3): desktop-shell: clamp view alpha correctly desktop-shell: set proper curtain size when no output is created yet clients/desktop-shell: fix crash on init when panel is disabled Derek Foreman (3): gl-renderer: apply output transform before readback in repaint libweston: Clip damage to paint node visible region libweston/backends: Move damage flush into backends Jeffy Chen (2): renderer-gl: Fix wrong stride error when reading pixels desktop-shell: Avoid using maximized size in fullscreen state Marius Vlad (3): backend-pipewire: Move region initialization at the start libweston: Add paint node destruction into weston_layer_entry_remove() build: bump to version 13.0.1 for the point release Michael Olbrich (1): ivi-shell: clear seat focus if necessary when a surface is destroyed Philipp Zabel (1): libweston-desktop: Work around crash when opening popup menu Ray Smith (1): backend-drm: fix confused fallback format handling Robert Mader (2): backend-drm: Don't force non-opaque overlays to primary plane backend-drm: Sort planes by faked zpos Wujian Sun (1): libweston-desktop: Fix weston crash when lost the shsurf git tag: 13.0.1 https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a weston-13.0.1.tar.xz SHA512: 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122 weston-13.0.1.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] Weston 12.0.4
Hi all, Weston 12.0.4, a bug fix release for 12.0.0 has been released. Full changelog below: Arnaud Vrac (2): desktop-shell: clamp view alpha correctly clients/desktop-shell: fix crash on init when panel is disabled Marius Vlad (1): build: bump to version 12.0.4 for the point release Michael Olbrich (1): ivi-shell: clear seat focus if necessary when a surface is destroyed Philipp Zabel (1): libweston-desktop: Work around crash when opening popup menu Robert Mader (2): backend-drm: Don't force non-opaque overlays to primary plane backend-drm: Sort planes by faked zpos Tomohito Esaki (4): ivi-shell: Properly handle seat hotplugging ivi-shell: activate desktop surface hmi-controller: activate and deactivate sruface ivi-shell-user-interface: change timing to create the launcher surface Wujian Sun (1): libweston-desktop: Fix weston crash when lost the shsurf git tag: 12.0.4 https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.4/downloads/weston-12.0.4.tar.xz SHA256: efdb21859b38f8cbc2b4b39ad65cc1ea3ed1adab23ac28bf501a8a9f80a31727 weston-12.0.4.tar.xz SHA512: c988256b73ea72f06d8ec4faaac2f4a2c52b250b573d3c9906cd00dcba017ad2202875ff04d012b194044715fb5e586331238c54daa508b814c7ab22f3d40006 weston-12.0.4.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.4/downloads/weston-12.0.4.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] Weston bug-fix release schedule -- 13.0.1 and 12.0.4
Hi all, I've been postponing these for a while now, and given that Weston 14 is still in development with some in-flight changes, think it would good to have at least an intermediary, bug-fix release, for Weston 13, respectively Weston 12. Next week, 23 of April, 2024, I'd like to cut both trees and do a release. In Gitlab there's 'Backport to Weston 12/13' tag which can be used if you would like to get some bug-fixes in until then, or just shout/drop a mail, so I can pick them up. Also, the MRs to pick up the fixes are opened as well: Weston 12 - https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1497 Weston 13 - https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1494 Thanks! signature.asc Description: PGP signature
Re: Issue with starting Weston service
On Sat, Mar 30, 2024 at 09:16:57AM +0530, Akshaya Maran wrote:
> Hi Marius,
Hi,
>
> pvr kernel module was not loaded properly . After loading the module , I
> end up with below issue ,
>
> *weston.service - Weston, a Wayland compositor, as a system service*
> *Loaded: loaded (/etc/systemd/system/weston.service; disabled; preset:
> enabled)*
> *Active: failed (Result: exit-code)*
> * Docs: man:weston(1)*
> *man:weston.ini(5)*
> *http://wayland.freedesktop.org/ <http://wayland.freedesktop.org/>*
> *Process: 252 ExecStart=/usr/bin/weston --modules=systemd-notify.so
> (code=exited, status=224/PAM)*
> * Main PID: 252 (code=exited, status=224/PAM)*
> * CPU: 24ms*
>
>
> *systemd[1]: Starting weston.service...*
> *(weston)[252]: PAM failed: Authentication service cannot retrieve
> authentication info*
This seems to indicate further issues with your system's
setup/installation regarding PAM (man 3 pam).
This is unrelated to Weston.
> *(weston)[252]: weston.service: Failed to set up PAM session: Operation not
> permitted*
> *(weston)[252]: weston.service: Failed at step PAM spawning
> /usr/bin/weston: Operation not permitted*
> *systemd[1]: weston.service: Main process exited, code=exited,
> status=224/PAM*
> *systemd[1]: weston.service: Failed with result 'exit-code'.*
> *systemd[1]: Failed to start weston.service.*
>
>
> Can you help me with this?
>
> Thanks,
> Akshaya.M
>
> On Fri, Mar 29, 2024 at 2:29 PM Marius Vlad
> wrote:
>
> > On Fri, Mar 29, 2024 at 12:28:36AM +0530, Akshaya Maran wrote:
> > > Hi,
> > Hi,
> > >
> > > I am facing an issue while trying to start the weston service .
> > > Below is the error message :
> > >
> > > *weston.service - Weston, a Wayland compositor, as a system service*
> > >
> > > * Loaded: loaded (/lib/systemd/system/weston.service; disabled;
> > preset:
> > > enabled)*
> > >
> > > * Active: failed (Result: exit-code)*
> > >
> > > *TriggeredBy: �● weston.socket*
> > >
> > > * Docs: man:weston(1)*
> > >
> > > * man:weston.ini(5)*
> > >
> > > * http://wayland.freedesktop.org/
> > > <http://wayland.freedesktop.org/>*
> > >
> > > *Process: 167 ExecStart=/usr/bin/weston
> > > --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so
> > > (code=exited, status=1/FAILURE)*
> > >
> > > * Main PID: 167 (code=exited, status=1/FAILURE)*
> > >
> > > *CPU: 28ms*
> > >
> > >
> > > * weston[167]: failed to load swrast driver*
> > >
> > > * weston[167]: Internal warning: debug scope 'drm-backend' has not been
> > > destroyed.*
> > >
> > > * weston[167]: PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]*
> > These issues are related to the graphics driver/display driver and not
> > Weston.
> > Either your installation is broken, incomplete, it's missing something
> > else to run
> > (kernel driver loaded), it can't run on your system, or something else is
> > already
> > using the same resource (DRM master) on system. Suggest looking for
> > 'PVRDRMOpenRender' as that might further assistance to get the graphics
> > driver working.
> > >
> > > * weston[167]: PVR:(Error): PVRSRVConnect: Unable to open connection.
> > [0, ]*
> > >
> > > * weston[167]: PVR:(Error): Couldn't connect to services [0, ]*
> > >
> > > * weston[167]: PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services
> > > initialisation failed [0, ]*
> > >
> > > * weston[167]: PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL
> > > global data [0, ]*
> > >
> > > * systemd[1]: weston.service: Main process exited, code=exited,
> > > status=1/FAILURE*
> > >
> > > * systemd[1]: weston.service: Failed with result 'exit-code'.*
> > >
> > > * systemd[1]: Failed to start weston.service.*
> > >
> > > Can you please help me to understand and fix this error ?
> > >
> > > Thanks,
> > > Akshaya.M
> >
signature.asc
Description: PGP signature
Re: Qustion: Support for Splitting Application Output Across Multiple Displays in Weston
On 29/03/2024 01:20, Yosuke Nakayama wrote: Dear Wayland-devel Community, I am currently exploring the capabilities of Weston, the reference compositor for Wayland, specifically in the context of an application use case that I am working on. My goal is to achieve a functionality where the graphical output of a single application can be divided and displayed simultaneously across two separate displays. This functionality would enable part of the application window to be shown on one display and the rest on another, effectively spanning the application window across multiple screens. From my understanding and current experimentation with Weston, this particular use case does not seem to be directly supported, but I'm not sure. Does functionality exist at this time to achieve such a use case? I don't think this is currently supported by Weston. But it is supported by Ubuntu Frame <https://mir-server.io/docs/how-to-configure-ubuntu-frame-for-multiple-outputs>. Does you usecase allow you to consider alternative compositors? Thank you for your time and assistance! Best regards, -- Canonical-20th-anniversary Alan Griffiths Senior Engineer (Mir) Location: United Kingdom canonical.com <https://canonical.com/> ubuntu.com <https://ubuntu.com/>
Re: Qustion: Support for Splitting Application Output Across Multiple Displays in Weston
On Fri, Mar 29, 2024 at 06:46:04PM +0900, Yosuke Nakayama wrote: > Thanks for the quick response. > > > With a (new) shell, or maybe with additions to desktop-shell, it would > allow the following to create a virtual output: > Does this mean that the existing shells (xdg-shell, kiosk-shell, ivi-shell, > etc.) cannot achieve the functionality? No, not in the sanse I've described earlier (using the maximized,fullscreen requests). With desktop-shell, you can create a region that spans all the outputs, but not with kiosk-shell. I don't know about ivi-shell, but with ivi-shell you can have other controllers which can problably achieve that, but similarly to the new shell, you might have to write it. Might want to take a look at the wayland-ivi-extension see if it that has something like that. > > On Fri, Mar 29, 2024 at 5:45 PM Marius Vlad > wrote: > > > On Fri, Mar 29, 2024 at 10:20:50AM +0900, Yosuke Nakayama wrote: > > > Dear Wayland-devel Community, > > Hi, > > > > > > I am currently exploring the capabilities of Weston, the reference > > > compositor for Wayland, specifically in the context of an application use > > > case that I am working on. My goal is to achieve a functionality where > > the > > > graphical output of a single application can be divided and displayed > > > simultaneously across two separate displays. This functionality would > > > enable part of the application window to be shown on one display and the > > > rest on another, effectively spanning the application window across > > > multiple screens. > > > > > > From my understanding and current experimentation with Weston, this > > > particular use case does not seem to be directly supported, but I'm not > > > sure. Does functionality exist at this time to achieve such a use case? > > In desktop-shell, maximized and fullscreen xdg-shell calls for a > > particular will *not* span across multiple outputs, nor there's a way to > > define a virtual output that will add up multiple physical outputs into > > a virtual one. For kiosk-shell, windows will be fullscreen'ed to a > > particular output. That doesn't mean this can't be done. With a (new) > > shell, or maybe with additions to desktop-shell, it would allow the > > following to create a virtual output: > > > > [virtual-output] > > output=eDP-1,HDMI-A-1 > > name=MyVirtualOutput-1 > > > > Then, the compositor will advertise this output as well such that the > > client can issue a maximized, fullscreen request and have client spanned > > across those outputs. > > > > > > > > Thank you for your time and assistance! > > > > > > Best regards, > > signature.asc Description: PGP signature
Re: Issue with starting Weston service
On Fri, Mar 29, 2024 at 12:28:36AM +0530, Akshaya Maran wrote:
> Hi,
Hi,
>
> I am facing an issue while trying to start the weston service .
> Below is the error message :
>
> *weston.service - Weston, a Wayland compositor, as a system service*
>
> * Loaded: loaded (/lib/systemd/system/weston.service; disabled; preset:
> enabled)*
>
> * Active: failed (Result: exit-code)*
>
> *TriggeredBy: �● weston.socket*
>
> * Docs: man:weston(1)*
>
> * man:weston.ini(5)*
>
> * http://wayland.freedesktop.org/
> <http://wayland.freedesktop.org/>*
>
> *Process: 167 ExecStart=/usr/bin/weston
> --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so
> (code=exited, status=1/FAILURE)*
>
> * Main PID: 167 (code=exited, status=1/FAILURE)*
>
> *CPU: 28ms*
>
>
> * weston[167]: failed to load swrast driver*
>
> * weston[167]: Internal warning: debug scope 'drm-backend' has not been
> destroyed.*
>
> * weston[167]: PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]*
These issues are related to the graphics driver/display driver and not Weston.
Either your installation is broken, incomplete, it's missing something else to
run
(kernel driver loaded), it can't run on your system, or something else is
already
using the same resource (DRM master) on system. Suggest looking for
'PVRDRMOpenRender' as that might further assistance to get the graphics
driver working.
>
> * weston[167]: PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ]*
>
> * weston[167]: PVR:(Error): Couldn't connect to services [0, ]*
>
> * weston[167]: PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services
> initialisation failed [0, ]*
>
> * weston[167]: PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL
> global data [0, ]*
>
> * systemd[1]: weston.service: Main process exited, code=exited,
> status=1/FAILURE*
>
> * systemd[1]: weston.service: Failed with result 'exit-code'.*
>
> * systemd[1]: Failed to start weston.service.*
>
> Can you please help me to understand and fix this error ?
>
> Thanks,
> Akshaya.M
signature.asc
Description: PGP signature
Re: Qustion: Support for Splitting Application Output Across Multiple Displays in Weston
On Fri, Mar 29, 2024 at 10:20:50AM +0900, Yosuke Nakayama wrote: > Dear Wayland-devel Community, Hi, > > I am currently exploring the capabilities of Weston, the reference > compositor for Wayland, specifically in the context of an application use > case that I am working on. My goal is to achieve a functionality where the > graphical output of a single application can be divided and displayed > simultaneously across two separate displays. This functionality would > enable part of the application window to be shown on one display and the > rest on another, effectively spanning the application window across > multiple screens. > > From my understanding and current experimentation with Weston, this > particular use case does not seem to be directly supported, but I'm not > sure. Does functionality exist at this time to achieve such a use case? In desktop-shell, maximized and fullscreen xdg-shell calls for a particular will *not* span across multiple outputs, nor there's a way to define a virtual output that will add up multiple physical outputs into a virtual one. For kiosk-shell, windows will be fullscreen'ed to a particular output. That doesn't mean this can't be done. With a (new) shell, or maybe with additions to desktop-shell, it would allow the following to create a virtual output: [virtual-output] output=eDP-1,HDMI-A-1 name=MyVirtualOutput-1 Then, the compositor will advertise this output as well such that the client can issue a maximized, fullscreen request and have client spanned across those outputs. > > Thank you for your time and assistance! > > Best regards, signature.asc Description: PGP signature
Qustion: Support for Splitting Application Output Across Multiple Displays in Weston
Dear Wayland-devel Community, I am currently exploring the capabilities of Weston, the reference compositor for Wayland, specifically in the context of an application use case that I am working on. My goal is to achieve a functionality where the graphical output of a single application can be divided and displayed simultaneously across two separate displays. This functionality would enable part of the application window to be shown on one display and the rest on another, effectively spanning the application window across multiple screens. >From my understanding and current experimentation with Weston, this particular use case does not seem to be directly supported, but I'm not sure. Does functionality exist at this time to achieve such a use case? Thank you for your time and assistance! Best regards,
Issue with starting Weston service
Hi,
I am facing an issue while trying to start the weston service .
Below is the error message :
*weston.service - Weston, a Wayland compositor, as a system service*
* Loaded: loaded (/lib/systemd/system/weston.service; disabled; preset:
enabled)*
* Active: failed (Result: exit-code)*
*TriggeredBy: �● weston.socket*
* Docs: man:weston(1)*
* man:weston.ini(5)*
* http://wayland.freedesktop.org/
<http://wayland.freedesktop.org/>*
*Process: 167 ExecStart=/usr/bin/weston
--log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so
(code=exited, status=1/FAILURE)*
* Main PID: 167 (code=exited, status=1/FAILURE)*
*CPU: 28ms*
* weston[167]: failed to load swrast driver*
* weston[167]: Internal warning: debug scope 'drm-backend' has not been
destroyed.*
* weston[167]: PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]*
* weston[167]: PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ]*
* weston[167]: PVR:(Error): Couldn't connect to services [0, ]*
* weston[167]: PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services
initialisation failed [0, ]*
* weston[167]: PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL
global data [0, ]*
* systemd[1]: weston.service: Main process exited, code=exited,
status=1/FAILURE*
* systemd[1]: weston.service: Failed with result 'exit-code'.*
* systemd[1]: Failed to start weston.service.*
Can you please help me to understand and fix this error ?
Thanks,
Akshaya.M
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On 05/03/2024 12:26, Pekka Paalanen wrote: On Mon, 4 Mar 2024 17:59:25 + Terry Barnaby wrote: On 04/03/2024 15:50, Pekka Paalanen wrote: On Mon, 4 Mar 2024 14:51:52 + Terry Barnaby wrote: On 04/03/2024 14:14, Pekka Paalanen wrote: On Mon, 4 Mar 2024 13:24:56 + Terry Barnaby wrote: On 04/03/2024 09:41, Pekka Paalanen wrote: On Mon, 4 Mar 2024 08:12:10 + Terry Barnaby wrote: While I am trying to investigate my issue in the QtWayland arena via the Qt Jira Bug system, I thought I would try taking Qt out of the equation to simplify the application a bit more to try and gain some understanding of what is going on and how this should all work. So I have created a pure GStreamer/Wayland/Weston application to test out how this should work. This is at: https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz This tries to implement a C++ Widget style application using native Wayland. It is rough and could easily be doing things wrong wrt Wayland. However it does work to a reasonable degree. However, I appear to see the same sort of issue I see with my Qt based system in that when a subsurface of a subsurface is used, the Gstreamer video is not seen. This example normally (UseWidgetTop=0) has a top level xdg_toplevel desktop surface (Gui), a subsurface to that (Video) and then waylandsink creates a subsurface to that which it sets to de-sync mode. When this example is run with UseWidgetTop=0 the video frames from gstreamer are only shown shown when the top subsurface is manually committed with gvideo->update() every second, otherwise the video pipeline is stalled. This is intentional. From wl_subsurface specification: Even if a sub-surface is in desynchronized mode, it will behave as in synchronized mode, if its parent surface behaves as in synchronized mode. This rule is applied recursively throughout the tree of surfaces. This means, that one can set a sub-surface into synchronized mode, and then assume that all its child and grand-child sub-surfaces are synchronized, too, without explicitly setting them. This is derived from the design decision that a wl_surface and its immediate sub-surfaces form a seamlessly integrated unit that works like a single wl_surface without sub-surfaces would. wl_subsurface state is state in the sub-surface's parent, so that the parent controls everything as if there was just a single wl_surface. If the parent sets its sub-surface as desynchronized, it explicitly gives the sub-surface the permission to update on screen regardless of the parent's updates. When the sub-surface is in synchronized mode, the parent surface wants to be updated in sync with the sub-surface in an atomic fashion. When your surface stack looks like: - main surface A, top-level, root surface (implicitly desynchronized) - sub-surface B, synchronized - sub-surface C, desynchronized Updates to surface C are immediately made part of surface B, because surface C is in desynchronized mode. If B was the root surface, all C updates would simply go through. However, surface B is a part of surface A, and surface B is in synchronized mode. This means that the client wants surface A updates to be explicit and atomic. Nothing must change on screen until A is explicitly committed itself. So any update to surface B requires a commit on surface A to become visible. Surface C does not get to override the atomicity requirement of surface A updates. This has been designed so that software component A can control surface A, and delegate a part of surface A to component B which happens to the using a sub-surface: surface B. If surface B parts are further delegated to another component C, then component A can still be sure that nothing updates on surface A until it says so. Component A sets surface B to synchronized to ensure that. That's the rationale behind the Wayland design. Thanks, pq Ah, thanks for the info, that may be why this is not working even in Qt then. This seems a dropoff in Wayland to me. If a software module wants to display Video into an area on the screen at its own rate, setting that surface to de-synced mode is no use in the general case with this policy. It is of use, if you don't have unnecessary sub-surfaces in synchronized mode in between, or you set all those extra sub-surfaces to desynchronized as well. Well they may not be necessary from the Wayland perspective, but from the higher level software they are useful to modularise/separate/provide a join for the software modules especially when software modules are separate like Qt and GStreamer. Sorry to hear that. I would have thought that if a subsurface was explicitly set to de-synced mode then that would be honoured. I can't see a usage case for it to be ignored and its commits synchronised up the tree ? Resizing the window is the main use case. In order to resize surface A, you also n
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On 08/03/2024 15:23, Pekka Paalanen wrote: On Fri, 8 Mar 2024 14:50:30 + Terry Barnaby wrote: On 05/03/2024 12:26, Pekka Paalanen wrote: On Mon, 4 Mar 2024 17:59:25 + Terry Barnaby wrote: ... I would have thought it better/more useful to have a Wayland API call like "stopCommiting" so that an application can sort things out for this and other things, providing more application control. But I really have only very limited knowledge of the Wayland system. I just keep hitting its restrictions. Right, Wayland does not work that way. Wayland sees any client as a single entity, regardless of its internal composition of libraries and others. When Wayland delivers any event, whether it is an explicit resize event or an input event (or maybe the client just spontaneously decides to), that causes the client to want to resize a window, it is then up to the client itself to make sure it resizes everything it needs to, and keeps everything atomic so that the end user does not see glitches on screen. Sub-surfaces' synchronous mode was needed to let clients batch the updates of multiple surfaces into a single atomic commit. It is the desync mode that was a non-mandatory add-on. The synchronous mode was needed, because there was no other way to batch multiple wl_surface.commit requests to apply simultaneously guaranteed. Without it, if you commit surface A and then surface B, nothing will guarantee that the compositor would not show A updated and B not on screen for a moment. Wayland intentionally did not include any mechanism in its design intended for communication between a single client's internal components. Why use a display server as an IPC middle-man for something that should be process-internal communication. After all, Wayland is primarily a protocol - inter-process communication. Well as you say it is up to the client to perform all of the surface resize work. So it seems to me, if the client had an issue with pixel perfect resizing it could always set any of its desynced surfaces to sync mode, or just stop the update to them, while it resizes. I don't see why Wayland needs to ignore the clients request to set a subsurface desynced down the tree. You're right, but it's in the spec now. I've gained a bit more experience in the decade after writing the sub-surface spec. You can still work around it by setting all sub-surfaces always desync. Oh you wrote it, thanks for the work! So maybe time for version n+1 then :) Actually allowing sub/subsurfaces to work in desync should not break any existing clients as they cannot use it yet. Obviously new clients written for it would not work on older Wayland servers though. Its difficult to desync all the higher surfaces in a Qt or probably other Widget set application, they are controlled by Qt and Qt does not give you access to the subsurfaces it has created. It would be better to have had a wl_surface_set_desync(wl_surface*) rather than a wl_subsurface_set_desync(wl_subsurface*). With clients using lots of libraries/subsystems it is better to not use their internal workings unless you have to. Normally you try and work at the least common denominator, in this case the Wayland display system as that is the shared module they both use (at least when driving a Wayland display server). This is why it is nice to have a surface that is almost totally independent of others and just is shown/not shown, is over/below etc. other surfaces like an XWindow. The Wayland surfaces are mainly this as far as I can see, apart from this desync mode although maybe there are others. I have asked in the Qt forums if they could provide some sort of API to allow the setting of desync up the tree, but this may not happen and it might be difficult for them as it could mess up their applications rendering. It also does not match other display system API's that they support. The higher level QWidgets ideally need synced surfaces, its just the Video surfaces that need desync. Really I think this is the Wayland servers job. In fact does it return an error to the client when the Wayland server ignores this command ? There is no "return error" in Wayland. Either a request succeeds, or the client is disconnected with an error. It's all asynchronous, too. Any possibility for graceful failure must be designed into protocol extensions at one step higher level. If there is room for a graceful failure, it will be mentioned in the XML spec with explicit messages to communicate it. Which command do you mean? I meant the wl_subsurface_set_desync() API call on a sub/subsurface that doesn't work. As no errors were returned it took a long time to find out why things weren't working, just some lower level threads locked up. Personally I think these sort of occasional, performance irrelevant, types of methods/requests/commands should be synchronous (maybe under an asynchronous comms system) and return an error. Makes developing clients
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Fri, 8 Mar 2024 14:50:30 + Terry Barnaby wrote: > On 05/03/2024 12:26, Pekka Paalanen wrote: > > On Mon, 4 Mar 2024 17:59:25 + > > Terry Barnaby wrote: > > ... > >> I would have thought it better/more useful to have a Wayland API call > >> like "stopCommiting" so that an application can sort things out for this > >> and other things, providing more application control. But I really have > >> only very limited knowledge of the Wayland system. I just keep hitting > >> its restrictions. > >> > > Right, Wayland does not work that way. Wayland sees any client as a > > single entity, regardless of its internal composition of libraries and > > others. > > > > When Wayland delivers any event, whether it is an explicit resize event > > or an input event (or maybe the client just spontaneously decides to), > > that causes the client to want to resize a window, it is then up to the > > client itself to make sure it resizes everything it needs to, and keeps > > everything atomic so that the end user does not see glitches on screen. > > > > Sub-surfaces' synchronous mode was needed to let clients batch the > > updates of multiple surfaces into a single atomic commit. It is the > > desync mode that was a non-mandatory add-on. The synchronous mode was > > needed, because there was no other way to batch multiple > > wl_surface.commit requests to apply simultaneously guaranteed. Without > > it, if you commit surface A and then surface B, nothing will guarantee > > that the compositor would not show A updated and B not on screen for a > > moment. > > > > Wayland intentionally did not include any mechanism in its design > > intended for communication between a single client's internal > > components. Why use a display server as an IPC middle-man for something > > that should be process-internal communication. After all, Wayland is > > primarily a protocol - inter-process communication. > > Well as you say it is up to the client to perform all of the surface > resize work. So it seems to me, if the client had an issue with pixel > perfect resizing it could always set any of its desynced surfaces to > sync mode, or just stop the update to them, while it resizes. I don't > see why Wayland needs to ignore the clients request to set a subsurface > desynced down the tree. You're right, but it's in the spec now. I've gained a bit more experience in the decade after writing the sub-surface spec. You can still work around it by setting all sub-surfaces always desync. > In fact does it return an error to the client > when the Wayland server ignores this command ? There is no "return error" in Wayland. Either a request succeeds, or the client is disconnected with an error. It's all asynchronous, too. Any possibility for graceful failure must be designed into protocol extensions at one step higher level. If there is room for a graceful failure, it will be mentioned in the XML spec with explicit messages to communicate it. Which command do you mean? There is no "ignore" with wl_surface nor wl_subsurface. wl_surface.commit is always acted upon, but the sub-surface sync mode determines whether the state update goes to the screen or to a cache. No state update is ignored unless you destroy your objects. The frame callbacks that seem to go unanswered are not ignored, they are just sitting in the cache waiting to apply when the parent surface actually updates on screen. Thanks, pq pgpdoXGYQYgtl.pgp Description: OpenPGP digital signature
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On 05/03/2024 12:26, Pekka Paalanen wrote: On Mon, 4 Mar 2024 17:59:25 + Terry Barnaby wrote: On 04/03/2024 15:50, Pekka Paalanen wrote: On Mon, 4 Mar 2024 14:51:52 + Terry Barnaby wrote: On 04/03/2024 14:14, Pekka Paalanen wrote: On Mon, 4 Mar 2024 13:24:56 + Terry Barnaby wrote: On 04/03/2024 09:41, Pekka Paalanen wrote: On Mon, 4 Mar 2024 08:12:10 + Terry Barnaby wrote: While I am trying to investigate my issue in the QtWayland arena via the Qt Jira Bug system, I thought I would try taking Qt out of the equation to simplify the application a bit more to try and gain some understanding of what is going on and how this should all work. So I have created a pure GStreamer/Wayland/Weston application to test out how this should work. This is at: https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz This tries to implement a C++ Widget style application using native Wayland. It is rough and could easily be doing things wrong wrt Wayland. However it does work to a reasonable degree. However, I appear to see the same sort of issue I see with my Qt based system in that when a subsurface of a subsurface is used, the Gstreamer video is not seen. This example normally (UseWidgetTop=0) has a top level xdg_toplevel desktop surface (Gui), a subsurface to that (Video) and then waylandsink creates a subsurface to that which it sets to de-sync mode. When this example is run with UseWidgetTop=0 the video frames from gstreamer are only shown shown when the top subsurface is manually committed with gvideo->update() every second, otherwise the video pipeline is stalled. This is intentional. From wl_subsurface specification: Even if a sub-surface is in desynchronized mode, it will behave as in synchronized mode, if its parent surface behaves as in synchronized mode. This rule is applied recursively throughout the tree of surfaces. This means, that one can set a sub-surface into synchronized mode, and then assume that all its child and grand-child sub-surfaces are synchronized, too, without explicitly setting them. This is derived from the design decision that a wl_surface and its immediate sub-surfaces form a seamlessly integrated unit that works like a single wl_surface without sub-surfaces would. wl_subsurface state is state in the sub-surface's parent, so that the parent controls everything as if there was just a single wl_surface. If the parent sets its sub-surface as desynchronized, it explicitly gives the sub-surface the permission to update on screen regardless of the parent's updates. When the sub-surface is in synchronized mode, the parent surface wants to be updated in sync with the sub-surface in an atomic fashion. When your surface stack looks like: - main surface A, top-level, root surface (implicitly desynchronized) - sub-surface B, synchronized - sub-surface C, desynchronized Updates to surface C are immediately made part of surface B, because surface C is in desynchronized mode. If B was the root surface, all C updates would simply go through. However, surface B is a part of surface A, and surface B is in synchronized mode. This means that the client wants surface A updates to be explicit and atomic. Nothing must change on screen until A is explicitly committed itself. So any update to surface B requires a commit on surface A to become visible. Surface C does not get to override the atomicity requirement of surface A updates. This has been designed so that software component A can control surface A, and delegate a part of surface A to component B which happens to the using a sub-surface: surface B. If surface B parts are further delegated to another component C, then component A can still be sure that nothing updates on surface A until it says so. Component A sets surface B to synchronized to ensure that. That's the rationale behind the Wayland design. Thanks, pq Ah, thanks for the info, that may be why this is not working even in Qt then. This seems a dropoff in Wayland to me. If a software module wants to display Video into an area on the screen at its own rate, setting that surface to de-synced mode is no use in the general case with this policy. It is of use, if you don't have unnecessary sub-surfaces in synchronized mode in between, or you set all those extra sub-surfaces to desynchronized as well. Well they may not be necessary from the Wayland perspective, but from the higher level software they are useful to modularise/separate/provide a join for the software modules especially when software modules are separate like Qt and GStreamer. Sorry to hear that. I would have thought that if a subsurface was explicitly set to de-synced mode then that would be honoured. I can't see a usage case for it to be ignored and its commits synchronised up the tree ? Resizing the window is the main use case. In order to resize surface A, you also need to resize and paint surface B, and for surface B you also n
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Mon, 4 Mar 2024 17:59:25 + Terry Barnaby wrote: > On 04/03/2024 15:50, Pekka Paalanen wrote: > > On Mon, 4 Mar 2024 14:51:52 + > > Terry Barnaby wrote: > > > >> On 04/03/2024 14:14, Pekka Paalanen wrote: > >>> On Mon, 4 Mar 2024 13:24:56 + > >>> Terry Barnaby wrote: > >>> > >>>> On 04/03/2024 09:41, Pekka Paalanen wrote: > >>>>> On Mon, 4 Mar 2024 08:12:10 + > >>>>> Terry Barnaby wrote: > >>>>> > >>>>>> While I am trying to investigate my issue in the QtWayland arena via > >>>>>> the > >>>>>> Qt Jira Bug system, I thought I would try taking Qt out of the equation > >>>>>> to simplify the application a bit more to try and gain some > >>>>>> understanding of what is going on and how this should all work. > >>>>>> > >>>>>> So I have created a pure GStreamer/Wayland/Weston application to test > >>>>>> out how this should work. This is at: > >>>>>> https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz > >>>>>> > >>>>>> This tries to implement a C++ Widget style application using native > >>>>>> Wayland. It is rough and could easily be doing things wrong wrt > >>>>>> Wayland. > >>>>>> However it does work to a reasonable degree. > >>>>>> > >>>>>> However, I appear to see the same sort of issue I see with my Qt based > >>>>>> system in that when a subsurface of a subsurface is used, the Gstreamer > >>>>>> video is not seen. > >>>>>> > >>>>>> This example normally (UseWidgetTop=0) has a top level xdg_toplevel > >>>>>> desktop surface (Gui), a subsurface to that (Video) and then > >>>>>> waylandsink > >>>>>> creates a subsurface to that which it sets to de-sync mode. > >>>>>> > >>>>>> When this example is run with UseWidgetTop=0 the video frames from > >>>>>> gstreamer are only shown shown when the top subsurface is manually > >>>>>> committed with gvideo->update() every second, otherwise the video > >>>>>> pipeline is stalled. > >>>>> This is intentional. From wl_subsurface specification: > >>>>> > >>>>> Even if a sub-surface is in desynchronized mode, it will > >>>>> behave as > >>>>> in synchronized mode, if its parent surface behaves as in > >>>>> synchronized mode. This rule is applied recursively throughout > >>>>> the > >>>>> tree of surfaces. This means, that one can set a sub-surface > >>>>> into > >>>>> synchronized mode, and then assume that all its child and > >>>>> grand-child > >>>>> sub-surfaces are synchronized, too, without explicitly setting > >>>>> them. > >>>>> > >>>>> This is derived from the design decision that a wl_surface and its > >>>>> immediate sub-surfaces form a seamlessly integrated unit that works > >>>>> like a single wl_surface without sub-surfaces would. wl_subsurface > >>>>> state is state in the sub-surface's parent, so that the parent controls > >>>>> everything as if there was just a single wl_surface. If the parent sets > >>>>> its sub-surface as desynchronized, it explicitly gives the sub-surface > >>>>> the permission to update on screen regardless of the parent's updates. > >>>>> When the sub-surface is in synchronized mode, the parent surface wants > >>>>> to be updated in sync with the sub-surface in an atomic fashion. > >>>>> > >>>>> When your surface stack looks like: > >>>>> > >>>>> - main surface A, top-level, root surface (implicitly desynchronized) > >>>>> - sub-surface B, synchronized > >>>>>- sub-surface C, desynchronized > >>>>> > >>>>> Updates to surface C are immediately made part of surface B, because > >>>>> surface C is in desynchronized mode. If B was the root surface, all C > >>>>> updates would simply go th
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On 04/03/2024 15:50, Pekka Paalanen wrote: On Mon, 4 Mar 2024 14:51:52 + Terry Barnaby wrote: On 04/03/2024 14:14, Pekka Paalanen wrote: On Mon, 4 Mar 2024 13:24:56 + Terry Barnaby wrote: On 04/03/2024 09:41, Pekka Paalanen wrote: On Mon, 4 Mar 2024 08:12:10 + Terry Barnaby wrote: While I am trying to investigate my issue in the QtWayland arena via the Qt Jira Bug system, I thought I would try taking Qt out of the equation to simplify the application a bit more to try and gain some understanding of what is going on and how this should all work. So I have created a pure GStreamer/Wayland/Weston application to test out how this should work. This is at: https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz This tries to implement a C++ Widget style application using native Wayland. It is rough and could easily be doing things wrong wrt Wayland. However it does work to a reasonable degree. However, I appear to see the same sort of issue I see with my Qt based system in that when a subsurface of a subsurface is used, the Gstreamer video is not seen. This example normally (UseWidgetTop=0) has a top level xdg_toplevel desktop surface (Gui), a subsurface to that (Video) and then waylandsink creates a subsurface to that which it sets to de-sync mode. When this example is run with UseWidgetTop=0 the video frames from gstreamer are only shown shown when the top subsurface is manually committed with gvideo->update() every second, otherwise the video pipeline is stalled. This is intentional. From wl_subsurface specification: Even if a sub-surface is in desynchronized mode, it will behave as in synchronized mode, if its parent surface behaves as in synchronized mode. This rule is applied recursively throughout the tree of surfaces. This means, that one can set a sub-surface into synchronized mode, and then assume that all its child and grand-child sub-surfaces are synchronized, too, without explicitly setting them. This is derived from the design decision that a wl_surface and its immediate sub-surfaces form a seamlessly integrated unit that works like a single wl_surface without sub-surfaces would. wl_subsurface state is state in the sub-surface's parent, so that the parent controls everything as if there was just a single wl_surface. If the parent sets its sub-surface as desynchronized, it explicitly gives the sub-surface the permission to update on screen regardless of the parent's updates. When the sub-surface is in synchronized mode, the parent surface wants to be updated in sync with the sub-surface in an atomic fashion. When your surface stack looks like: - main surface A, top-level, root surface (implicitly desynchronized) - sub-surface B, synchronized - sub-surface C, desynchronized Updates to surface C are immediately made part of surface B, because surface C is in desynchronized mode. If B was the root surface, all C updates would simply go through. However, surface B is a part of surface A, and surface B is in synchronized mode. This means that the client wants surface A updates to be explicit and atomic. Nothing must change on screen until A is explicitly committed itself. So any update to surface B requires a commit on surface A to become visible. Surface C does not get to override the atomicity requirement of surface A updates. This has been designed so that software component A can control surface A, and delegate a part of surface A to component B which happens to the using a sub-surface: surface B. If surface B parts are further delegated to another component C, then component A can still be sure that nothing updates on surface A until it says so. Component A sets surface B to synchronized to ensure that. That's the rationale behind the Wayland design. Thanks, pq Ah, thanks for the info, that may be why this is not working even in Qt then. This seems a dropoff in Wayland to me. If a software module wants to display Video into an area on the screen at its own rate, setting that surface to de-synced mode is no use in the general case with this policy. It is of use, if you don't have unnecessary sub-surfaces in synchronized mode in between, or you set all those extra sub-surfaces to desynchronized as well. Well they may not be necessary from the Wayland perspective, but from the higher level software they are useful to modularise/separate/provide a join for the software modules especially when software modules are separate like Qt and GStreamer. Sorry to hear that. I would have thought that if a subsurface was explicitly set to de-synced mode then that would be honoured. I can't see a usage case for it to be ignored and its commits synchronised up the tree ? Resizing the window is the main use case. In order to resize surface A, you also need to resize and paint surface B, and for surface B you also need to resize and paint surface C. Then you need to guaran
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Mon, 4 Mar 2024 14:51:52 + Terry Barnaby wrote: > On 04/03/2024 14:14, Pekka Paalanen wrote: > > On Mon, 4 Mar 2024 13:24:56 + > > Terry Barnaby wrote: > > > >> On 04/03/2024 09:41, Pekka Paalanen wrote: > >>> On Mon, 4 Mar 2024 08:12:10 + > >>> Terry Barnaby wrote: > >>> > >>>> While I am trying to investigate my issue in the QtWayland arena via the > >>>> Qt Jira Bug system, I thought I would try taking Qt out of the equation > >>>> to simplify the application a bit more to try and gain some > >>>> understanding of what is going on and how this should all work. > >>>> > >>>> So I have created a pure GStreamer/Wayland/Weston application to test > >>>> out how this should work. This is at: > >>>> https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz > >>>> > >>>> This tries to implement a C++ Widget style application using native > >>>> Wayland. It is rough and could easily be doing things wrong wrt Wayland. > >>>> However it does work to a reasonable degree. > >>>> > >>>> However, I appear to see the same sort of issue I see with my Qt based > >>>> system in that when a subsurface of a subsurface is used, the Gstreamer > >>>> video is not seen. > >>>> > >>>> This example normally (UseWidgetTop=0) has a top level xdg_toplevel > >>>> desktop surface (Gui), a subsurface to that (Video) and then waylandsink > >>>> creates a subsurface to that which it sets to de-sync mode. > >>>> > >>>> When this example is run with UseWidgetTop=0 the video frames from > >>>> gstreamer are only shown shown when the top subsurface is manually > >>>> committed with gvideo->update() every second, otherwise the video > >>>> pipeline is stalled. > >>> This is intentional. From wl_subsurface specification: > >>> > >>> Even if a sub-surface is in desynchronized mode, it will behave as > >>> in synchronized mode, if its parent surface behaves as in > >>> synchronized mode. This rule is applied recursively throughout the > >>> tree of surfaces. This means, that one can set a sub-surface into > >>> synchronized mode, and then assume that all its child and > >>> grand-child > >>> sub-surfaces are synchronized, too, without explicitly setting > >>> them. > >>> > >>> This is derived from the design decision that a wl_surface and its > >>> immediate sub-surfaces form a seamlessly integrated unit that works > >>> like a single wl_surface without sub-surfaces would. wl_subsurface > >>> state is state in the sub-surface's parent, so that the parent controls > >>> everything as if there was just a single wl_surface. If the parent sets > >>> its sub-surface as desynchronized, it explicitly gives the sub-surface > >>> the permission to update on screen regardless of the parent's updates. > >>> When the sub-surface is in synchronized mode, the parent surface wants > >>> to be updated in sync with the sub-surface in an atomic fashion. > >>> > >>> When your surface stack looks like: > >>> > >>> - main surface A, top-level, root surface (implicitly desynchronized) > >>> - sub-surface B, synchronized > >>> - sub-surface C, desynchronized > >>> > >>> Updates to surface C are immediately made part of surface B, because > >>> surface C is in desynchronized mode. If B was the root surface, all C > >>> updates would simply go through. > >>> > >>> However, surface B is a part of surface A, and surface B is in > >>> synchronized mode. This means that the client wants surface A updates to > >>> be explicit and atomic. Nothing must change on screen until A is > >>> explicitly committed itself. So any update to surface B requires a > >>> commit on surface A to become visible. Surface C does not get to > >>> override the atomicity requirement of surface A updates. > >>> > >>> This has been designed so that software component A can control surface > >>> A, and delegate a part of surface A to component B which happens to the > >>> using a sub-surface: surface B. If surface B parts are further > >>> delegated to another compo
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On 04/03/2024 14:14, Pekka Paalanen wrote: On Mon, 4 Mar 2024 13:24:56 + Terry Barnaby wrote: On 04/03/2024 09:41, Pekka Paalanen wrote: On Mon, 4 Mar 2024 08:12:10 + Terry Barnaby wrote: While I am trying to investigate my issue in the QtWayland arena via the Qt Jira Bug system, I thought I would try taking Qt out of the equation to simplify the application a bit more to try and gain some understanding of what is going on and how this should all work. So I have created a pure GStreamer/Wayland/Weston application to test out how this should work. This is at: https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz This tries to implement a C++ Widget style application using native Wayland. It is rough and could easily be doing things wrong wrt Wayland. However it does work to a reasonable degree. However, I appear to see the same sort of issue I see with my Qt based system in that when a subsurface of a subsurface is used, the Gstreamer video is not seen. This example normally (UseWidgetTop=0) has a top level xdg_toplevel desktop surface (Gui), a subsurface to that (Video) and then waylandsink creates a subsurface to that which it sets to de-sync mode. When this example is run with UseWidgetTop=0 the video frames from gstreamer are only shown shown when the top subsurface is manually committed with gvideo->update() every second, otherwise the video pipeline is stalled. This is intentional. From wl_subsurface specification: Even if a sub-surface is in desynchronized mode, it will behave as in synchronized mode, if its parent surface behaves as in synchronized mode. This rule is applied recursively throughout the tree of surfaces. This means, that one can set a sub-surface into synchronized mode, and then assume that all its child and grand-child sub-surfaces are synchronized, too, without explicitly setting them. This is derived from the design decision that a wl_surface and its immediate sub-surfaces form a seamlessly integrated unit that works like a single wl_surface without sub-surfaces would. wl_subsurface state is state in the sub-surface's parent, so that the parent controls everything as if there was just a single wl_surface. If the parent sets its sub-surface as desynchronized, it explicitly gives the sub-surface the permission to update on screen regardless of the parent's updates. When the sub-surface is in synchronized mode, the parent surface wants to be updated in sync with the sub-surface in an atomic fashion. When your surface stack looks like: - main surface A, top-level, root surface (implicitly desynchronized) - sub-surface B, synchronized - sub-surface C, desynchronized Updates to surface C are immediately made part of surface B, because surface C is in desynchronized mode. If B was the root surface, all C updates would simply go through. However, surface B is a part of surface A, and surface B is in synchronized mode. This means that the client wants surface A updates to be explicit and atomic. Nothing must change on screen until A is explicitly committed itself. So any update to surface B requires a commit on surface A to become visible. Surface C does not get to override the atomicity requirement of surface A updates. This has been designed so that software component A can control surface A, and delegate a part of surface A to component B which happens to the using a sub-surface: surface B. If surface B parts are further delegated to another component C, then component A can still be sure that nothing updates on surface A until it says so. Component A sets surface B to synchronized to ensure that. That's the rationale behind the Wayland design. Thanks, pq Ah, thanks for the info, that may be why this is not working even in Qt then. This seems a dropoff in Wayland to me. If a software module wants to display Video into an area on the screen at its own rate, setting that surface to de-synced mode is no use in the general case with this policy. It is of use, if you don't have unnecessary sub-surfaces in synchronized mode in between, or you set all those extra sub-surfaces to desynchronized as well. Well they may not be necessary from the Wayland perspective, but from the higher level software they are useful to modularise/separate/provide a join for the software modules especially when software modules are separate like Qt and GStreamer. I would have thought that if a subsurface was explicitly set to de-synced mode then that would be honoured. I can't see a usage case for it to be ignored and its commits synchronised up the tree ? Resizing the window is the main use case. In order to resize surface A, you also need to resize and paint surface B, and for surface B you also need to resize and paint surface C. Then you need to guarantee that all the updates from surface C, B and A are applied atomically on screen. Either you have component APIs good eno
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Mon, 4 Mar 2024 13:24:56 + Terry Barnaby wrote: > On 04/03/2024 09:41, Pekka Paalanen wrote: > > On Mon, 4 Mar 2024 08:12:10 + > > Terry Barnaby wrote: > > > >> While I am trying to investigate my issue in the QtWayland arena via the > >> Qt Jira Bug system, I thought I would try taking Qt out of the equation > >> to simplify the application a bit more to try and gain some > >> understanding of what is going on and how this should all work. > >> > >> So I have created a pure GStreamer/Wayland/Weston application to test > >> out how this should work. This is at: > >> https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz > >> > >> This tries to implement a C++ Widget style application using native > >> Wayland. It is rough and could easily be doing things wrong wrt Wayland. > >> However it does work to a reasonable degree. > >> > >> However, I appear to see the same sort of issue I see with my Qt based > >> system in that when a subsurface of a subsurface is used, the Gstreamer > >> video is not seen. > >> > >> This example normally (UseWidgetTop=0) has a top level xdg_toplevel > >> desktop surface (Gui), a subsurface to that (Video) and then waylandsink > >> creates a subsurface to that which it sets to de-sync mode. > >> > >> When this example is run with UseWidgetTop=0 the video frames from > >> gstreamer are only shown shown when the top subsurface is manually > >> committed with gvideo->update() every second, otherwise the video > >> pipeline is stalled. > > This is intentional. From wl_subsurface specification: > > > >Even if a sub-surface is in desynchronized mode, it will behave as > >in synchronized mode, if its parent surface behaves as in > >synchronized mode. This rule is applied recursively throughout the > >tree of surfaces. This means, that one can set a sub-surface into > >synchronized mode, and then assume that all its child and grand-child > >sub-surfaces are synchronized, too, without explicitly setting them. > > > > This is derived from the design decision that a wl_surface and its > > immediate sub-surfaces form a seamlessly integrated unit that works > > like a single wl_surface without sub-surfaces would. wl_subsurface > > state is state in the sub-surface's parent, so that the parent controls > > everything as if there was just a single wl_surface. If the parent sets > > its sub-surface as desynchronized, it explicitly gives the sub-surface > > the permission to update on screen regardless of the parent's updates. > > When the sub-surface is in synchronized mode, the parent surface wants > > to be updated in sync with the sub-surface in an atomic fashion. > > > > When your surface stack looks like: > > > > - main surface A, top-level, root surface (implicitly desynchronized) > >- sub-surface B, synchronized > > - sub-surface C, desynchronized > > > > Updates to surface C are immediately made part of surface B, because > > surface C is in desynchronized mode. If B was the root surface, all C > > updates would simply go through. > > > > However, surface B is a part of surface A, and surface B is in > > synchronized mode. This means that the client wants surface A updates to > > be explicit and atomic. Nothing must change on screen until A is > > explicitly committed itself. So any update to surface B requires a > > commit on surface A to become visible. Surface C does not get to > > override the atomicity requirement of surface A updates. > > > > This has been designed so that software component A can control surface > > A, and delegate a part of surface A to component B which happens to the > > using a sub-surface: surface B. If surface B parts are further > > delegated to another component C, then component A can still be sure > > that nothing updates on surface A until it says so. Component A sets > > surface B to synchronized to ensure that. > > > > That's the rationale behind the Wayland design. > > > > > > Thanks, > > pq > > Ah, thanks for the info, that may be why this is not working even in Qt > then. > > This seems a dropoff in Wayland to me. If a software module wants to > display Video into an area on the screen at its own rate, setting that > surface to de-synced mode is no use in the general case with this > policy. It is of use, if you don't have unnecessary sub-surfaces in synchronized mode in between, or you set all t
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On 04/03/2024 09:41, Pekka Paalanen wrote: On Mon, 4 Mar 2024 08:12:10 + Terry Barnaby wrote: While I am trying to investigate my issue in the QtWayland arena via the Qt Jira Bug system, I thought I would try taking Qt out of the equation to simplify the application a bit more to try and gain some understanding of what is going on and how this should all work. So I have created a pure GStreamer/Wayland/Weston application to test out how this should work. This is at: https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz This tries to implement a C++ Widget style application using native Wayland. It is rough and could easily be doing things wrong wrt Wayland. However it does work to a reasonable degree. However, I appear to see the same sort of issue I see with my Qt based system in that when a subsurface of a subsurface is used, the Gstreamer video is not seen. This example normally (UseWidgetTop=0) has a top level xdg_toplevel desktop surface (Gui), a subsurface to that (Video) and then waylandsink creates a subsurface to that which it sets to de-sync mode. When this example is run with UseWidgetTop=0 the video frames from gstreamer are only shown shown when the top subsurface is manually committed with gvideo->update() every second, otherwise the video pipeline is stalled. This is intentional. From wl_subsurface specification: Even if a sub-surface is in desynchronized mode, it will behave as in synchronized mode, if its parent surface behaves as in synchronized mode. This rule is applied recursively throughout the tree of surfaces. This means, that one can set a sub-surface into synchronized mode, and then assume that all its child and grand-child sub-surfaces are synchronized, too, without explicitly setting them. This is derived from the design decision that a wl_surface and its immediate sub-surfaces form a seamlessly integrated unit that works like a single wl_surface without sub-surfaces would. wl_subsurface state is state in the sub-surface's parent, so that the parent controls everything as if there was just a single wl_surface. If the parent sets its sub-surface as desynchronized, it explicitly gives the sub-surface the permission to update on screen regardless of the parent's updates. When the sub-surface is in synchronized mode, the parent surface wants to be updated in sync with the sub-surface in an atomic fashion. When your surface stack looks like: - main surface A, top-level, root surface (implicitly desynchronized) - sub-surface B, synchronized - sub-surface C, desynchronized Updates to surface C are immediately made part of surface B, because surface C is in desynchronized mode. If B was the root surface, all C updates would simply go through. However, surface B is a part of surface A, and surface B is in synchronized mode. This means that the client wants surface A updates to be explicit and atomic. Nothing must change on screen until A is explicitly committed itself. So any update to surface B requires a commit on surface A to become visible. Surface C does not get to override the atomicity requirement of surface A updates. This has been designed so that software component A can control surface A, and delegate a part of surface A to component B which happens to the using a sub-surface: surface B. If surface B parts are further delegated to another component C, then component A can still be sure that nothing updates on surface A until it says so. Component A sets surface B to synchronized to ensure that. That's the rationale behind the Wayland design. Thanks, pq Ah, thanks for the info, that may be why this is not working even in Qt then. This seems a dropoff in Wayland to me. If a software module wants to display Video into an area on the screen at its own rate, setting that surface to de-synced mode is no use in the general case with this policy. I would have thought that if a subsurface was explicitly set to de-synced mode then that would be honoured. I can't see a usage case for it to be ignored and its commits synchronised up the tree ? So is there a way to actually display Video on a subsurface many levels deep in a surface hierarchy, would setting all of the surfaces up to the subsurface just below the desktop top level one work (although not ideal as it would mean overriding other software modules surfaces at the Wayland level) ? Or can desynced subsurfaces really only work to one level deep ? If it is just one subsurface level deep that video can be displayed, I guess I will have to get GStreamers waylandsink to create its subsurface off the top most surface and add calls to manage its surface from my app. Or maybe get waylandsinks subsurface and manipulate it behind waylandsinks back. Not sure what this will do to the Qt level though. Using the QWidgets subsurface as its base should have allowed isolation to a degree between the Qt and wayland sink sub syst
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Mon, 4 Mar 2024 08:12:10 + Terry Barnaby wrote: > While I am trying to investigate my issue in the QtWayland arena via the > Qt Jira Bug system, I thought I would try taking Qt out of the equation > to simplify the application a bit more to try and gain some > understanding of what is going on and how this should all work. > > So I have created a pure GStreamer/Wayland/Weston application to test > out how this should work. This is at: > https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz > > This tries to implement a C++ Widget style application using native > Wayland. It is rough and could easily be doing things wrong wrt Wayland. > However it does work to a reasonable degree. > > However, I appear to see the same sort of issue I see with my Qt based > system in that when a subsurface of a subsurface is used, the Gstreamer > video is not seen. > > This example normally (UseWidgetTop=0) has a top level xdg_toplevel > desktop surface (Gui), a subsurface to that (Video) and then waylandsink > creates a subsurface to that which it sets to de-sync mode. > > When this example is run with UseWidgetTop=0 the video frames from > gstreamer are only shown shown when the top subsurface is manually > committed with gvideo->update() every second, otherwise the video > pipeline is stalled. This is intentional. From wl_subsurface specification: Even if a sub-surface is in desynchronized mode, it will behave as in synchronized mode, if its parent surface behaves as in synchronized mode. This rule is applied recursively throughout the tree of surfaces. This means, that one can set a sub-surface into synchronized mode, and then assume that all its child and grand-child sub-surfaces are synchronized, too, without explicitly setting them. This is derived from the design decision that a wl_surface and its immediate sub-surfaces form a seamlessly integrated unit that works like a single wl_surface without sub-surfaces would. wl_subsurface state is state in the sub-surface's parent, so that the parent controls everything as if there was just a single wl_surface. If the parent sets its sub-surface as desynchronized, it explicitly gives the sub-surface the permission to update on screen regardless of the parent's updates. When the sub-surface is in synchronized mode, the parent surface wants to be updated in sync with the sub-surface in an atomic fashion. When your surface stack looks like: - main surface A, top-level, root surface (implicitly desynchronized) - sub-surface B, synchronized - sub-surface C, desynchronized Updates to surface C are immediately made part of surface B, because surface C is in desynchronized mode. If B was the root surface, all C updates would simply go through. However, surface B is a part of surface A, and surface B is in synchronized mode. This means that the client wants surface A updates to be explicit and atomic. Nothing must change on screen until A is explicitly committed itself. So any update to surface B requires a commit on surface A to become visible. Surface C does not get to override the atomicity requirement of surface A updates. This has been designed so that software component A can control surface A, and delegate a part of surface A to component B which happens to the using a sub-surface: surface B. If surface B parts are further delegated to another component C, then component A can still be sure that nothing updates on surface A until it says so. Component A sets surface B to synchronized to ensure that. That's the rationale behind the Wayland design. Thanks, pq > Waylandsink is stuck in a loop awaiting a Wayland > callback after committing its subsurface. > If the Video Widget is a top level widget (UseWidgetTop=1) this works > fine (only one subsurface deep ?). > > I have tried using both Gstreamer's waylandsink and glimagesink > elements, both show the same issue. > > This seems to suggest that the de-synced subsurface system is not > working properly with Weston, I miss-understand how this should work or > I have a program error. > This has been tested on Fedora37 running Weston 10.0.1 under KDE/Plasma/X11. > > 1. Should de-synced subsurfaces under other subsurfaces work under > Weston 10.0.1 ? > > 2. Do I miss-understand how this should work ? > > 3. Do I have some coding issue (sorry the code is a bit complex with > Wayland callbacks and C++ timers etc) ? > > pgp5dAHgSLs4H.pgp Description: OpenPGP digital signature
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
While I am trying to investigate my issue in the QtWayland arena via the Qt Jira Bug system, I thought I would try taking Qt out of the equation to simplify the application a bit more to try and gain some understanding of what is going on and how this should all work. So I have created a pure GStreamer/Wayland/Weston application to test out how this should work. This is at: https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz This tries to implement a C++ Widget style application using native Wayland. It is rough and could easily be doing things wrong wrt Wayland. However it does work to a reasonable degree. However, I appear to see the same sort of issue I see with my Qt based system in that when a subsurface of a subsurface is used, the Gstreamer video is not seen. This example normally (UseWidgetTop=0) has a top level xdg_toplevel desktop surface (Gui), a subsurface to that (Video) and then waylandsink creates a subsurface to that which it sets to de-sync mode. When this example is run with UseWidgetTop=0 the video frames from gstreamer are only shown shown when the top subsurface is manually committed with gvideo->update() every second, otherwise the video pipeline is stalled. Waylandsink is stuck in a loop awaiting a Wayland callback after committing its subsurface. If the Video Widget is a top level widget (UseWidgetTop=1) this works fine (only one subsurface deep ?). I have tried using both Gstreamer's waylandsink and glimagesink elements, both show the same issue. This seems to suggest that the de-synced subsurface system is not working properly with Weston, I miss-understand how this should work or I have a program error. This has been tested on Fedora37 running Weston 10.0.1 under KDE/Plasma/X11. 1. Should de-synced subsurfaces under other subsurfaces work under Weston 10.0.1 ? 2. Do I miss-understand how this should work ? 3. Do I have some coding issue (sorry the code is a bit complex with Wayland callbacks and C++ timers etc) ?
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi Pekka, Did you try making the "middle" QWidget *not* have a wl_surface of its own? Hack on Qt, then? Sorry, but I don't understand this insistence that what sounds like a Qt bug must be workaround-able via Wayland. Hmm, that does not sound right to me, but then again, I don't know Qt. Wayland certainly does not impose such demand. Well the way this is supposed to work, I believe, is: 1. There are two separate systems in operation here: Qt doing the general GUI and GStreamer waylandsink displaying the video. These systems know nothing of one another. 2. The link between these two systems is a Wayland surface in the Wayland server. QWidget will manage this surface (raise, lower, position etc.) and can draw into it if it wants. 3. Waylandsink creates a subsurface of that QWidget Wayland surface, sets it to be de-synced and and then proceeds to draw into this at the video frame rate. 4. There's quite a lot of hardware engine working going on in the background. For example video buffers may be in special memory like in a video or 2D hardware engine pipeline etc. Qt may be using separate 3D engine hardware etc. I am not experienced with Wayland, but I think a "middle" surface is needed so this can be moved, raised,/lowered etc. relative to the applications main QWidgets and the waylandsink does not need to know about this (apart from resizes). Another option would be to modify waylandsink to do the necessary things with its subsurface. But having a separate shared surface from the Qt applications main drawing surface seems safer and I am trying to keep with what I think is the accepted method with minimal changes to upstream code. This Gstreamer video display method came from the older X11 way of doing this with XWindows. As stated the reason this is not working with Qt6/Wayland/Weston is probably a Qt6 bug/issue/feature. However a way to understand what is happening is to look at the shared Wayland level and maybe there is a way with Wayland protocol commands of overcoming the issue so I can work around the problem I am having in a short time (timescales!) before a more proper fix is worked out. For example in X11 an XMapWindow() or XRaiseWindow() request or positioning/size requests may have worked and I wondered if I could do the same sort of thing in Wayland. Even if the QtWayland issue is fixed, I may have to do something at the Wayland level as I'm not sure if subsurfaces are effectively moved, raised/lowered etc. when their parent surface is changed Wayland. Anyway as David has suggested, I have raised an issue on the Qt Jira bugs list at: https://bugreports.qt.io/browse/QTBUG-122941. Terry On 29/02/2024 13:39, Pekka Paalanen wrote: On Wed, 28 Feb 2024 18:04:28 + Terry Barnaby wrote: Hi Pekka, Some questions below: Thanks Terry On 26/02/2024 15:56, Pekka Paalanen wrote: Ok. What Wayland API requests cause a surface to actually be mapped (Sorry don't really know Wayland protocol) ? Hi Terry, the basic protocol object is wl_surface. The wl_surface needs to be given a "role". This is a specific protocol term. xdg_surface and xdg_toplevel can give a wl_surface the role of a top-level window, which means it can get mapped when you play by the rules set in the xdg_toplevel specification. Sub-surface is another role. So the rules are always role specific, but at some point they all require content on the wl_surface, which is given with the attach request followed by a commit request. Role rules specify when and how that can be done. Yes, I have heard that. But what I don't knoe is from the client: 1. How do I find out the surfaces role ? It is what you (or Qt, or Gst) set it to. There is no way to query it (or any other thing) back by Wayland. If you look at a protocol dump (e.g. WAYLAND_DEBUG=client in environment), you can could follow the protocol messages and trace back what the role was set to. 2. How would I set the surface to have a role such that it would be mapped and thus visible ? Just wondering if I can work around what I think is a QtWayland bug/issue/feature to make sure by second Widgets surface is mapped/visible so that the waylandsink subsurface can work. With X11 there were API calls to change the Windows state and I was looking for something similar with Wayland. There is no simple answer to this. You pick a role you need, and then play by the protocol spec. You do not have any surfaces without roles, though, so this would not help you anyway. Roles cannot be changed, only set once per wl_surface life time. Sub-surface is a role. I need to find some way to actually display video, simply and efficiently on an embedded platform, in a Qt application in the year 2024 :) I have tried lots of work arounds but none have worked due to either Qt issues, Wayland restrictions, Gstreamer restrictions, Weston issues/restrictions, NXP hardware engin
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Wed, 28 Feb 2024 18:04:28 + Terry Barnaby wrote: > Hi Pekka, > > Some questions below: > > Thanks > > Terry > On 26/02/2024 15:56, Pekka Paalanen wrote: > > Ok. What Wayland API requests cause a surface to actually be mapped > >> (Sorry don't really know Wayland protocol) ? > > Hi Terry, > > > > the basic protocol object is wl_surface. The wl_surface needs to be > > given a "role". This is a specific protocol term. xdg_surface and > > xdg_toplevel can give a wl_surface the role of a top-level window, > > which means it can get mapped when you play by the rules set in the > > xdg_toplevel specification. > > > > Sub-surface is another role. > > > > So the rules are always role specific, but at some point they all > > require content on the wl_surface, which is given with the attach > > request followed by a commit request. Role rules specify when and how > > that can be done. > > Yes, I have heard that. But what I don't knoe is from the client: > > 1. How do I find out the surfaces role ? It is what you (or Qt, or Gst) set it to. There is no way to query it (or any other thing) back by Wayland. If you look at a protocol dump (e.g. WAYLAND_DEBUG=client in environment), you can could follow the protocol messages and trace back what the role was set to. > 2. How would I set the surface to have a role such that it would be > mapped and thus visible ? Just wondering if I can work around what I > think is a QtWayland bug/issue/feature to make sure by second > Widgets surface is mapped/visible so that the waylandsink subsurface > can work. With X11 there were API calls to change the Windows state > and I was looking for something similar with Wayland. There is no simple answer to this. You pick a role you need, and then play by the protocol spec. You do not have any surfaces without roles, though, so this would not help you anyway. Roles cannot be changed, only set once per wl_surface life time. Sub-surface is a role. > > I need to find some way to actually display video, simply and > efficiently on an embedded platform, in a Qt application in the year 2024 :) > > I have tried lots of work arounds but none have worked due to either Qt > issues, Wayland restrictions, Gstreamer restrictions, Weston > issues/restrictions, NXP hardware engine issues/restrictions etc. Any > ideas gratefully received! > Did you try making the "middle" QWidget *not* have a wl_surface of its own? > > > >> The higher level surfaces are created/managed by QtWayland, but maybe I > >> can override somehow. > >> > > That does not feel like a good idea to me. But I also cannot really > > help you, because this all seems to be pointing at Qt which I know > > nothing about. > > Yes, thats probably true. But I need to get this to work somehow, even > if a kludge for now. Hack on Qt, then? Sorry, but I don't understand this insistence that what sounds like a Qt bug must be workaround-able via Wayland. > > > >>> > >>>> As mentioned before, If I use QPainter to draw into the video QWidget it > >>>> actually draws into the top QWidgets 16 surface using Wayland protocol. > >>>> I would have thought it would draw into its own QWidget surface 18 as it > >>>> has Qt::WA_NativeWindow set ? > > This question seems to be the essence. If Qt worked like you expected, > > then I think the whole program would work. > > > > However, there is no need (from Wayland perspective) to have a > > wl_surface as "surface 18" in the middle. What would be best is if you > > could somehow have that "middle" QWidget but without it's own > > wl_surface. Have the QWidget control the GStreamer wl_surface position > > through wl_subsurface interface, while GStreamer plays the video > > through wl_surface interface. > > > > Wayland does not relay sub-surface resizing or positioning between two > > client-side components at all. There is not even a way query a > > sub-surface position. So the positioning and sizing is all done in > > Qt<->GStreamer somehow without Wayland in between. Only the end result > > gets sent over Wayland to display: Qt sets up the position and > > GStreamer sets up the size and content. > > I think this middle surface is needed so that Qt can manage the > "Windows" at this level, like raise, lower, resize et. and Wayland Hmm, that does not sound right to me, but then again, I don't know Qt. Wayland certainly does not impose such demand. > sink's subsurface that is below this is separate and can be
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi Pekka, Some questions below: Thanks Terry On 26/02/2024 15:56, Pekka Paalanen wrote: Ok. What Wayland API requests cause a surface to actually be mapped (Sorry don't really know Wayland protocol) ? Hi Terry, the basic protocol object is wl_surface. The wl_surface needs to be given a "role". This is a specific protocol term. xdg_surface and xdg_toplevel can give a wl_surface the role of a top-level window, which means it can get mapped when you play by the rules set in the xdg_toplevel specification. Sub-surface is another role. So the rules are always role specific, but at some point they all require content on the wl_surface, which is given with the attach request followed by a commit request. Role rules specify when and how that can be done. Yes, I have heard that. But what I don't knoe is from the client: 1. How do I find out the surfaces role ? 2. How would I set the surface to have a role such that it would be mapped and thus visible ? Just wondering if I can work around what I think is a QtWayland bug/issue/feature to make sure by second Widgets surface is mapped/visible so that the waylandsink subsurface can work. With X11 there were API calls to change the Windows state and I was looking for something similar with Wayland. I need to find some way to actually display video, simply and efficiently on an embedded platform, in a Qt application in the year 2024 :) I have tried lots of work arounds but none have worked due to either Qt issues, Wayland restrictions, Gstreamer restrictions, Weston issues/restrictions, NXP hardware engine issues/restrictions etc. Any ideas gratefully received! The higher level surfaces are created/managed by QtWayland, but maybe I can override somehow. That does not feel like a good idea to me. But I also cannot really help you, because this all seems to be pointing at Qt which I know nothing about. Yes, thats probably true. But I need to get this to work somehow, even if a kludge for now. As mentioned before, If I use QPainter to draw into the video QWidget it actually draws into the top QWidgets 16 surface using Wayland protocol. I would have thought it would draw into its own QWidget surface 18 as it has Qt::WA_NativeWindow set ? This question seems to be the essence. If Qt worked like you expected, then I think the whole program would work. However, there is no need (from Wayland perspective) to have a wl_surface as "surface 18" in the middle. What would be best is if you could somehow have that "middle" QWidget but without it's own wl_surface. Have the QWidget control the GStreamer wl_surface position through wl_subsurface interface, while GStreamer plays the video through wl_surface interface. Wayland does not relay sub-surface resizing or positioning between two client-side components at all. There is not even a way query a sub-surface position. So the positioning and sizing is all done in Qt<->GStreamer somehow without Wayland in between. Only the end result gets sent over Wayland to display: Qt sets up the position and GStreamer sets up the size and content. I think this middle surface is needed so that Qt can manage the "Windows" at this level, like raise, lower, resize et. and Wayland sink's subsurface that is below this is separate and can be de-synced for the video display etc. I normally (on X11 and with Qt5/Wayland), respond to QWidget resizes and use the Gstreamer API calls to position/resize the waylandsink's sub-surface. This all works quite nicely under X11 and worked (although not nicely) under Qt5/Wayland. I assume that Qtwayland is not "activating" the video QWidget's surface or using it for some reason (send subsurface expose events ?) ? If that's true, then it is very relevant. A sub-surface becomes mapped and visible when: - its parent surface is mapped and visible, and - the parent surface is committed after the sub-surface has been created and associated, and - if the sub-surface is in synchronized mode, there also needs to be a parent surface commit after every sub-surface commit you want to become visible. So if you do the first sub-surface sync-mode commit with a buffer after the parent has already committed the sub-surface's creation, the parent surface needs too commit again. This applies recursively, too, and you have a sub-sub-surface there. Do you actually need to sub-surface in the middle? Have you tried without it? I am not doing anything with Wayland directly. Qt is managing the higher level surfaces/subsurfaces and then GStreamers waylandsink is passed one of these Qt managed surfaces and it creates the subsurface 44. Looking at waylandsink it should set this subsurface to be desynced so it can draw into this surface without synchronising to the parents surface managed by Qt. Right, and desync is not enough if its parent is not mapped. All I am trying to do is use t
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Mon, 26 Feb 2024 15:18:27 + Terry Barnaby wrote: > Hi Pekka, > > Thanks for the response. Notes below: > > Terry > > On 26/02/2024 13:28, Pekka Paalanen wrote: > > On Sun, 25 Feb 2024 08:04:30 + > > Terry Barnaby wrote: > > > >> Hi, > >> > >> I have investigated a bit further. I have built my own Weston server to > >> run under X11 on Fedora37 so I can add printf's and debug more easily > >> than using a cross compiled iMX8mp target system etc. I added a new > >> dsmc-shell to Weston which is identical to kiosk-shell (apart from > >> names) so I could play with that. > >> > >> When It run my simple QWidget test program (test016-qt6-video-example) > >> which creates one top level QWidget with a child QWidget to display the > >> Gstreamer video in it, I see the following surfaces/subsurfaces when > >> desktop_surface_committed() is called in the dsmc-shell. > >> > >> Surface: 16 1044,620 mapped: 1 opaque: 0 > >> View: 0x29182b0 > >> Surface: 18 0,0 mapped: 0 opaque: 0 > >> Surface: 44 640,480 mapped: 1 opaque: 0 > >> Surface: 18 0,0 mapped: 0 opaque: 0 > >> Surface: 17 0,0 mapped: 0 opaque: 0 > >> Surface: 16 1044,620 mapped: 1 opaque: 0 > > Btw. the sub-surface list also contains the parent weston_surface in > > it, that's why surface 18 and 16 show up twice, I guess. It's used for > > z-ordering. > > Yes, that was my view. > > > > > >> Surface 16 is used by the top level QWidget, surface 18 is used by the > >> Video QWidget and surface 44 is the GStreamer video display surface (I > >> think!). This list is generated traversing the weston_surface's views > >> and subsurface_list lists. The mapped is the "is_mapped" field of the > >> surface. > >> Only the top level weston_surface has a weston_view in the views list it > >> that is any relevance. "weston-debug scene-graph" only shows the tope > >> most surface, no subsurfaces. > > Right. > > > > A sub-surface requires its parent surface to be mapped in order to show > > up on screen. This applies recursively, so surface 18 not being mapped > > prevents surface 44 from showing up. > > > > IIRC, more or less only "fully mapped" weston_surfaces (as in, if it's > > a sub-surface, the whole sub-surface ancestry path up to a top-level is > > mapped) have a weston_view. weston_view defines where on screen a > > weston_surface will be presented, so without a view it cannot show up. > > Ok. What Wayland API requests cause a surface to actually be mapped > (Sorry don't really know Wayland protocol) ? Hi Terry, the basic protocol object is wl_surface. The wl_surface needs to be given a "role". This is a specific protocol term. xdg_surface and xdg_toplevel can give a wl_surface the role of a top-level window, which means it can get mapped when you play by the rules set in the xdg_toplevel specification. Sub-surface is another role. So the rules are always role specific, but at some point they all require content on the wl_surface, which is given with the attach request followed by a commit request. Role rules specify when and how that can be done. > The higher level surfaces are created/managed by QtWayland, but maybe I > can override somehow. > That does not feel like a good idea to me. But I also cannot really help you, because this all seems to be pointing at Qt which I know nothing about. > > > >> As mentioned before, If I use QPainter to draw into the video QWidget it > >> actually draws into the top QWidgets 16 surface using Wayland protocol. > >> I would have thought it would draw into its own QWidget surface 18 as it > >> has Qt::WA_NativeWindow set ? This question seems to be the essence. If Qt worked like you expected, then I think the whole program would work. However, there is no need (from Wayland perspective) to have a wl_surface as "surface 18" in the middle. What would be best is if you could somehow have that "middle" QWidget but without it's own wl_surface. Have the QWidget control the GStreamer wl_surface position through wl_subsurface interface, while GStreamer plays the video through wl_surface interface. Wayland does not relay sub-surface resizing or positioning between two client-side components at all. There is not even a way query a sub-surface position. So the positioning and sizing is all done in Qt<->GStreamer somehow without Wayland in between. Only the end result gets sent over Wayland to display: Qt sets up the position and GStreamer sets up the size and content.
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi Pekka, Thanks for the response. Notes below: Terry On 26/02/2024 13:28, Pekka Paalanen wrote: On Sun, 25 Feb 2024 08:04:30 + Terry Barnaby wrote: Hi, I have investigated a bit further. I have built my own Weston server to run under X11 on Fedora37 so I can add printf's and debug more easily than using a cross compiled iMX8mp target system etc. I added a new dsmc-shell to Weston which is identical to kiosk-shell (apart from names) so I could play with that. When It run my simple QWidget test program (test016-qt6-video-example) which creates one top level QWidget with a child QWidget to display the Gstreamer video in it, I see the following surfaces/subsurfaces when desktop_surface_committed() is called in the dsmc-shell. Surface: 16 1044,620 mapped: 1 opaque: 0 View: 0x29182b0 Surface: 18 0,0 mapped: 0 opaque: 0 Surface: 44 640,480 mapped: 1 opaque: 0 Surface: 18 0,0 mapped: 0 opaque: 0 Surface: 17 0,0 mapped: 0 opaque: 0 Surface: 16 1044,620 mapped: 1 opaque: 0 Btw. the sub-surface list also contains the parent weston_surface in it, that's why surface 18 and 16 show up twice, I guess. It's used for z-ordering. Yes, that was my view. Surface 16 is used by the top level QWidget, surface 18 is used by the Video QWidget and surface 44 is the GStreamer video display surface (I think!). This list is generated traversing the weston_surface's views and subsurface_list lists. The mapped is the "is_mapped" field of the surface. Only the top level weston_surface has a weston_view in the views list it that is any relevance. "weston-debug scene-graph" only shows the tope most surface, no subsurfaces. Right. A sub-surface requires its parent surface to be mapped in order to show up on screen. This applies recursively, so surface 18 not being mapped prevents surface 44 from showing up. IIRC, more or less only "fully mapped" weston_surfaces (as in, if it's a sub-surface, the whole sub-surface ancestry path up to a top-level is mapped) have a weston_view. weston_view defines where on screen a weston_surface will be presented, so without a view it cannot show up. Ok. What Wayland API requests cause a surface to actually be mapped (Sorry don't really know Wayland protocol) ? The higher level surfaces are created/managed by QtWayland, but maybe I can override somehow. As mentioned before, If I use QPainter to draw into the video QWidget it actually draws into the top QWidgets 16 surface using Wayland protocol. I would have thought it would draw into its own QWidget surface 18 as it has Qt::WA_NativeWindow set ? I assume that Qtwayland is not "activating" the video QWidget's surface or using it for some reason (send subsurface expose events ?) ? If that's true, then it is very relevant. A sub-surface becomes mapped and visible when: - its parent surface is mapped and visible, and - the parent surface is committed after the sub-surface has been created and associated, and - if the sub-surface is in synchronized mode, there also needs to be a parent surface commit after every sub-surface commit you want to become visible. So if you do the first sub-surface sync-mode commit with a buffer after the parent has already committed the sub-surface's creation, the parent surface needs too commit again. This applies recursively, too, and you have a sub-sub-surface there. Do you actually need to sub-surface in the middle? Have you tried without it? I am not doing anything with Wayland directly. Qt is managing the higher level surfaces/subsurfaces and then GStreamers waylandsink is passed one of these Qt managed surfaces and it creates the subsurface 44. Looking at waylandsink it should set this subsurface to be desynced so it can draw into this surface without synchronising to the parents surface managed by Qt. All I am trying to do is use the technique as mentioned in various forums/lists to get GStreamer to display a video such that it "appears" where a QWidget is on the screen. Mind you all of this info is very rough and ready. For X11 it appears stable, but for Qt/Wayland the info, and it appears functionality, is not quite all there. When you say a sub-surface in the middle I presume you mean the surface 18 of the lower QWidget ? Well I have tried using the top most QWidget's surface 16 and the video is displayed, although all over the application. I really need to manage this surface so it can be raised, lowered and resizes amongst the other QWidgets somehow. I have tried using direct Wayland API calls to create a subsurface manually from the top surface but so far I have just got protocol errors while trying this. It may be my bad Wayland client code or how it is interfering with Qt's Wayland interface. I have even tried using a separate top level surface. Unfortunately as the standard Wayland protocols do not allow an application to move or manage top level Windows th
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Sun, 25 Feb 2024 08:04:30 + Terry Barnaby wrote: > Hi, > > I have investigated a bit further. I have built my own Weston server to > run under X11 on Fedora37 so I can add printf's and debug more easily > than using a cross compiled iMX8mp target system etc. I added a new > dsmc-shell to Weston which is identical to kiosk-shell (apart from > names) so I could play with that. > > When It run my simple QWidget test program (test016-qt6-video-example) > which creates one top level QWidget with a child QWidget to display the > Gstreamer video in it, I see the following surfaces/subsurfaces when > desktop_surface_committed() is called in the dsmc-shell. > > Surface: 16 1044,620 mapped: 1 opaque: 0 > View: 0x29182b0 > Surface: 18 0,0 mapped: 0 opaque: 0 > Surface: 44 640,480 mapped: 1 opaque: 0 > Surface: 18 0,0 mapped: 0 opaque: 0 > Surface: 17 0,0 mapped: 0 opaque: 0 > Surface: 16 1044,620 mapped: 1 opaque: 0 Btw. the sub-surface list also contains the parent weston_surface in it, that's why surface 18 and 16 show up twice, I guess. It's used for z-ordering. > > Surface 16 is used by the top level QWidget, surface 18 is used by the > Video QWidget and surface 44 is the GStreamer video display surface (I > think!). This list is generated traversing the weston_surface's views > and subsurface_list lists. The mapped is the "is_mapped" field of the > surface. > Only the top level weston_surface has a weston_view in the views list it > that is any relevance. "weston-debug scene-graph" only shows the tope > most surface, no subsurfaces. Right. A sub-surface requires its parent surface to be mapped in order to show up on screen. This applies recursively, so surface 18 not being mapped prevents surface 44 from showing up. IIRC, more or less only "fully mapped" weston_surfaces (as in, if it's a sub-surface, the whole sub-surface ancestry path up to a top-level is mapped) have a weston_view. weston_view defines where on screen a weston_surface will be presented, so without a view it cannot show up. > > As mentioned before, If I use QPainter to draw into the video QWidget it > actually draws into the top QWidgets 16 surface using Wayland protocol. > I would have thought it would draw into its own QWidget surface 18 as it > has Qt::WA_NativeWindow set ? > > I assume that Qtwayland is not "activating" the video QWidget's surface > or using it for some reason (send subsurface expose events ?) ? > If that's true, then it is very relevant. A sub-surface becomes mapped and visible when: - its parent surface is mapped and visible, and - the parent surface is committed after the sub-surface has been created and associated, and - if the sub-surface is in synchronized mode, there also needs to be a parent surface commit after every sub-surface commit you want to become visible. So if you do the first sub-surface sync-mode commit with a buffer after the parent has already committed the sub-surface's creation, the parent surface needs too commit again. This applies recursively, too, and you have a sub-sub-surface there. Do you actually need to sub-surface in the middle? Have you tried without it? Thanks, pq > > I note in the qtwayland change logs, for the earlier QT5 for subsurface > changes: > dist/changes-5.6.3: - [QTBUG-52118] Fixed subsurface positions sometimes > not being committed. > dist/changes-5.11.2: - [QTBUG-69643] Fixed a bug where subsurfaces would > not be rendered if clients added them before a WaylandQuickItem was > created for the parent surface > dist/changes-5.12.0: - [QTBUG-49809] Added support for > wl_subsurface.place_above and place_below in WaylandQuickItem. > dist/changes-5.15.2: - [QTBUG-86176] We now send subsurface expose > events when a different toplevel (such as a dialog) is configured. > > Could any of these be related ? > > Terry pgpJnC5Zfi2QJ.pgp Description: OpenPGP digital signature
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi,
I have investigated a bit further. I have built my own Weston server to
run under X11 on Fedora37 so I can add printf's and debug more easily
than using a cross compiled iMX8mp target system etc. I added a new
dsmc-shell to Weston which is identical to kiosk-shell (apart from
names) so I could play with that.
When It run my simple QWidget test program (test016-qt6-video-example)
which creates one top level QWidget with a child QWidget to display the
Gstreamer video in it, I see the following surfaces/subsurfaces when
desktop_surface_committed() is called in the dsmc-shell.
Surface: 16 1044,620 mapped: 1 opaque: 0
View: 0x29182b0
Surface: 18 0,0 mapped: 0 opaque: 0
Surface: 44 640,480 mapped: 1 opaque: 0
Surface: 18 0,0 mapped: 0 opaque: 0
Surface: 17 0,0 mapped: 0 opaque: 0
Surface: 16 1044,620 mapped: 1 opaque: 0
Surface 16 is used by the top level QWidget, surface 18 is used by the
Video QWidget and surface 44 is the GStreamer video display surface (I
think!). This list is generated traversing the weston_surface's views
and subsurface_list lists. The mapped is the "is_mapped" field of the
surface.
Only the top level weston_surface has a weston_view in the views list it
that is any relevance. "weston-debug scene-graph" only shows the tope
most surface, no subsurfaces.
As mentioned before, If I use QPainter to draw into the video QWidget it
actually draws into the top QWidgets 16 surface using Wayland protocol.
I would have thought it would draw into its own QWidget surface 18 as it
has Qt::WA_NativeWindow set ?
I assume that Qtwayland is not "activating" the video QWidget's surface
or using it for some reason (send subsurface expose events ?) ?
I note in the qtwayland change logs, for the earlier QT5 for subsurface
changes:
dist/changes-5.6.3: - [QTBUG-52118] Fixed subsurface positions sometimes
not being committed.
dist/changes-5.11.2: - [QTBUG-69643] Fixed a bug where subsurfaces would
not be rendered if clients added them before a WaylandQuickItem was
created for the parent surface
dist/changes-5.12.0: - [QTBUG-49809] Added support for
wl_subsurface.place_above and place_below in WaylandQuickItem.
dist/changes-5.15.2: - [QTBUG-86176] We now send subsurface expose
events when a different toplevel (such as a dialog) is configured.
Could any of these be related ?
Terry
On 23/02/2024 09:29, Terry Barnaby wrote:
Hi David,
Many thanks for the reply and the info on how to get the ID.
I have added a basic example with some debug output at:
https://portal.beam.ltd.uk/public//test016-qt6-video-example.tar.gz
If there are any ideas of things I could look at/investigate I am all
ears!
In a previous email I stated:
I have tried using "weston-debug scene-graph" and I am coming to the
conclusion that qtwayland 6.5.0 is not really using native Wayland
surfaces when Qt::WA_NativeWindow is used. From what I can see (and I
could easily be wrong) the Wayland protocol shows wl_surfaces being
created and two QWidget's QPlatformNativeInterface
nativeResourceForWindow("surface", windowHandle()) function does
return different wl_surface pointers but even at the QWidget level
(ignoring gstreamer), a QPainter paint into each of these QWidgets
actually uses Wayland to draw into just the one top level surface and
"weston-debug scene-graph" shows only one application xdg_toplevel
surface and no subsurfaces. I don't know how to determine the Wayland
surface ID from a wl_surface pointer unfortunately to really check this.
If my Video QWidget(0) is a top level QWidget, then video is shown
and "weston-debug scene-graph" shows the application xdg_toplevel and
two wl_subsurfaces as children.
Unfortunately I think "weston-debug scene-graph" only shows surfaces
that are actually "active" so I can't see all of the surfaces that
Weston actually knows about (is there a method of doing this ?).
My feeling is that although Qtwayland is creating native surfaces, it
actually only uses the one top level one and presumably doesn't
"activate" (set a role, do something ?) with the other surfaces.
Does anyone know a good list/place where I can ask such detailed
qtwayland questions ?
I guess I can work around this by manually creating a Wayland
subsurface from the Qt top level surface and handing that to
waylandsink and then manage this subsurface, like hiding, showing and
resizing, when the QWidget is hidden/shown/resized.
Or could there be a way of "activating" the child QWidget's Wayland
surface ?
Terry
On 23/02/2024 08:35, David Edmundson wrote:
On Fri, Feb 23, 2024 at 6:15 AM Terry Barnaby
wrote:
I don't know how to determine the Wayland surface ID from a
wl_surface pointer unfortunately to really check this.
wl_proxy_get_id(static_cast(myWlSurface));
Possibly when QWidget is below in hierarcy to be a child of of a
parent,
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi David,
Many thanks for the reply and the info on how to get the ID.
I have added a basic example with some debug output at:
https://portal.beam.ltd.uk/public//test016-qt6-video-example.tar.gz
If there are any ideas of things I could look at/investigate I am all ears!
In a previous email I stated:
I have tried using "weston-debug scene-graph" and I am coming to the
conclusion that qtwayland 6.5.0 is not really using native Wayland
surfaces when Qt::WA_NativeWindow is used. From what I can see (and I
could easily be wrong) the Wayland protocol shows wl_surfaces being
created and two QWidget's QPlatformNativeInterface
nativeResourceForWindow("surface", windowHandle()) function does
return different wl_surface pointers but even at the QWidget level
(ignoring gstreamer), a QPainter paint into each of these QWidgets
actually uses Wayland to draw into just the one top level surface and
"weston-debug scene-graph" shows only one application xdg_toplevel
surface and no subsurfaces. I don't know how to determine the Wayland
surface ID from a wl_surface pointer unfortunately to really check this.
If my Video QWidget(0) is a top level QWidget, then video is shown and
"weston-debug scene-graph" shows the application xdg_toplevel and two
wl_subsurfaces as children.
Unfortunately I think "weston-debug scene-graph" only shows surfaces
that are actually "active" so I can't see all of the surfaces that
Weston actually knows about (is there a method of doing this ?).
My feeling is that although Qtwayland is creating native surfaces, it
actually only uses the one top level one and presumably doesn't
"activate" (set a role, do something ?) with the other surfaces.
Does anyone know a good list/place where I can ask such detailed
qtwayland questions ?
I guess I can work around this by manually creating a Wayland
subsurface from the Qt top level surface and handing that to
waylandsink and then manage this subsurface, like hiding, showing and
resizing, when the QWidget is hidden/shown/resized.
Or could there be a way of "activating" the child QWidget's Wayland
surface ?
Terry
On 23/02/2024 08:35, David Edmundson wrote:
On Fri, Feb 23, 2024 at 6:15 AM Terry Barnaby wrote:
I don't know how to determine the Wayland surface ID from a
wl_surface pointer unfortunately to really check this.
wl_proxy_get_id(static_cast(myWlSurface));
Possibly when QWidget is below in hierarcy to be a child of of a parent,
as described in
That's fine.
A QWidget with WA_NativeWindow will create a QWindow with a parent. A
QWindow with a parent will create a subsurface in wayland terms.
But it is a subsurface where Qt is managing it and you're also
committing on it, which can be a bit confusing and going through
widgets to create a subsurface isn't really needed.
There's a bunch of other options there.
---
Can you link your test app. You can send me a private email and I'll
take a look. It doesn't seem like a core wayland problem more a
Qt/application setup issue so far. Then we can follow it up on Qt's
Jira if there is a Qt issue.
David Edmundson - QtWayland Maintainer
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi,
On Fri, Feb 23, 2024 at 06:14:11AM +, Terry Barnaby wrote:
> I have tried using "weston-debug scene-graph" and I am coming to the
> conclusion that qtwayland 6.5.0 is not really using native Wayland surfaces
> when Qt::WA_NativeWindow is used. From what I can see (and I could easily be
> wrong) the Wayland protocol shows wl_surfaces being created and two
> QWidget's QPlatformNativeInterface nativeResourceForWindow("surface",
> windowHandle()) function does return different wl_surface pointers but even
> at the QWidget level (ignoring gstreamer), a QPainter paint into each of
> these QWidgets actually uses Wayland to draw into just the one top level
> surface and "weston-debug scene-graph" shows only one application
> xdg_toplevel surface and no subsurfaces. I don't know how to determine the
> Wayland surface ID from a wl_surface pointer unfortunately to really check
> this.
I suppose this is to expected given that you don't actually see the video.
>
> If my Video QWidget(0) is a top level QWidget, then video is shown and
> "weston-debug scene-graph" shows the application xdg_toplevel and two
> wl_subsurfaces as children.
>
> Unfortunately I think "weston-debug scene-graph" only shows surfaces that
> are actually "active" so I can't see all of the surfaces that Weston
> actually knows about (is there a method of doing this ?).
Mapped or not, Weston will print out views associated with a surface, if
those views are part of a layer. I don't know what active means in this
case, but you won't be activating wl_surfaces but rather the top-level
xdg-shell window. Depending on the Weston version it would explicit say
that or not (surface/view being not mapped).
>
> My feeling is that although Qtwayland is creating native surfaces, it
> actually only uses the one top level one and presumably doesn't "activate"
> (set a role, do something ?) with the other surfaces.
WAYLAND_DEBUG=1 could tell if it creates or not subsurfaces underneath.
>
> Does anyone know a good list/place where I can ask such detailed qtwayland
> questions ?
https://bugreports.qt.io/projects/QTBUG/issues/QTBUG-122683?filter=allopenissues
>
> I guess I can work around this by manually creating a Wayland subsurface
> from the Qt top level surface and handing that to waylandsink and then
> manage this subsurface, like hiding, showing and resizing, when the QWidget
> is hidden/shown/resized.
>
> Or could there be a way of "activating" the child QWidget's Wayland surface
> ?
>
>
>
> On 22/02/2024 18:44, Terry Barnaby wrote:
> > Hi Marius,
> >
> > Many thanks for the info.
> >
> > Some notes/questions below:
> >
> > Terry
> > On 22/02/2024 17:49, Marius Vlad wrote:
> > > Hi,
> > > On Thu, Feb 22, 2024 at 03:21:01PM +, Terry Barnaby wrote:
> > > > Hi,
> > > >
> > > > We are developing a video processing system that runs on an NXP imx8
> > > > processor using a Yocto embedded Linux system that has Qt6, GStreamer,
> > > > Wayland and Weston.
> > > >
> > > > We are having a problem displaying the video stream from GStreamer on a
> > > > QWidget. In the past we had this working with Qt5 and older GStreamer,
> > > > Wayland and Weston.
> > > >
> > > > A simple test program also shows the issue on Fedora37 with QT6 and
> > > > KDE/Plasma/Wayland.
> > > I'm tempted to say if this happens on a desktop with the same Qt
> > > version and
> > > other compositors to be an issue with Qt rather than waylandsink or
> > > the compositor. Note that on NXP they have their own modified Weston
> > > version.
> >
> > That is my current feeling and is one reason why I tried it on Fedora
> > with whatever Wayland compositor KDE/Plasma is using.
> >
> >
> > > > The technique we are using is to get the Wayland surface from
> > > > the QWidget is
> > > > using (It has been configured to use a Qt::WA_NativeWindow) and
> > > > pass this to
> > > > the GStreamer's waylandsink which should then update this
> > > > surface with video
> > > > frames (via hardware). This works when the QWidget is a top
> > > > level Window
> > > > widget (QWidget(0)), but if this QWidget is below others in the
> > > > hierarchy no
> > > > video is seen and the gstreamer pipeline line is stalled.
> > > So the assumption is that aren't there other widgets which obscures this
> > > one, when you move it below others?
> >
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Fri, Feb 23, 2024 at 6:15 AM Terry Barnaby wrote: >I don't know how to determine the Wayland surface ID from a > wl_surface pointer unfortunately to really check this. wl_proxy_get_id(static_cast(myWlSurface)); > >> Possibly when QWidget is below in hierarcy to be a child of of a parent, > >> as described in That's fine. A QWidget with WA_NativeWindow will create a QWindow with a parent. A QWindow with a parent will create a subsurface in wayland terms. But it is a subsurface where Qt is managing it and you're also committing on it, which can be a bit confusing and going through widgets to create a subsurface isn't really needed. There's a bunch of other options there. --- Can you link your test app. You can send me a private email and I'll take a look. It doesn't seem like a core wayland problem more a Qt/application setup issue so far. Then we can follow it up on Qt's Jira if there is a Qt issue. David Edmundson - QtWayland Maintainer
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
I have tried using "weston-debug scene-graph" and I am coming to the
conclusion that qtwayland 6.5.0 is not really using native Wayland
surfaces when Qt::WA_NativeWindow is used. From what I can see (and I
could easily be wrong) the Wayland protocol shows wl_surfaces being
created and two QWidget's QPlatformNativeInterface
nativeResourceForWindow("surface", windowHandle()) function does return
different wl_surface pointers but even at the QWidget level (ignoring
gstreamer), a QPainter paint into each of these QWidgets actually uses
Wayland to draw into just the one top level surface and "weston-debug
scene-graph" shows only one application xdg_toplevel surface and no
subsurfaces. I don't know how to determine the Wayland surface ID from a
wl_surface pointer unfortunately to really check this.
If my Video QWidget(0) is a top level QWidget, then video is shown and
"weston-debug scene-graph" shows the application xdg_toplevel and two
wl_subsurfaces as children.
Unfortunately I think "weston-debug scene-graph" only shows surfaces
that are actually "active" so I can't see all of the surfaces that
Weston actually knows about (is there a method of doing this ?).
My feeling is that although Qtwayland is creating native surfaces, it
actually only uses the one top level one and presumably doesn't
"activate" (set a role, do something ?) with the other surfaces.
Does anyone know a good list/place where I can ask such detailed
qtwayland questions ?
I guess I can work around this by manually creating a Wayland subsurface
from the Qt top level surface and handing that to waylandsink and then
manage this subsurface, like hiding, showing and resizing, when the
QWidget is hidden/shown/resized.
Or could there be a way of "activating" the child QWidget's Wayland
surface ?
On 22/02/2024 18:44, Terry Barnaby wrote:
Hi Marius,
Many thanks for the info.
Some notes/questions below:
Terry
On 22/02/2024 17:49, Marius Vlad wrote:
Hi,
On Thu, Feb 22, 2024 at 03:21:01PM +, Terry Barnaby wrote:
Hi,
We are developing a video processing system that runs on an NXP imx8
processor using a Yocto embedded Linux system that has Qt6, GStreamer,
Wayland and Weston.
We are having a problem displaying the video stream from GStreamer on a
QWidget. In the past we had this working with Qt5 and older GStreamer,
Wayland and Weston.
A simple test program also shows the issue on Fedora37 with QT6 and
KDE/Plasma/Wayland.
I'm tempted to say if this happens on a desktop with the same Qt
version and
other compositors to be an issue with Qt rather than waylandsink or
the compositor. Note that on NXP they have their own modified Weston
version.
That is my current feeling and is one reason why I tried it on Fedora
with whatever Wayland compositor KDE/Plasma is using.
The technique we are using is to get the Wayland surface from the
QWidget is
using (It has been configured to use a Qt::WA_NativeWindow) and pass
this to
the GStreamer's waylandsink which should then update this surface
with video
frames (via hardware). This works when the QWidget is a top level
Window
widget (QWidget(0)), but if this QWidget is below others in the
hierarchy no
video is seen and the gstreamer pipeline line is stalled.
So the assumption is that aren't there other widgets which obscures this
one, when you move it below others?
My simple test example has two QWidgets with the one for video being
created as a child of the first so it should be above all others. I
have even tried drawing in it to make sure and it displays its Qt
drawn contents fine, just not the video stream.
It appears that waylandsink does:
Creates a surface callback:
callback = wl_surface_frame (surface);
wl_callback_add_listener (callback, _callback_listener, self);
Then adds a buffer to a surface:
gst_wl_buffer_attach (buffer, priv->video_surface_wrapper);
wl_surface_set_buffer_scale (priv->video_surface_wrapper,
priv->scale);
wl_surface_damage_buffer (priv->video_surface_wrapper, 0, 0,
G_MAXINT32,
G_MAXINT32);
wl_surface_commit (priv->video_surface_wrapper);
But never gets a callback and just sits in a loop awaiting that
callback.
I assume that the surface waylandsink is using, which is created
using the
original QWidget surface (sub-surface ? with window ?) is not
"active" for
some reason.
Possibly when QWidget is below in hierarcy to be a child of of a parent,
as described in
https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_parent,
so I assume to have a different surface than the parent one. This would
be easy to determine with WAYLAND_DEBUG. Seems unlikely to a itself a
sub-surface of a surface.
I haven't really got the gist of whats going on, but waylandsink
certainly creates a subsurface from the QWidget surface, in fact it
seems to create a few things.
I assume a s
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi Marius, Many thanks for the info. Some notes/questions below: Terry On 22/02/2024 17:49, Marius Vlad wrote: Hi, On Thu, Feb 22, 2024 at 03:21:01PM +, Terry Barnaby wrote: Hi, We are developing a video processing system that runs on an NXP imx8 processor using a Yocto embedded Linux system that has Qt6, GStreamer, Wayland and Weston. We are having a problem displaying the video stream from GStreamer on a QWidget. In the past we had this working with Qt5 and older GStreamer, Wayland and Weston. A simple test program also shows the issue on Fedora37 with QT6 and KDE/Plasma/Wayland. I'm tempted to say if this happens on a desktop with the same Qt version and other compositors to be an issue with Qt rather than waylandsink or the compositor. Note that on NXP they have their own modified Weston version. That is my current feeling and is one reason why I tried it on Fedora with whatever Wayland compositor KDE/Plasma is using. The technique we are using is to get the Wayland surface from the QWidget is using (It has been configured to use a Qt::WA_NativeWindow) and pass this to the GStreamer's waylandsink which should then update this surface with video frames (via hardware). This works when the QWidget is a top level Window widget (QWidget(0)), but if this QWidget is below others in the hierarchy no video is seen and the gstreamer pipeline line is stalled. So the assumption is that aren't there other widgets which obscures this one, when you move it below others? My simple test example has two QWidgets with the one for video being created as a child of the first so it should be above all others. I have even tried drawing in it to make sure and it displays its Qt drawn contents fine, just not the video stream. It appears that waylandsink does: Creates a surface callback: callback = wl_surface_frame (surface); wl_callback_add_listener (callback, _callback_listener, self); Then adds a buffer to a surface: gst_wl_buffer_attach (buffer, priv->video_surface_wrapper); wl_surface_set_buffer_scale (priv->video_surface_wrapper, priv->scale); wl_surface_damage_buffer (priv->video_surface_wrapper, 0, 0, G_MAXINT32, G_MAXINT32); wl_surface_commit (priv->video_surface_wrapper); But never gets a callback and just sits in a loop awaiting that callback. I assume that the surface waylandsink is using, which is created using the original QWidget surface (sub-surface ? with window ?) is not "active" for some reason. Possibly when QWidget is below in hierarcy to be a child of of a parent, as described in https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_parent, so I assume to have a different surface than the parent one. This would be easy to determine with WAYLAND_DEBUG. Seems unlikely to a itself a sub-surface of a surface. I haven't really got the gist of whats going on, but waylandsink certainly creates a subsurface from the QWidget surface, in fact it seems to create a few things. I assume a subsurface is used so the video can be displayed in that subsurface separately from the parent (de synced from it). I am trying to debug this, but this graphics stack is quite complicated with waylandsink, qtwayland, wayland-lib and Weston not to mention the NXP hardware levels. My thoughts are that it is something qtwayland is doing with the surface stack or thread locking issues (gstreamer uses separate threads). I also don't understand Wayland or Weston in detail. So some questions: 1. Anyone seen something like this ? Someone else reported something similar but that by causing damage, or moving pointer to make the video sub-surface to show up: https://gitlab.freedesktop.org/wayland/weston/-/issues/843. Thanks, I will have a look. Moving the mouse cursor in my case (at least with Weston) does not affect things. 2. Anyone any idea one where to look ? 3. Given the wl_surface in the Qt app or in waylandsink is there a way I can print out its state and the surface hierarchy easily ? In Weston there's something called scene-graph. You can grab it by starting Weston with with the --debug argument, then you can print with `weston-debug scene-graph` command. A more recent Weston version would indent sub-surfaces by their (main) surface parent. Thanks, that could be useful. 4. Any idea on any debug methods to use ? WAYLAND_DEBUG=1 as env variable. Any idea on how to get a surfaces ID from a C pointer so I can match up the QtWidget/waylandsink surface with the Wayland debug output ? Cheers Terry
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi, On Thu, Feb 22, 2024 at 03:21:01PM +, Terry Barnaby wrote: > Hi, > > We are developing a video processing system that runs on an NXP imx8 > processor using a Yocto embedded Linux system that has Qt6, GStreamer, > Wayland and Weston. > > We are having a problem displaying the video stream from GStreamer on a > QWidget. In the past we had this working with Qt5 and older GStreamer, > Wayland and Weston. > > A simple test program also shows the issue on Fedora37 with QT6 and > KDE/Plasma/Wayland. I'm tempted to say if this happens on a desktop with the same Qt version and other compositors to be an issue with Qt rather than waylandsink or the compositor. Note that on NXP they have their own modified Weston version. > > The technique we are using is to get the Wayland surface from the QWidget is > using (It has been configured to use a Qt::WA_NativeWindow) and pass this to > the GStreamer's waylandsink which should then update this surface with video > frames (via hardware). This works when the QWidget is a top level Window > widget (QWidget(0)), but if this QWidget is below others in the hierarchy no > video is seen and the gstreamer pipeline line is stalled. So the assumption is that aren't there other widgets which obscures this one, when you move it below others? > > It appears that waylandsink does: > > Creates a surface callback: > > callback = wl_surface_frame (surface); > > wl_callback_add_listener (callback, _callback_listener, self); > > Then adds a buffer to a surface: > > gst_wl_buffer_attach (buffer, priv->video_surface_wrapper); > wl_surface_set_buffer_scale (priv->video_surface_wrapper, priv->scale); > wl_surface_damage_buffer (priv->video_surface_wrapper, 0, 0, G_MAXINT32, > G_MAXINT32); > wl_surface_commit (priv->video_surface_wrapper); > > But never gets a callback and just sits in a loop awaiting that callback. > > I assume that the surface waylandsink is using, which is created using the > original QWidget surface (sub-surface ? with window ?) is not "active" for > some reason. Possibly when QWidget is below in hierarcy to be a child of of a parent, as described in https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_parent, so I assume to have a different surface than the parent one. This would be easy to determine with WAYLAND_DEBUG. Seems unlikely to a itself a sub-surface of a surface. > > > I am trying to debug this, but this graphics stack is quite complicated with > waylandsink, qtwayland, wayland-lib and Weston not to mention the NXP > hardware levels. My thoughts are that it is something qtwayland is doing > with the surface stack or thread locking issues (gstreamer uses separate > threads). I also don't understand Wayland or Weston in detail. So some > questions: > > 1. Anyone seen something like this ? Someone else reported something similar but that by causing damage, or moving pointer to make the video sub-surface to show up: https://gitlab.freedesktop.org/wayland/weston/-/issues/843. > > 2. Anyone any idea one where to look ? > > 3. Given the wl_surface in the Qt app or in waylandsink is there a way I can > print out its state and the surface hierarchy easily ? In Weston there's something called scene-graph. You can grab it by starting Weston with with the --debug argument, then you can print with `weston-debug scene-graph` command. A more recent Weston version would indent sub-surfaces by their (main) surface parent. > > 4. Any idea on any debug methods to use ? WAYLAND_DEBUG=1 as env variable. > > Cheers > > Terry > > signature.asc Description: PGP signature
Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Hi, We are developing a video processing system that runs on an NXP imx8 processor using a Yocto embedded Linux system that has Qt6, GStreamer, Wayland and Weston. We are having a problem displaying the video stream from GStreamer on a QWidget. In the past we had this working with Qt5 and older GStreamer, Wayland and Weston. A simple test program also shows the issue on Fedora37 with QT6 and KDE/Plasma/Wayland. The technique we are using is to get the Wayland surface from the QWidget is using (It has been configured to use a Qt::WA_NativeWindow) and pass this to the GStreamer's waylandsink which should then update this surface with video frames (via hardware). This works when the QWidget is a top level Window widget (QWidget(0)), but if this QWidget is below others in the hierarchy no video is seen and the gstreamer pipeline line is stalled. It appears that waylandsink does: Creates a surface callback: callback = wl_surface_frame (surface); wl_callback_add_listener (callback, _callback_listener, self); Then adds a buffer to a surface: gst_wl_buffer_attach (buffer, priv->video_surface_wrapper); wl_surface_set_buffer_scale (priv->video_surface_wrapper, priv->scale); wl_surface_damage_buffer (priv->video_surface_wrapper, 0, 0, G_MAXINT32, G_MAXINT32); wl_surface_commit (priv->video_surface_wrapper); But never gets a callback and just sits in a loop awaiting that callback. I assume that the surface waylandsink is using, which is created using the original QWidget surface (sub-surface ? with window ?) is not "active" for some reason. I am trying to debug this, but this graphics stack is quite complicated with waylandsink, qtwayland, wayland-lib and Weston not to mention the NXP hardware levels. My thoughts are that it is something qtwayland is doing with the surface stack or thread locking issues (gstreamer uses separate threads). I also don't understand Wayland or Weston in detail. So some questions: 1. Anyone seen something like this ? 2. Anyone any idea one where to look ? 3. Given the wl_surface in the Qt app or in waylandsink is there a way I can print out its state and the surface hierarchy easily ? 4. Any idea on any debug methods to use ? Cheers Terry
Re: Punch hole logic in gl-renderer in weston
Hi, Work towards adding this functionality is discussed at https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258 On Tue, Jan 23, 2024 at 01:13:20PM +, Namit Solanki (QUIC) wrote: > Hi Weston team, > > For the use cases where the GPU composed output (output of > gl-renderer) is on top (higher z order) of a layer > (layer has lower z order and layer is composed by Display Processing > unit), do we have a punch hole logic implemented in > gl-renderer or Weston so that layer is visible through the punch hole? > > Or Weston always expects that the GPU composed buffer is always at the lowest > z order among all layers? > > Example : Suppose, there are four layers on the display. Layer1 and > Layer2 are composed by GPU and layer3 and layer4 are composed by > Display processing unit. The composed output of layer1 and layer2 can > have higher z order than layer3 and layer4? if yes, how the layer3 and > layer4 will be visible on screen? > > Please help me in understanding this. > > Thanks > Namit signature.asc Description: PGP signature
Punch hole logic in gl-renderer in weston
Hi Weston team, For the use cases where the GPU composed output (output of gl-renderer) is on top (higher z order) of a layer (layer has lower z order and layer is composed by Display Processing unit), do we have a punch hole logic implemented in gl-renderer or Weston so that layer is visible through the punch hole? Or Weston always expects that the GPU composed buffer is always at the lowest z order among all layers? Example : Suppose, there are four layers on the display. Layer1 and Layer2 are composed by GPU and layer3 and layer4 are composed by Display processing unit. The composed output of layer1 and layer2 can have higher z order than layer3 and layer4? if yes, how the layer3 and layer4 will be visible on screen? Please help me in understanding this. Thanks Namit
Re: [ANNOUNCE] weston 12.0.3
[ANNOUNCE] weston 12.0.3
Hi all, This is a point/bugfix release for Weston 12. Full commit history bellow. Aske Bækdal Møller (1): clients: keyboard: fix delete before cursor Derek Foreman (2): toy-toolkit: Fix rotations xwm: Fix accidental resizing of windows Marius Vlad (1): build: bump to version 12.0.3 for the point release git tag: 12.0.3 https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.3/downloads/weston-12.0.3.tar.xz SHA256: 0fa88359e691ce6de47ee92d7bd0c10ec8c54b064d07b204715fc479eef0db6d weston-12.0.3.tar.xz SHA512: 689f0c945c5dde212e024e046046eb1dea3f3c40f36f1750901b13854b53f3ae8dd0a355319b12e74822ef96a2dc907d60b2d992e5541ab900f7d74f5f097fa5 weston-12.0.3.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.3/downloads/weston-12.0.3.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] weston 13.0.0
Hi all, This is the official release for weston 13.0.0. Highlights for this release: - multiple backend support allowing loading multiple backends, vnc, rdp, pipewire are secondary backends - backend-vnc, backend-pipewire and backend-rdp: GL renderer support - improved fullscreen handling in kiosk-shell which allows xwayland type of surfaces be fullscreen - support for overlapping outputs, which allows placing views on planes when they're displayed on multiple outputs Internal changes: - desktop-shell now makes use of pointer confinement for fullscreen surfaces - new test for pointer constrains - new test for paint-node - many view/surfaces cleanups, including subsurface view construction, weston_view_geometry_dirty_internal() addition - drop libgbm 21.1.1 from various clients requiring it and from drm-backend; libgbm 21.1.1 was already required from Weston 10, but it wasn't explicitly requested API changes: - weston_view_move_to_layer() wraps movement of a view into a specific layer. If the target layer is NULL it would effectively remove the view from the scene graph. This new helper triggers a view list rebuild, and it performs all the necessary steps required to make it so the view is added to the layer, respectively removed from the current layer if the target layer is NULL. It deals with damaging the old regions of the view and removal from the layer, as well as damaging the new region when adding it to a new layer. Both desktop-shell and kiosk-shell have been refactored to use this new helper. - weston_coord struct in now use for weston_view_set_position, weston_output weston_touch as well as the shells - added iterator for logging scopes - weston_log_scopes_iterate() Breaking changes for users: - launcher: Remove launcher-logind has been removed entirely. This was already deprecated previously. Users are encourated to use libseat which has systemd-logind support with its backends. Marius Vlad (2): build: bump to version 13.0.0 for the official release git tag: 13.0.0 https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.0/downloads/weston-13.0.0.tar.xz SHA256: 52ff1d4aa2394a2e416c85a338b627ce97fa71d43eb762fd4aaf145d36fc795a weston-13.0.0.tar.xz SHA512: 8c656cdf24ec9429c76c64ebd2d58351991f5990a6d4b5900ac913243ad8e2c9c0fb1a748f018d177fbfd7e0a8836d0434d97acec287a8f977d47335ae30eacc weston-13.0.0.tar.xz signature.asc Description: PGP signature
[ANNOUNCE] weston 12.0.95
Hi all, This is the RC3 release for Weston 13.0.0. Full commit history below: Daniel Stone (2): desktop-shell: Map input panel exactly once weston-keyboard: Create input_panel_surface earlier Marius Vlad (2): backend-x11: Fix error shutdown path for x11 build: bump to version 12.0.95 for the RC3 release git tag: 12.0.95 https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.95/downloads/weston-12.0.95.tar.xz SHA256: 7c5e761837aed8304ab5c334b8ba6a9e8a27a8ab530126ca98188d7c741657ce weston-12.0.95.tar.xz SHA512: cd9dc97348c2f381bc687bbee84fa6b42563abb9d34cdb2c23befde460c25e9c9fe617ca47981f5bb0498d6de073232b5dccb8c18e6047598f4f67b9a8e18b51 weston-12.0.95.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.95/downloads/weston-12.0.95.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] weston 12.0.94
Hi all, This is the RC2 release for Weston 13.0.0. Full commit history below: Aske Bækdal Møller (1): clients: keyboard: fix delete before cursor Derek Foreman (5): vnc: Remove scanout plane optimization libweston: Don't clip damage to paint node visible region libweston: Don't set VISIBILITY_DIRTY on non-primary planes vnc: Fix cursor updates drm-backend: Fix cursor updates with overlapping heads Marius Vlad (1): build: bump to version 12.0.94 for the RC2 release git tag: 12.0.94 https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.94/downloads/weston-12.0.94.tar.xz SHA256: 7c463d7630af5d49bcf92e09e42725eaf22a9a0851e8c90d4d830e9a7c95575b weston-12.0.94.tar.xz SHA512: 7e5fd718cbee30a466e14be7e35fd9cc1a7eb42c147a77271692fd04af62b6eda7c9c6ac4acfb787e184b0cf34563bad8b98c4159b03b9ccf43ef9958b7d916a weston-12.0.94.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.94/downloads/weston-12.0.94.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] weston 12.0.93
Hi all, This is the RC1 release for Weston 13.0.0. Full commit history below. Marius Vlad (1): build: bump to version 12.0.93 for the RC1 release git tag: 12.0.93 https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.93/downloads/weston-12.0.93.tar.xz SHA256: 7a873b477dc4c6a6f46ee1e0b594f8132af530f7ec9b1d02614c5337e8d773c3 weston-12.0.93.tar.xz SHA512: 0fb5f447270605974a1de09ff8014e8647c6f54a7403f2c62644dd93bcc1c593892d0c2cc495a03b5e43dda472c463e141ff8f9535e1d1a92c3285cdd2cbfb93 weston-12.0.93.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.93/downloads/weston-12.0.93.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] weston 12.0.92
Hi all, This is the beta release for Weston 13.0.0. The following changes have been added since the alpha release: Derek Foreman (1): xwm: Fix accidental resizing of windows Leandro Ribeiro (7): color-lcms: unref stock sRGB cprof instead of directly destroying it color-noop: make use of xalloc helpers color-noop: add stock color profile color: add get_stock_sRGB_color_profile() to color manager color-lcms: extract color characteristics even when output cprof != NULL tests/color-metadata-errors: add mock stock sRGB color profile color: do not use NULL as stock sRGB color profile Marius Vlad (3): backend-x11: Move back-end removal to the destroy function libweston: Ignore subsurface offsets build: bump to version 12.0.92 for the beta release git tag: 12.0.92 https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.92/downloads/weston-12.0.92.tar.xz SHA256: ecd0d6bf5a596f1f930eea615aeac9a3ec1c904cf8ac6fb1815bada0ca3cd07a weston-12.0.92.tar.xz SHA512: 91c8613e980605fadcb7d44a8eca88daa50a8d0bf9421804cab297cc7b2a4a7e76edc844153384f1e5683f5193095892e9e107ed1636391688471ebf7293e7d3 weston-12.0.92.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.92/downloads/weston-12.0.92.tar.xz.sig signature.asc Description: PGP signature
Re: Weston 13 and Weston 12.0.3 release schedule
Hi all, Just a heads-up, we're going to postpone our Beta release for the next week (it should've been today), as to able to fix some issues we've discovered recently, and also give fdo.org time to "recover". Note that all the other dates are also shifted with one week. Thanks! On Mon, Oct 09, 2023 at 07:36:06PM +0300, Marius Vlad wrote: > Hi all, > > Here is the release schedule for Weston 13.0, the next major version: > > - Alpha: October 16, in one week > - Beta: October 23 > - RC1: October 30 > - First possible release: November, 6 > > Package maintainers are encouraged to pick up the pre-releases to make > sure packaging can be tested (and fixed) before the stable release. > > Additionally I'd like to do a Weston 12 bug-fix/point release at the > same time matching our first possible release date. As usual, we have a > dedicated label, 'Backport to Weston 12' if there's something you'd like > to get in for Weston 12, or you can reach out directly. > > Thanks! signature.asc Description: PGP signature
[ANNOUNCE] weston 12.0.91
Hi all, This is the alpha release for Weston 13.0.0. Notes for packagers: - backend-vnc requires Neat VNC 0.7.0 - launcher-logind has been removed Thanks to all contributors! Full history commit below: Alexandros Frantzis (3): xwayland: Allow shells to make xwayland surfaces fullscreen xwayland: Notify the shell when a window drops the fullscreen state desktop-shell: Don't process surfaces under destruction during output resize Brendan King (1): xwayland: fix segfault when running x11perf Christopher Obbard (2): libweston: Decouple dbus helper to public namespace libweston: Split dbus support into seperate build option Daniel Stone (153): CI: Upgrade ci-templates version CI: Parameterise LLVM version CI: Rename debian jobs to debian-lts CI: Force pip to install packages CI: Bump virtme snapshot version CI: Upgrade Mesa and kernel CI: Add Debian bookworm jobs CI: Require wayland 1.22 for wl_client_add_destroy_late_listener frontend: Move path into weston_process frontend: Remove process_info frontend: Rename weston_process to wet_process frontend: Inline wet_watch_process frontend: Rename weston_client_start to wet_client_start frontend: Add data argument to wet_process cleanup frontend: Allow NULL wet_process cleanup handler frontend: Allocate new wet_process for Xwayland frontend: Make wet_client_launch allocate new wet_process frontend: Inline process_handle_sigchld frontend: Factor out wet_process_destroy xwayland: Only pass Xwayland wl_client to libweston tests/xwayland: Ensure $DISPLAY is correctly set xwayland: Remove process exit status from libweston API xwayland: Rename destroy_listener to be more explicit xwayland: Add client destroy listener frontend: Return user-data pointer from Xwayland init frontend: Explicitly destroy Xwayland from frontend code frontend: Clean up wet_processes on exit libweston: Add weston_compositor.shutting_down backend-drm: Use weston_compositor.shutting_down desktop-shell: Don't restart client on exit text-backend: Don't restart client on exit backend-drm: Don't leak writeback-format property blob tests/drm: Fix leaks in drm-writeback-screenshot-test CI: Enable ASan memory-leak checking surface: Convert a couple of ints to bools surface: Move presentation-feedback discard to commit surface: Start tracking weston_surface_status surface: Only rebuild paint node regions when necessary surface: Convert a couple of bools to dirty flags surface: Inline buffer-size calculation to attach surface: Pass weston_surface_state into attach build: Switch join_paths(foo, bar) to foo / bar build: Run tests with leak-sanitizer suppressions CI: Remove per-test-asan wrapper weston_surface: Add map and unmap signals desktop-shell: shell_surfaces always have a layer desktop-shell: Actually dirty surface regions when moving desktop-shell: Don't damage unmapped views desktop-shell: Make view mapping more consistent desktop-shell: Centralise view mapping for shell_surfaces weston-desktop: Match desktop-shell view mapping semantics libweston: Add weston_view::map_signal desktop-shell: Use weston_view_move_to_layer() for fullscreen switching desktop-shell: Use weston_view_move_to_layer() for fullscreen fades desktop-shell: Use weston_view_move_to_layer() for per-view unfade desktop-shell: Create fade-out views at destroy time desktop-shell: Use weston_view_move_to_layer() for fullscreen background desktop-shell: Use weston_view_move_to_layer() for static views desktop-shell: Use weston_view_to_layer() for lock surface desktop-shell: Be more precise with rotation damage kiosk-shell: Use weston_view_move_to_layer() for activation kiosk-shell: Use weston_view_move_to_layer() for background kiosk-shell: Use weston_view_move_to_layer() for view activation fullscreen-shell: Use weston_view_move_to_layer() weston-test-desktop-shell: Use weston_view_move_to_layer() build: Avoid Meson warning for run_command() without check tests: Remove single case for device destroy test tests: Pass wet_testsuite_data to test runs tests: Track weston_outputs in weston-test plugin tests: Add client<->compositor breakpoint support tests: Add paint-node test tests: Initialise breakpoint list for all test types desktop-shell: Remove unused fullscreen transform surface: Only rebuild surface size where necessary surface: Replace newly_attached with weston_surface_status surface: Replace viewport.changed with weston_surface_status surface: Add comments to weston_surface_status member surface: Add position dirty
