Let pointer events pass through
Hello, I am writing a Wayland client that acts as an OSD "overlay" on top of another application. This OSD overlay should not handle any pointer events -- these should "pass through" and be handled by the application below. From the docs, wwl_surface::set_input_region looked promising: > Input events happening outside of this region will try the next surface in > the server surface stack. The compositor ignores the parts of the input > region that fall outside of the surface. [...] The initial value for an input > region is infinite. That means the whole surface will accept input. Setting > the pending input region has copy semantics, and the wl_region object can be > destroyed immediately. A NULL wl_region causes the input region to be set to > infinite. I am trying this: struct wl_region* region = wl_compositor_create_region(_glfw.wl.compositor); wl_surface_set_input_region(window->wl.surface, region); wl_region_destroy(region); However it doesn't seem to work -- pointer events do not seem to "pass through". Same problem is also reported here: https://github.com/glfw/glfw/pull/1568 Is this approach correct? Any hints on how to debug this? Best regards, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Let pointer events pass through
El lun., 18 nov. 2019 a las 13:49, Simon Ser () escribió: > > On Monday, November 18, 2019 1:37 PM, Guillermo Rodriguez > wrote: > > > Hello, > > > > I am writing a Wayland client that acts as an OSD "overlay" on top of > > another application. This OSD overlay should not handle any pointer > > events -- these should "pass through" and be handled by the > > application below. > > > > From the docs, wwl_surface::set_input_region looked promising: > > > > > Input events happening outside of this region will try the next surface > > > in the server surface stack. The compositor ignores the parts of the > > > input region that fall outside of the surface. [...] The initial value > > > for an input region is infinite. That means the whole surface will accept > > > input. Setting the pending input region has copy semantics, and the > > > wl_region object can be destroyed immediately. A NULL wl_region causes > > > the input region to be set to infinite. > > > > I am trying this: > > > > struct wl_region* region = > > wl_compositor_create_region(_glfw.wl.compositor); > > wl_surface_set_input_region(window->wl.surface, region); > > > > wl_region_destroy(region); > > > > > > However it doesn't seem to work -- pointer events do not seem to "pass > > through". > > > > Same problem is also reported here: https://github.com/glfw/glfw/pull/1568 > > > > Is this approach correct? Any hints on how to debug this? > > This should work. Other clients do this, for instance swaybg [1]. > > This is probably a GNOME bug. I'd suggest trying on other compositors > (KDE, Weston, Sway, …) and report a GNOME bug if it only happens on > GNOME. Just tested on Weston, and indeed this *almost* works. I say "almost" because pointer events do in fact pass through. But then when the application below receives the event, it is brought to top by Weston, thus obscuring the OSD "overlay". I searched for a way to indicate that a surface should always stay on top and it looks like this is not supported (by design apparently). Is there any way to achieve this? Thank, Guillermo Rodriguez ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
How to implement OSD overlay in Wayland/Weston
Hi all, This is a follow up to my earlier email "Let pointer events pass through". I have an use case where there is one full screen application (I'll call this the "main" application) and I need to show a OSD overlay on top of it. The OSD overlay is actually based on GStreamer (think PiP) and is managed by a different process. The OSD overlay should not handle pointer events; these should pass through to the main application, which knows how to handle them. I am not sure how to approach this in Wayland/Weston. I have considered the following: 1. Use wl_surface::set_input_region so that pointer events are not delivered to the OSD overlay, but instead pass through and are handled by the main application. This "almost" works, however when the main application receives the event, Weston brings it on top, thus hiding the OSD overlay. I searched for a way to specify that a given surface should always stay "on top". This does not seem to be supported in Wayland. 2. Setup things so that the OSD overlay is not an additional top level surface, but a child surface owned by the main application. This would mean having the main application create a child surface for the OSD, and pass this surface to the OSD process. In X this could be achieved by passing a Windows ID. In Wayland apparently it is not possible to share surfaces between processes. 3. Let the OSD overlay actually handle pointer events, but "send" them to the main application. In X this could be achieved with XSendEvent. In Wayland apparently it is not possible to have one process send events to another process. Not sure what else to try. Any ideas? Either ways to make one of the above work, or new approaches... TIA, Guillermo Rodriguez ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to implement OSD overlay in Wayland/Weston
Hello, Indeed I looked into xdg-foreign but it does not seem to be supported in Weston. Other ideas? Guillermo El mar., 19 nov. 2019 a las 10:21, Ilia Bozhinov () escribió: > > Hi, > > I am not entirely familiar with your setup, but you can try to use a > combination of: > > 1. Setting your on-top window's input region to empty as you already have > tried. > 2. Use xdg-foreign protocol to set the main window as parent of your on-top > window. >> > This will work on all compositors that support xdg-foreign, however I am not > sure whether weston supports it. > > Regards, > Ilia Bozhinov > > On Tue, 19 Nov 2019, 09:53 Guillermo Rodriguez, > wrote: >> >> Hi all, >> >> This is a follow up to my earlier email "Let pointer events pass through". >> >> I have an use case where there is one full screen application (I'll >> call this the "main" application) and I need to show a OSD overlay on >> top of it. The OSD overlay is actually based on GStreamer (think PiP) >> and is managed by a different process. >> The OSD overlay should not handle pointer events; these should pass >> through to the main application, which knows how to handle them. >> >> I am not sure how to approach this in Wayland/Weston. I have >> considered the following: >> >> 1. >> Use wl_surface::set_input_region so that pointer events are not >> delivered to the OSD overlay, but instead pass through and are handled >> by the main application. >> This "almost" works, however when the main application receives the >> event, Weston brings it on top, thus hiding the OSD overlay. >> I searched for a way to specify that a given surface should always >> stay "on top". This does not seem to be supported in Wayland. >> >> 2. >> Setup things so that the OSD overlay is not an additional top level >> surface, but a child surface owned by the main application. >> This would mean having the main application create a child surface for >> the OSD, and pass this surface to the OSD process. >> In X this could be achieved by passing a Windows ID. In Wayland >> apparently it is not possible to share surfaces between processes. >> >> 3. >> Let the OSD overlay actually handle pointer events, but "send" them to >> the main application. >> In X this could be achieved with XSendEvent. In Wayland apparently it >> is not possible to have one process send events to another process. >> >> Not sure what else to try. >> >> Any ideas? Either ways to make one of the above work, or new approaches... >> >> TIA, >> >> Guillermo Rodriguez >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to implement OSD overlay in Wayland/Weston
El mar., 19 nov. 2019 a las 11:47, Pekka Paalanen () escribió: > > On Tue, 19 Nov 2019 09:53:39 +0100 > Guillermo Rodriguez wrote: > > > Hi all, > > > > This is a follow up to my earlier email "Let pointer events pass through". > > > > I have an use case where there is one full screen application (I'll > > call this the "main" application) and I need to show a OSD overlay on > > top of it. The OSD overlay is actually based on GStreamer (think PiP) > > and is managed by a different process. > > The OSD overlay should not handle pointer events; these should pass > > through to the main application, which knows how to handle them. > > > > I am not sure how to approach this in Wayland/Weston. I have > > considered the following: > > > > 1. > > Use wl_surface::set_input_region so that pointer events are not > > delivered to the OSD overlay, but instead pass through and are handled > > by the main application. > > This "almost" works, however when the main application receives the > > event, Weston brings it on top, thus hiding the OSD overlay. > > I searched for a way to specify that a given surface should always > > stay "on top". This does not seem to be supported in Wayland. > > Hi, > > yes. I'm not aware of any Wayland extension that would allow clients to > dictate always-on-top behaviour on the desktop. It has an obvious > attack vector (malicious or misbehaving app setting always-on-top > without user's consent) and a simple corner case (how do you stack > multiple always-on-top windows). > > OSD as a concept seems like a desktop component, not a normal app. > Hence I would expect such a client to use a domain-specific or custom > protocol extension to set always-on-top. If your use case is not a > generic desktop but some special environment, then a domain-specific It is actually a special environment; a single fullscreen app on an embedded system. > protocol extension would be a way to go. For generic desktop > environments you'd integrate with the particular DE specifically, e.g. > a gnome-shell plugin or something. > > That is, if the OSD really is an independent separate program and not a > part of some fullscreen application. > > If the OSD is just a piece of a bigger application and only needs to be > on top of that application's windows, you could probably use xdg > extensions or a sub-surface to realize it. This does mean that the OSD > component must be in-process with the main app and share the same > wl_display instance. The OSD is conceptually part of the fullscreen application but due to several reasons it is implemented as a separate process with a CLI that controls the OSD contents and PiP function; the main application communicates with the OSD process by writing commands to the OSD process' stdin, and reading responses from the OSD process' stdout. There are several reasons for this approach, but the main one is that if there are any issues in the GStreamer side this should not crash the whole application. With the current approach, the main application can just respawn the OSD process if it dies. > I think this should be possible also with GStreamer. Not in the current implementation of the waylandsink plugin -- it always creates its own top level window (https://gstreamer.freedesktop.org/documentation/waylandsink/index.html?gi-language=c), and does not support drawing to an existing surface. But this could be patched if needed. > > > 2. > > Setup things so that the OSD overlay is not an additional top level > > surface, but a child surface owned by the main application. > > This would mean having the main application create a child surface for > > the OSD, and pass this surface to the OSD process. > > In X this could be achieved by passing a Windows ID. In Wayland > > apparently it is not possible to share surfaces between processes. > > I'd avoid a design with two separate processes. As Ilia wrote, > xdg-foreign exists, but I'm not sure which compositors implement it. > > In Wayland, all protocol objects are private to the Wayland connection > (wl_display) where they were created. xdg-foreign is a way to work > around that, but I'd leave xdg-foreign only to cases that really need > to have separate processes for e.g. security reasons. > > > 3. > > Let the OSD overlay actually handle pointer events, but "send" them to > > the main application. > > In X this could be achieved with XSendEvent. In Wayland apparently it > > is not possible to have one process send events to another process. > > Once an input event has been delivered to a client, there
Re: How to implement OSD overlay in Wayland/Weston
Hi, El mar., 19 nov. 2019 a las 12:38, Sebastian Krzyszkowiak () escribió: > > On 11/19/19, Pekka Paalanen wrote: > > yes. I'm not aware of any Wayland extension that would allow clients to > > dictate always-on-top behaviour on the desktop. It has an obvious > > attack vector (malicious or misbehaving app setting always-on-top > > without user's consent) and a simple corner case (how do you stack > > multiple always-on-top windows). > > > > OSD as a concept seems like a desktop component, not a normal app. > > Hence I would expect such a client to use a domain-specific or custom > > protocol extension to set always-on-top. If your use case is not a > > generic desktop but some special environment, then a domain-specific > > protocol extension would be a way to go. For generic desktop > > environments you'd integrate with the particular DE specifically, e.g. > > a gnome-shell plugin or something. > > > > That is, if the OSD really is an independent separate program and not a > > part of some fullscreen application. > > Sounds like something layer-shell protocol solves portably already. That sounds interesting. Is that supported by Weston? Guillermo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to implement OSD overlay in Wayland/Weston
Hi Daniel, El mar., 19 nov. 2019 a las 13:44, Daniel Stone () escribió: > > Hi, > > On Tue, 19 Nov 2019 at 11:48, Guillermo Rodriguez > wrote: > > El mar., 19 nov. 2019 a las 11:47, Pekka Paalanen () > > escribió: > > > If the OSD is just a piece of a bigger application and only needs to be > > > on top of that application's windows, you could probably use xdg > > > extensions or a sub-surface to realize it. This does mean that the OSD > > > component must be in-process with the main app and share the same > > > wl_display instance. > > > > The OSD is conceptually part of the fullscreen application but due to > > several reasons it is implemented as a separate process with a CLI > > that controls the OSD contents and PiP function; the main application > > communicates with the OSD process by writing commands to the OSD > > process' stdin, and reading responses from the OSD process' stdout. > > > > There are several reasons for this approach, but the main one is that > > if there are any issues in the GStreamer side this should not crash > > the whole application. With the current approach, the main application > > can just respawn the OSD process if it dies. > > > > > I think this should be possible also with GStreamer. > > > > Not in the current implementation of the waylandsink plugin -- it > > always creates its own top level window > > (https://gstreamer.freedesktop.org/documentation/waylandsink/index.html?gi-language=c), > > and does not support drawing to an existing surface. But this could be > > patched if needed. > > It is completely possible, using the GstVideoOverlay API. See > gst-plugins-bad/tests/examples/waylandsink/main.c for an example of > providing your own wl_surface. Nice. I assumed this was not possible as the documentation I linked explicitly states that the waylandsink creates its own window. This will definitely make my life easier :-) Thanks for the pointer, Guillermo Rodriguez ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to implement OSD overlay in Wayland/Weston
Hello, El mar., 19 nov. 2019 a las 13:28, Pekka Paalanen () escribió: > > On Tue, 19 Nov 2019 12:48:10 +0100 > Guillermo Rodriguez wrote: > > > El mar., 19 nov. 2019 a las 11:47, Pekka Paalanen > > () escribió: > > > > > > On Tue, 19 Nov 2019 09:53:39 +0100 > > > Guillermo Rodriguez wrote: > > > > > > > Hi all, > > > > > > > > This is a follow up to my earlier email "Let pointer events pass > > > > through". > > > > > > > > I have an use case where there is one full screen application (I'll > > > > call this the "main" application) and I need to show a OSD overlay on > > > > top of it. The OSD overlay is actually based on GStreamer (think PiP) > > > > and is managed by a different process. > > > > The OSD overlay should not handle pointer events; these should pass > > > > through to the main application, which knows how to handle them. > > > > > > > > I am not sure how to approach this in Wayland/Weston. I have > > > > considered the following: > > > > > > > > 1. > > > > Use wl_surface::set_input_region so that pointer events are not > > > > delivered to the OSD overlay, but instead pass through and are handled > > > > by the main application. > > > > This "almost" works, however when the main application receives the > > > > event, Weston brings it on top, thus hiding the OSD overlay. > > > > I searched for a way to specify that a given surface should always > > > > stay "on top". This does not seem to be supported in Wayland. > > ... > > > The OSD is conceptually part of the fullscreen application but due to > > several reasons it is implemented as a separate process with a CLI > > that controls the OSD contents and PiP function; the main application > > communicates with the OSD process by writing commands to the OSD > > process' stdin, and reading responses from the OSD process' stdout. > > > > There are several reasons for this approach, but the main one is that > > if there are any issues in the GStreamer side this should not crash > > the whole application. With the current approach, the main application > > can just respawn the OSD process if it dies. > > I see. Then conceptually, you more or less need a custom window manager > that knows to handle your OSD specially. This is exactly the pluggable > (shell) modules that Weston supports. More on that below. > > > OK, so it seems that 2 and 3 are going to be difficult due to > > architectural reasons. Let's go back to 1. > > Mind that using separate independent processes makes it nearly > impossible to synchronize their content updates. This would be an issue > if you need to move or resize the OSD in sync with the main window > contents. Yes. But that's not a problem in my case since neither the OSD or the main application can be moved or resized. > > > I understand that my main problem is controlling the Z-order of > > top-level surfaces. If that is not possible at the application level, > > then I guess I need to mess around with Weston. > > > > From what I see > > (https://vignatti.com/2013/03/05/ui-customization-on-wayland/), Weston > > supports the concept of plugabble shells that are in charge of > > defining "how surfaces will be mapped on the screen". I guess then > > that I would need to write a custom shell controlling Z-order of the > > surfaces. Does this make sense? > > > > I have been looking for documentation on this (the API for custom > > Weston shells), but I cannot find anything. Can you point me in the > > right direction? > > Unfortunately it's not documented even still, yet. > > One approach is to fork Weston's desktop-shell/. But since your use > case is quite simple, instead of replacing the whole shell plugin, you > could write a new add-on plugin that implements only the new behaviour > you need. I see. So I can extend the capabilities of Weston's desktop-shell by adding plugins that implement protocol extensions. I wasn't aware of this possibility; this should be much easier than writing a custom shell (or forking an existing one). > > You need a little protocol extension that will allow a client to send a > request that "gives a wl_surface the role of an OSD" and any parameters > you want the client to be in control of. Alternatively the plugin might > implement wlroot's layer-shell interfaces. Since layer-shell seems to perfectly fit
XDG_RUNTIME_DIR on a system with no "logins"
Hi all, Weston requires XDG_RUNTIME_DIR to exist. The specification for this (https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html) says: === $XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700. The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed. If the user logs in more than once he should get pointed to the same directory, and it is mandatory that the directory continues to exist from his first login to his last logout on the system, and not removed in between. Files in the directory MUST not survive reboot or a full logout/login cycle. === But how is this done for a system where normally no users "log in", e.g. a fixed-function embedded system with a graphical user interface? Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDG_RUNTIME_DIR on a system with no "logins"
El mié., 18 dic. 2019 a las 10:56, Pekka Paalanen
() escribió:
>
> On Tue, 17 Dec 2019 19:18:15 +0100 (CET)
> Jan Engelhardt wrote:
>
> > On Tuesday 2019-12-17 18:55, Guillermo Rodriguez wrote:
> >
> > >Hi all,
> > >
> > >Weston requires XDG_RUNTIME_DIR to exist. The specification for this
> > >(https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html)
> > >says:
> > >
> > >===
> > >$XDG_RUNTIME_DIR defines the base directory relative to which
> > >user-specific non-essential runtime files and other file objects (such
> > >as sockets, named pipes, ...) should be stored. The directory MUST be
> > >owned by the user, and he MUST be the only one having read and write
> > >access to it. Its Unix access mode MUST be 0700.
> > >
> > >The lifetime of the directory MUST be bound to the user being logged
> > >in. It MUST be created when the user first logs in and if the user
> > >fully logs out the directory MUST be removed. If the user logs in more
> > >than once he should get pointed to the same directory, and it is
> > >mandatory that the directory continues to exist from his first login
> > >to his last logout on the system, and not removed in between. Files in
> > >the directory MUST not survive reboot or a full logout/login cycle.
> > >===
> > >
> > >But how is this done for a system where normally no users "log in",
> > >e.g. a fixed-function embedded system with a graphical user interface?
> >
> > Well you simply create the directory before running the program that desires
> > said directory. Does not matter if the user identity change is by way of
> > a system manager, runuser(8), or login(8)/PAM (as called by xdm/etc.).
> >
> >
> > kiosk.service
> > User=npc
> > ExecStart=/home/npc/startx.sh
> >
> > startx.sh:
> > export XDG_RUNTIME_DIR=/home/npc/xdg
> > rm -Rf "$XDG_RUNTIME_DIR"
> > mkdir "$XDG_RUNTIME_DIR"
> > weston # or whatever
OK so I can just "make up" a xdg dir which is not bound to any specific
user. Although this obviously wouldn't meet the specs quoted above
("The lifetime of the directory MUST be bound to the user being logged
in" ...)
In my application I need to run several clients, and each one is started
from a separate SysV init script. I guess that I will need to define the
XDG_RUNTIME_DIR env var to point to this "made up" location in each
script. A bit ugly...
>
> If you invent XDG_RUNTIME_DIR like this, please also make sure to
> adhere to the XDG specification requirements. Specifically, it is a
> good idea to use a tmpfs for this. If it is backed by an actual
> disk, it may incur unnecessary disk I/O, which in embedded systems
> might be really bad.
>
>
> Thanks,
> pq
Thanks,
Guillermo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDG_RUNTIME_DIR on a system with no "logins"
El jue., 19 dic. 2019 a las 9:15, Pekka Paalanen () escribió: > > On Wed, 18 Dec 2019 13:10:14 +0100 > Guillermo Rodriguez wrote: > > > In my application I need to run several clients, and each one is started > > from a separate SysV init script. I guess that I will need to define the > > XDG_RUNTIME_DIR env var to point to this "made up" location in each > > script. A bit ugly... > > Hi, > > yes I guess, and SysV init scripts have other downsides: if you > use them to launch both Weston and the clients, you may have hard > time making sure the clients are launched only after Weston is > ready to accept them. Unfortunately Weston's own auto-launch > feature has not materialized yet, although it has been discussed and > should likely use the XDG desktop files for it. Even then, it > would be a one-shot thing, not restarting the clients if they quit. > > If you used systemd, Weston has integration for that, both startup > notification to ensure dependent services are started only after > Weston is ready and socket activation should you choose to want > that. Uhm. I am not sure I can switch to systemd at this point. How does this (Weston being ready / not ready) look like from the client side? i.e. if I want to make sure the client is launched once Weston is ready, 1. Is there any way to manually check whether Weston is ready? (e.g. some sentinel file being created or similar) or failing that, 2. Is there any recognizable error code if the client tries to launch before Weston is ready (so that I can wait a bit and retry) Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Thread safety when rendering on a separate thread
Hi all,
I have a Wayland client where the main loop runs on a thread and
rendering is done in a separate thread. The main loop simply uses
wl_display_dispatch:
while (wl_display_dispatch(globals.display) != -1) {
[...process user input...]
}
This is the only place where events are processed.
Rendering however is done on a separate thread, which eventually ends
up calling:
wl_surface_attach(surface, buffer, 0, 0);
wl_surface_damage(surface, x, y, width, height);
wl_surface_commit(surface);
wl_display_flush(display);
Is this safe or do I need to do any additional locking / synchronization?
Thank you,
Guillermo Rodriguez Garcia
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Thread safety when rendering on a separate thread
Hi,
El lun., 27 ene. 2020 a las 12:07, Pekka Paalanen
() escribió:
>
> On Mon, 27 Jan 2020 11:43:50 +0100
> Guillermo Rodriguez wrote:
>
> > Hi all,
> >
> > I have a Wayland client where the main loop runs on a thread and
> > rendering is done in a separate thread. The main loop simply uses
> > wl_display_dispatch:
> >
> > while (wl_display_dispatch(globals.display) != -1) {
> > [...process user input...]
> > }
> >
> > This is the only place where events are processed.
> >
> > Rendering however is done on a separate thread, which eventually ends
> > up calling:
> >
> > wl_surface_attach(surface, buffer, 0, 0);
> > wl_surface_damage(surface, x, y, width, height);
> > wl_surface_commit(surface);
> > wl_display_flush(display);
> >
> > Is this safe or do I need to do any additional locking / synchronization?
>
> Hi,
>
> that depends.
>
> First thing is if you have event handlers, for example wl_callback.done
> for wl_surface.frame which you really should be using to throttle your
> rendering. Event callbacks get dispatched from where the dispatch
> function is called, so that could race with your rendering thread.
>
> Another thing is window management. If you handle xdg_toplevel events
> and set window state while your animation is already running, it
> depends on from which thread you send the window state requests. If you
> send those from the rendering thread, it's fine. If you send those from
> the main thread, then they will race against your rendering thread
> sending wl_surface.commit. In some cases that might even lead to fatal
> protocol errors as you cannot reliably operate the protocol correctly.
>
> Usually when threads are involved, you dispatch the wl_display itself
> in one thread, and for each other thread touching Wayland you create a
> new wl_event_queue and with the help of wl_proxy_create_wrapper() you
> assing new protocol objects to the appropriate queue. This ensures the
> dispatching will happen in the thread where you want it.
Thank you for your answer. This is an embedded fullscreen application, so no
window management.
I need to have a look at the frame callback thing, though. Thanks for
the pointer.
Best regards,
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Thread safety when rendering on a separate thread
El lun., 27 ene. 2020 a las 12:53, Pekka Paalanen
() escribió:
>
> On Mon, 27 Jan 2020 12:36:27 +0100
> Guillermo Rodriguez wrote:
>
> > Hi,
> >
> > El lun., 27 ene. 2020 a las 12:07, Pekka Paalanen
> > () escribió:
> > >
> > > On Mon, 27 Jan 2020 11:43:50 +0100
> > > Guillermo Rodriguez wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have a Wayland client where the main loop runs on a thread and
> > > > rendering is done in a separate thread. The main loop simply uses
> > > > wl_display_dispatch:
> > > >
> > > > while (wl_display_dispatch(globals.display) != -1) {
> > > > [...process user input...]
> > > > }
> > > >
> > > > This is the only place where events are processed.
> > > >
> > > > Rendering however is done on a separate thread, which eventually ends
> > > > up calling:
> > > >
> > > > wl_surface_attach(surface, buffer, 0, 0);
> > > > wl_surface_damage(surface, x, y, width, height);
> > > > wl_surface_commit(surface);
> > > > wl_display_flush(display);
> > > >
> > > > Is this safe or do I need to do any additional locking /
> > > > synchronization?
> > >
> > > Hi,
> > >
> > > that depends.
> > >
> > > First thing is if you have event handlers, for example wl_callback.done
> > > for wl_surface.frame which you really should be using to throttle your
> > > rendering. Event callbacks get dispatched from where the dispatch
> > > function is called, so that could race with your rendering thread.
> > >
> > > Another thing is window management. If you handle xdg_toplevel events
> > > and set window state while your animation is already running, it
> > > depends on from which thread you send the window state requests. If you
> > > send those from the rendering thread, it's fine. If you send those from
> > > the main thread, then they will race against your rendering thread
> > > sending wl_surface.commit. In some cases that might even lead to fatal
> > > protocol errors as you cannot reliably operate the protocol correctly.
> > >
> > > Usually when threads are involved, you dispatch the wl_display itself
> > > in one thread, and for each other thread touching Wayland you create a
> > > new wl_event_queue and with the help of wl_proxy_create_wrapper() you
> > > assing new protocol objects to the appropriate queue. This ensures the
> > > dispatching will happen in the thread where you want it.
> >
> > Thank you for your answer. This is an embedded fullscreen application, so no
> > window management.
>
> Fullscreen is one of the modes where you need to be careful with your
> window size and synchronise correctly to obey the compositor's demands.
Can you elaborate on this?
btw I said fullscreen but this is actually a toplevel shell surface
with the same
size as the current video mode (so that it occuppies the whole screen).
Best,
Guillermo Rodriguez Garcia
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fullscreen window (Re: Thread safety when rendering on a separate thread)
Hi, El lun., 27 ene. 2020 a las 14:21, Pekka Paalanen () escribió: > > On Mon, 27 Jan 2020 12:58:13 +0100 > Guillermo Rodriguez wrote: > > > El lun., 27 ene. 2020 a las 12:53, Pekka Paalanen > > () escribió: > > > > > > On Mon, 27 Jan 2020 12:36:27 +0100 > > > Guillermo Rodriguez wrote: > > > > > > > Thank you for your answer. This is an embedded fullscreen application, > > > > so no > > > > window management. > > > > > > Fullscreen is one of the modes where you need to be careful with your > > > window size and synchronise correctly to obey the compositor's demands. > > > > Can you elaborate on this? > > Hi, > > the xdg-shell extension suite has some rules on when the client must > obey compositor constraints and when it is free to pick any window size > it wants. > > I am assuming that you are using the xdg-shell extension suite for > window management. If you are using some other extension for window > management, that changes things. In any case, you must be using some > window management extension, because otherwise the window will not > appear on screen. I'm using wl_shell. > > > btw I said fullscreen but this is actually a toplevel shell surface > > with the same > > size as the current video mode (so that it occuppies the whole screen). > > That is not fullscreen but a floating window with a peculiar size. > Position of the window could be anywhere, and does not prevent UI > components like desktop panels from displacing it or showing on top of > it. Yes, that's why I clarified that it is not really a fullscreen surface, but a toplevel surface with the dimensions of the screen. (I know that position of the window is not specified by the protocol, but Weston is always placing the surface at 0,0) Also this is an embedded system where there are no other components such as desktop panels... BR, Guillermo Rodriguez Garcia ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fullscreen window (Re: Thread safety when rendering on a separate thread)
El mar., 28 ene. 2020 a las 12:55, Pekka Paalanen () escribió: > > On Mon, 27 Jan 2020 16:13:41 +0100 > Guillermo Rodriguez wrote: > > > Hi, > > > > El lun., 27 ene. 2020 a las 14:21, Pekka Paalanen > > () escribió: > > > > > > On Mon, 27 Jan 2020 12:58:13 +0100 > > > Guillermo Rodriguez wrote: > > > > > > > El lun., 27 ene. 2020 a las 12:53, Pekka Paalanen > > > > () escribió: > > > > > > > > > > On Mon, 27 Jan 2020 12:36:27 +0100 > > > > > Guillermo Rodriguez wrote: > > > > > > > > > > > Thank you for your answer. This is an embedded fullscreen > > > > > > application, so no > > > > > > window management. > > > > > > > > > > Fullscreen is one of the modes where you need to be careful with your > > > > > window size and synchronise correctly to obey the compositor's > > > > > demands. > > > > > > > > Can you elaborate on this? > > > > > > Hi, > > > > > > the xdg-shell extension suite has some rules on when the client must > > > obey compositor constraints and when it is free to pick any window size > > > it wants. > > > > > > I am assuming that you are using the xdg-shell extension suite for > > > window management. If you are using some other extension for window > > > management, that changes things. In any case, you must be using some > > > window management extension, because otherwise the window will not > > > appear on screen. > > > > I'm using wl_shell. > > Ok, the deprecated one. Even wl_shell has > wl_shell_surface.set_fullscreen you could use. I must note though that > the special features of fullscreen method and preferred framerate are > not implemented in Weston. > > If possible, I would recommend migrating to the xdg-shell extension > suite which is maintained both protocol and implementation wise. > > > > > btw I said fullscreen but this is actually a toplevel shell surface > > > > with the same > > > > size as the current video mode (so that it occuppies the whole screen). > > > > > > That is not fullscreen but a floating window with a peculiar size. > > > Position of the window could be anywhere, and does not prevent UI > > > components like desktop panels from displacing it or showing on top of > > > it. > > > > Yes, that's why I clarified that it is not really a fullscreen > > surface, but a toplevel surface with the dimensions of the screen. > > (I know that position of the window is not specified by the protocol, > > but Weston is always placing the surface at 0,0) > > That is an accident you should not rely on. Weston generally uses > random() to position floating windows at the moment, but currently does > attempt to keep the whole window visible. > > > Also this is an embedded system where there are no other components > > such as desktop panels... > > Sure, but you risk it breaking on a Weston update if you don't use the > protocol to ensure you get what you want. > > IIRC the user can use a key-mouse-combination to force-move or rotate > any floating window but not a fullscreen window. Just tried this but found that fullscreen windows seem to be made fully opaque (black surface behind), which does not work for me. I have two "pseudo full screen" windows, one is stacked on top of the other, and the topmost window needs to have transparent areas. So I guess I will need to stick with a toplevel surface and rely on Weston keeping the whole window visible.. BR, Guillermo Rodriguez Garcia ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fullscreen window (Re: Thread safety when rendering on a separate thread)
El jue., 30 ene. 2020 a las 12:25, Pekka Paalanen () escribió: > > On Thu, 30 Jan 2020 11:46:59 +0100 > Guillermo Rodriguez wrote: > > > Just tried this but found that fullscreen windows seem to be made > > fully opaque (black surface behind), which does not work for me. > > Yes, that is very intentional. > > > I have two "pseudo full screen" windows, one is stacked on top of the > > other, and the topmost window needs to have transparent areas. > > The same process or separate processes? > > The same client or separate clients? > > Usually that is managed by making one of the windows a sub-surface for > the other, but that only works within the same client. Yes, but this is not possible in my case. These are two separate applications; one of them (the "main" application) controls the other (a OSD style component which stays on top) by sending commands to it through a CLI. So I cannot easily make one window a sub-surface of the other. > > > So I guess I will need to stick with a toplevel surface and rely on > > Weston keeping the whole window visible.. > > That is very unfortunate. We cannot even attempt to keep that working > from upstream side. You are depending on luck for window positioning > and stacking order. Wouldn't a user hitting Mod+Tab or Alt+Tab already > break your setup? Well, there's no keyboard :-) > > Do you prevent pointer and touch input to one of the windows completely > via input regions? Yes; the OSD app does not accept any input. > > Sounds like fixing that properly could mean an architectural re-design > for your application. If that means combining the two applications into one -- I'd rather not do that; there are multiplea reasons why these are designed as independent applications. Ideally I should be able to find a way to setup Wayland to fit the requirements rather than the opposite (tweak the requirements to fit Wayland :-) BR, Guillermo Rodriguez Garcia ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fullscreen window (Re: Thread safety when rendering on a separate thread)
El jue., 30 ene. 2020 a las 13:33, Pekka Paalanen () escribió: > > On Thu, 30 Jan 2020 12:49:34 +0100 > Guillermo Rodriguez wrote: > > > El jue., 30 ene. 2020 a las 12:25, Pekka Paalanen > > () escribió: > > > > > > On Thu, 30 Jan 2020 11:46:59 +0100 > > > Guillermo Rodriguez wrote: > > > > > > > Just tried this but found that fullscreen windows seem to be made > > > > fully opaque (black surface behind), which does not work for me. > > > > > > Yes, that is very intentional. > > > > > > > I have two "pseudo full screen" windows, one is stacked on top of the > > > > other, and the topmost window needs to have transparent areas. > > > > > > The same process or separate processes? > > > > > > The same client or separate clients? > > > > > > Usually that is managed by making one of the windows a sub-surface for > > > the other, but that only works within the same client. > > > > Yes, but this is not possible in my case. These are two separate > > applications; one of them (the "main" application) controls the other > > (a OSD style component which stays on top) by sending commands to it > > through a CLI. > > So I cannot easily make one window a sub-surface of the other. > > > > > > > > > So I guess I will need to stick with a toplevel surface and rely on > > > > Weston keeping the whole window visible.. > > > > > > That is very unfortunate. We cannot even attempt to keep that working > > > from upstream side. You are depending on luck for window positioning > > > and stacking order. Wouldn't a user hitting Mod+Tab or Alt+Tab already > > > break your setup? > > > > Well, there's no keyboard :-) > > > > > > > > Do you prevent pointer and touch input to one of the windows completely > > > via input regions? > > > > Yes; the OSD app does not accept any input. > > > > > > > > Sounds like fixing that properly could mean an architectural re-design > > > for your application. > > > > If that means combining the two applications into one -- I'd rather > > not do that; there are multiplea reasons why these are designed as > > independent applications. > > Ideally I should be able to find a way to setup Wayland to fit the > > requirements rather than the opposite (tweak the requirements to fit > > Wayland :-) > > Right. Since this is now obviously not about a desktop use case anymore > but a quite a specialised use case with probably even a closed system, > you do not have to settle for the normal desktop extensions of Wayland. > > The OSD is not a "normal desktop client", so it could use a different > Wayland extension for managing its window. I believe wlroots has some > extensions that could apply, and you can always write your own custom > extensions. Both have the caveat that you need to write the Weston > implementation as well. The benefit is that then you will have > guaranteed behaviour: the compositor knows what the OSD actually is and > has code to specifically keep it where it belongs. > > Since the OSD probably does not interact with any other window > management, I think it might be possible to implement the protocol > extension as a downstream Weston plugin rather than hacking e.g. > desktop-shell/shell.c in weston. > > If the OSD is actually fullscreen-sized right now but you only need a > sub-part of that area, meaning that most of the OSD window is completely > transparent, then with a suitable protocol extension you could avoid > having the completely transparent areas. Transparent areas still need > to be composited one way or another, so not having them could be a > a win in performance or power consumption. Yes, that makes sense. Is there any documentation or examples on how to write custom protocol extensions and/or Weston plugins? Anyway this only solves half of the problem, doesn't it? I mean: Even if I have a custom protocol extension or plugin to handle the positioning/ of the OSD window, the "main" application (which also needs to be fullscreen-sized) still needs to be a regular toplevel surface, as otherwise it would be shown on top of all other surfaces, including the OSD window... BR, Guillermo Rodriguez Garcia ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fullscreen window (Re: Thread safety when rendering on a separate thread)
Hi, El jue., 30 ene. 2020 a las 16:48, Pekka Paalanen () escribió: > > On Thu, 30 Jan 2020 16:06:19 +0100 > Guillermo Rodriguez wrote: > > > El jue., 30 ene. 2020 a las 13:33, Pekka Paalanen > > () escribió: > > > > > > On Thu, 30 Jan 2020 12:49:34 +0100 > > > Guillermo Rodriguez wrote: > > > > > > > > If that means combining the two applications into one -- I'd rather > > > > not do that; there are multiplea reasons why these are designed as > > > > independent applications. > > > > Ideally I should be able to find a way to setup Wayland to fit the > > > > requirements rather than the opposite (tweak the requirements to fit > > > > Wayland :-) > > > > > > Right. Since this is now obviously not about a desktop use case anymore > > > but a quite a specialised use case with probably even a closed system, > > > you do not have to settle for the normal desktop extensions of Wayland. > > > > > > The OSD is not a "normal desktop client", so it could use a different > > > Wayland extension for managing its window. I believe wlroots has some > > > extensions that could apply, and you can always write your own custom > > > extensions. Both have the caveat that you need to write the Weston > > > implementation as well. The benefit is that then you will have > > > guaranteed behaviour: the compositor knows what the OSD actually is and > > > has code to specifically keep it where it belongs. > > > > > > Since the OSD probably does not interact with any other window > > > management, I think it might be possible to implement the protocol > > > extension as a downstream Weston plugin rather than hacking e.g. > > > desktop-shell/shell.c in weston. > > > > > > If the OSD is actually fullscreen-sized right now but you only need a > > > sub-part of that area, meaning that most of the OSD window is completely > > > transparent, then with a suitable protocol extension you could avoid > > > having the completely transparent areas. Transparent areas still need > > > to be composited one way or another, so not having them could be a > > > a win in performance or power consumption. > > > > Yes, that makes sense. Is there any documentation or examples on how > > to write custom protocol extensions and/or Weston plugins? > > Hi, > > hmm, that's a good question. Weston repository itself has some plugins > in-tree. tests/weston-test.c is a small and rough plugin that the test > suite uses to map test windows bypassing all normal window management. > It implements the custom test extension from protocol/weston-test.xml. > Confusingly, the interesting bits for you are in move_surface() which > also maps the window. > > The point of the new extension protocol for an OSD would be to take a > wl_surface and give it a new role "OSD" for example. "Role" is a term > defined in the wl_surface specification. Looks like the test plugin > forgets to use weston_surface_set_role() when it should. > > You can grep for weston_surface_set_role() to find other roles and > their implementations. > > Oh, "weston_touch_calibrator" role is probably a much better example > than the test plugin. A touch calibrator is a fullscreen window used for > calibrating touchscreens, where the client needs to know both the raw > touch coordinates and on-screen image coordinates. It needs to grab > input too. I see. I'll need to study all of this.. > > > Anyway this only solves half of the problem, doesn't it? > > I mean: Even if I have a custom protocol extension or plugin to handle > > the positioning/ of the OSD window, the "main" application (which also > > needs to be fullscreen-sized) still needs to be a regular toplevel > > surface, as otherwise it would be shown on top of all other surfaces, > > including the OSD window... > > You'd be writing some window manager bits, so in Weston you can put the > OSD view on a layer that is always on top of everything else. Then you > can make the real main window a proper fullscreen window, and even when > it is active and "top-most", the OSD will still appear on top of it. Uhm, I am not sure to understand this bit. Based on your comments before I am assuming I would implement this as a plugin / addon, instead of hacking shell.c. So if my plugin / addon creates a new layer, how do I make Weston "aware" of this layer ? Thx, Guillermo > > Weston uses the same mechanism to keep the pointer cursor view on top of > absolutely everything. (Cursors don't have any special handling outside > the window management, they are views just like everything else.) > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fullscreen window (Re: Thread safety when rendering on a separate thread)
El vie., 31 ene. 2020 a las 9:44, Pekka Paalanen () escribió: > > On Thu, 30 Jan 2020 17:48:54 +0100 > Guillermo Rodriguez wrote: > > > Hi, > > > > El jue., 30 ene. 2020 a las 16:48, Pekka Paalanen > > () escribió: > > > Uhm, I am not sure to understand this bit. Based on your comments > > before I am assuming I would implement this as a plugin / addon, > > instead of hacking shell.c. > > So if my plugin / addon creates a new layer, how do I make Weston > > "aware" of this layer ? > > Hi, > > Weston core handles layers, desktop-shell et al. just manipulate them. > > Look for 'struct weston_layer' and 'enum weston_layer_position'. A > plugin can basically invent a new layer, hook it up and assing it a > position (stacking order) from the enum values or any other value in > between. The enum is there to give some idea of what layers generally > might exist and how they are ordered so you can pick a suitable > position value. > Yes, but doesn't desktop-shell need to be aware of these new layers? For example, when the screen is locked, desktop-shell hides the layers it knows about and shows the lock layer. If my plugin invents a new layer and hooks it up, desktop-shell will not know anything about it and it will not be hidden when the screen is locked... Guillermo Rodriguez Garcia ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Asynchronous frame updates
Hi all,
This is a followup question to an earlier thread on this ML ("Thread
safety when rendering on a separate thread")
The story was like this:
> > Hi all,
> >
> > I have a Wayland client where the main loop runs on a thread and
> > rendering is done in a separate thread. The main loop simply uses
> > wl_display_dispatch:
> >
> > while (wl_display_dispatch(globals.display) != -1) {
> > [...process user input...]
> > }
> >
> > This is the only place where events are processed.
> >
> > Rendering however is done on a separate thread, which eventually ends
> > up calling:
> >
> > wl_surface_attach(surface, buffer, 0, 0);
> > wl_surface_damage(surface, x, y, width, height);
> > wl_surface_commit(surface);
> > wl_display_flush(display);
> >
> > Is this safe or do I need to do any additional locking / synchronization?
>
> Hi,
>
> that depends.
>
> First thing is if you have event handlers, for example wl_callback.done
> for wl_surface.frame which you really should be using to throttle your
> rendering. Event callbacks get dispatched from where the dispatch
> function is called, so that could race with your rendering thread.
[...]
Most of the examples I can find that use wl_callback.done assume that
the application is ready to draw whenever it gets the callback (so in
the callback, the application simply draws the next frame).
But how would this be handled if the application needs to draw at
application defined times? e.g. for an animation loop, or when an
external event happens? When wl_callback.done runs, there is nothing
new to draw yet. And at some later time, the application wants to
update the display. Should it then simply draw as follows:
wl_surface_attach(surface, buffer, 0, 0);
wl_surface_damage(surface, x, y, width, height);
wl_surface_commit(surface);
wl_display_flush(display);
(note: this would happen on a thread which is not the same thread
where the main loop runs -- see above).
Thank you,
Guillermo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Aliases for DRI connectors?
Hi Pekka, El vie., 3 abr. 2020 a las 10:14, Pekka Paalanen () escribió: > > On Wed, 1 Apr 2020 14:38:37 -0500 > Matt Hoosier wrote: > > > I'm searching for some sort of scheme that will let my DRI master query the > > set of available connectors and select the one carrying a prearranged > > designation. The problem I'm trying to solve is to allow deploying one > > standardized userspace component across a fleet of devices that have > > varying numbers of displays, with the use cases not always driven on the > > same connector topologically. > > > > I had a look around the properties available on my system's DRI connectors, > > and nothing immediate jumped out at me. Is there a standard connector > > property that (assuming I can find the right place in DeviceTree or similar > > to) that would be a good fit for this? > > Hi, > > I've never heard of a thing that could accomplish that. DRM connector > names are not even actually communicated to userspace. What userspace > sees is connector type (enum) and some counter numbers (which are not > persistent, so not reliable if you have e.g. multiple DRM drivers > racing to initialize), I may be misreading you, but does this mean that the connector names used in the [output] section of the weston.ini configuration file are not reliable? Then what is the proper way to configure one specific (physical) output in Weston? BR, Guillermo > and then userspace manufactures a connector name > from those. This has been most painful with Xorg, where the different > video DDX drivers used to use different conventions in making up the > names, meaning that if you switched DDXes (e.g. between driver-specific > driver and modesetting driver), the connector names changed > invalidating your xorg.conf. > > However, the problem of non-persistent connector names has been thought > of, see e.g.: > https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html > The thread has messages also in July and August. > > If you had reliable, persistent connector names (and used e.g. device > path from udev to reliably identify DRM devices), maybe you could build > something on top of that? > > Though I doubt if maintainers would like your config to be in DT or > kernel, maybe it needs to be handled in userspace? > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Aliases for DRI connectors?
Hi Pekka, El vie., 3 abr. 2020 a las 12:03, Pekka Paalanen () escribió: > > On Fri, 3 Apr 2020 10:28:52 +0200 > Guillermo Rodriguez wrote: > > > Hi Pekka, > > > > El vie., 3 abr. 2020 a las 10:14, Pekka Paalanen > > () escribió: > > > > > > On Wed, 1 Apr 2020 14:38:37 -0500 > > > Matt Hoosier wrote: > > > > > > > I'm searching for some sort of scheme that will let my DRI master query > > > > the > > > > set of available connectors and select the one carrying a prearranged > > > > designation. The problem I'm trying to solve is to allow deploying one > > > > standardized userspace component across a fleet of devices that have > > > > varying numbers of displays, with the use cases not always driven on the > > > > same connector topologically. > > > > > > > > I had a look around the properties available on my system's DRI > > > > connectors, > > > > and nothing immediate jumped out at me. Is there a standard connector > > > > property that (assuming I can find the right place in DeviceTree or > > > > similar > > > > to) that would be a good fit for this? > > > > > > Hi, > > > > > > I've never heard of a thing that could accomplish that. DRM connector > > > names are not even actually communicated to userspace. What userspace > > > sees is connector type (enum) and some counter numbers (which are not > > > persistent, so not reliable if you have e.g. multiple DRM drivers > > > racing to initialize), > > > > I may be misreading you, but does this mean that the connector names > > used in the [output] section of the weston.ini configuration file are > > not reliable? > > Yes, they are not generally reliable. They are reliable enough in most > cases, particularly if you have only one DRM device with connectors. > DRM drivers themselves often manage to not race internally, so they are > fairly consistent in what order they create their connectors per device. > > Xorg has the exact same problem IIRC, as has probably any display > server on Linux. This means that to find a case where the reliability > actually breaks down you have to try quite hard or be very unlucky, > since it has gone unfixed for so long. > > Likewise you cannot rely that /dev/dri/card0 is always the same device > if you have multiple. That issue is showing up a little more than the > connector naming issue. Hence /dev/dri/by-path/ aliases exist. Network > devices have hit the same naming problem a long time ago already, hence > we nowadays have "Predictable Network Interface Names". > > > Then what is the proper way to configure one specific (physical) > > output in Weston? > > There is no better way yet. I've had some ideas, but no time to look > into them. > > MST connectors have a KMS property for the hardware path, but Weston > does not look at that, and the other connectors don't even have it. Ok so this is a known "problem" which has never been fixed, probably because in most cases (single DRM device) the current solution is good enough. Thank you for the clarification. BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Possible resource leak in Weston
Hi all, I am investigating something that looks like a resource leak in Weston. I first saw the problem in an application involving Gstreamer, which would run out of fds after a number of iterations (~1000). However I have also been able to reproduce it without using Gstreamer. This is the scenario: I have a wayland application that uses Gstreamer to display video. The application creates the display connection (wl_display_connect) and a top-level surface; these last for the lifetime of the application. Every time the application needs to show a video fragment, it builds a Gstreamer pipeline, and passes the display and surface handles to Gstreamer's waylandsink. This ends up calling the gst_wl_display_new_existing function [1], which registers a listener for the wayland registry and binds to some interfaces [2]. Binding to the wl_shell interface results in a call to weston_desktop_wl_shell_bind -> weston_desktop_client_create where some resources are created, including, among others, a ping timer. When Gstreamer is done showing the video, it cleans up and releases all resources. As part of this process it calls wl_shell_destroy [3], however this does NOT result in a call to weston_desktop_client_destroy, and so the associated resources are not released. In fact, the resources are only released when the application disconnects (wl_display_disconnect) and exits. At this point, all "pending" calls to weston_desktop_client_destroy are made. The original symptoms (application running out of fds) are only visible with wayland < 1.18.0. This is because up to 1.18.0, one timerfd was being used for each ping timer. This was changed in this commit [4]. However even if the symptoms are less visible, the issue still exists in Weston. Does this make sense? In case I am not overlooking something and this is indeed a Weston issue, any hints on how to fix it? Thank you, Guillermo Rodriguez [1]: https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/wayland/wldisplay.c#L295 [2]: https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/wayland/wldisplay.c#L204 [3]: https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/wayland/wldisplay.c#L91 [4]: https://github.com/wayland-project/wayland/commit/60a8d29ad8526c18cc670612e2c94f443873011a ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible resource leak in Weston
Hi Pekka, El jue., 23 abr. 2020 a las 11:43, Pekka Paalanen () escribió: > > On Wed, 22 Apr 2020 16:45:42 +0200 > Guillermo Rodriguez wrote: > > > Hi all, > > > > I am investigating something that looks like a resource leak in > > Weston. I first saw the problem in an application involving Gstreamer, > > which would run out of fds after a number of iterations (~1000). > > However I have also been able to reproduce it without using Gstreamer. > > > > This is the scenario: > > > > I have a wayland application that uses Gstreamer to display video. The > > application creates the display connection (wl_display_connect) and a > > top-level surface; these last for the lifetime of the application. > > Every time the application needs to show a video fragment, it builds a > > Gstreamer pipeline, and passes the display and surface handles to > > Gstreamer's waylandsink. > > > > This ends up calling the gst_wl_display_new_existing function [1], > > which registers a listener for the wayland registry and binds to some > > interfaces [2]. Binding to the wl_shell interface results in a call to > > weston_desktop_wl_shell_bind -> weston_desktop_client_create where > > some resources are created, including, among others, a ping timer. > > > > When Gstreamer is done showing the video, it cleans up and releases > > all resources. As part of this process it calls wl_shell_destroy [3], > > however this does NOT result in a call to > > weston_desktop_client_destroy, and so the associated resources are not > > released. In fact, the resources are only released when the > > application disconnects (wl_display_disconnect) and exits. At this > > point, all "pending" calls to weston_desktop_client_destroy are made. > > > > The original symptoms (application running out of fds) are only > > visible with wayland < 1.18.0. This is because up to 1.18.0, one > > timerfd was being used for each ping timer. This was changed in this > > commit [4]. However even if the symptoms are less visible, the issue > > still exists in Weston. > > > > Does this make sense? > > Hi, > > yes, it does make sense, I think. > > > In case I am not overlooking something and this is indeed a Weston > > issue, any hints on how to fix it? > > It is mostly a Weston issue, but there are a couple Wayland protocol > issues as well: > > - wl_registry does not have a destroy request defined, hence the > compositor cannot know when a client destroys a wl_registry. The > compositor side of a wl_registry object can only be reaped when the > client disconnects. Fixing this is cumbersome. > > - wl_shell interface does not have a destroy request either. However, > adding one would be much easier that with wl_registry. OTOH, wl_shell > is deprecated, so even if we add one, I doubt the clients still using > it would get fixed. > > The above are fundamental but relatively minor leaks during a client's > lifetime in the compositor. Solving them should not be necessary for > solving your immediate problem, but they would be needed for a complete > solution rather than just pushing the failure point even further out. The lack of a destroy request for wl_shell seems to be the root of the problem in my case. Each time my application needs to show a video fragment it builds a Gstreamer pipeline, Gstreamer's waylandsink binds to the wl_shell client, and this results in the creation of a new ping timer. Once the video stops the timer resources are not released. After a number of iterations of this process, the application cannot show video anymore. You mention that "solving this should not be necessary for solving my immediate problem", but I am not sure why you say that. If the wl_shell objects (and associated resources) are being leaked, how do I work around this issue? > > There is also a peculiarity with the wl_shell_surface interface: it > does not have a destroy request defined, but the protocol object is > documented to be destroyed when the wl_surface is destroyed. You might > want to check libweston-desktop actually implements this, and that the > client also does destroy the wl_surface. > > In the early days of Wayland, we missed to add destroy requests to many > interfaces which we assumed would only be instantiated once in a > client's lifetime. That's why the oldest levels of the protocol > interfaces are inconsistent wrt. freeing. > > The rest is issues with libweston-desktop or weston in general. I'm not > too familiar with libweston-desktop, but I have some ideas. > > To me it looks like libweston-desktop hangs too much data (includ
Re: Possible resource leak in Weston
Hi Pekka, El vie., 24 abr. 2020 a las 12:50, Pekka Paalanen () escribió: > > On Thu, 23 Apr 2020 16:14:43 +0200 > Guillermo Rodriguez wrote: > > > Hi Pekka, > > > > El jue., 23 abr. 2020 a las 11:43, Pekka Paalanen > > () escribió: > > > > > > On Wed, 22 Apr 2020 16:45:42 +0200 > > > Guillermo Rodriguez wrote: > > > > > > > Hi all, > > > > > > > > I am investigating something that looks like a resource leak in > > > > Weston. I first saw the problem in an application involving Gstreamer, > > > > which would run out of fds after a number of iterations (~1000). > > > > However I have also been able to reproduce it without using Gstreamer. > > > > > > > > This is the scenario: > > > > > > > > I have a wayland application that uses Gstreamer to display video. The > > > > application creates the display connection (wl_display_connect) and a > > > > top-level surface; these last for the lifetime of the application. > > > > Every time the application needs to show a video fragment, it builds a > > > > Gstreamer pipeline, and passes the display and surface handles to > > > > Gstreamer's waylandsink. > > > > > > > > This ends up calling the gst_wl_display_new_existing function [1], > > > > which registers a listener for the wayland registry and binds to some > > > > interfaces [2]. Binding to the wl_shell interface results in a call to > > > > weston_desktop_wl_shell_bind -> weston_desktop_client_create where > > > > some resources are created, including, among others, a ping timer. > > > > > > > > When Gstreamer is done showing the video, it cleans up and releases > > > > all resources. As part of this process it calls wl_shell_destroy [3], > > > > however this does NOT result in a call to > > > > weston_desktop_client_destroy, and so the associated resources are not > > > > released. In fact, the resources are only released when the > > > > application disconnects (wl_display_disconnect) and exits. At this > > > > point, all "pending" calls to weston_desktop_client_destroy are made. > > > > > > > > The original symptoms (application running out of fds) are only > > > > visible with wayland < 1.18.0. This is because up to 1.18.0, one > > > > timerfd was being used for each ping timer. This was changed in this > > > > commit [4]. However even if the symptoms are less visible, the issue > > > > still exists in Weston. > > > > > > > > Does this make sense? > > > > > > Hi, > > > > > > yes, it does make sense, I think. > > > > > > > In case I am not overlooking something and this is indeed a Weston > > > > issue, any hints on how to fix it? > > > > > > It is mostly a Weston issue, but there are a couple Wayland protocol > > > issues as well: > > > > > > - wl_registry does not have a destroy request defined, hence the > > > compositor cannot know when a client destroys a wl_registry. The > > > compositor side of a wl_registry object can only be reaped when the > > > client disconnects. Fixing this is cumbersome. > > > > > > - wl_shell interface does not have a destroy request either. However, > > > adding one would be much easier that with wl_registry. OTOH, wl_shell > > > is deprecated, so even if we add one, I doubt the clients still using > > > it would get fixed. > > > > > > The above are fundamental but relatively minor leaks during a client's > > > lifetime in the compositor. Solving them should not be necessary for > > > solving your immediate problem, but they would be needed for a complete > > > solution rather than just pushing the failure point even further out. > > > > The lack of a destroy request for wl_shell seems to be the root of the > > problem in my case. > > Each time my application needs to show a video fragment it builds a > > Gstreamer pipeline, Gstreamer's waylandsink binds to the wl_shell > > client, and this results in the creation of a new ping timer. Once the > > video stops the timer resources are not released. After a number of > > iterations of this process, the application cannot show video anymore. > > > > You mention that "solving this should not be necessary for solving my > > immediate problem", but I am not sure why you say tha
Fwd: Best practices for client side buffer management
(Resending to the list) Hi Brad, El vie., 19 jun. 2020 a las 5:24, Brad Robinson () escribió: [...] > > Finally, the toolkit already maintains an off-screen buffer with the window's > current contents rendered into it. I'll probably replace that with a Wayland > buffer, but wondering about partial updates. eg: if the client only needs to > redraw a part of the window what's the correct process to update just that > part with Wayland. Can I just update the existing buffer and prompt Wayland > to just redraw that part? I am facing a similar situation with a toolkit that maintains an off-screen buffer with the current window contents, and will update that buffer at arbitrary times, when the application needs to update the UI. You must consider the following: Once you submit a buffer to Wayland you cannot touch it anymore until the compositor releases it back (wl_buffer.release callback). From Pekka's email: > When you submit a buffer to a Wayland compositor, it gives the > compositor permission to read the buffer at any time, as many times as > it wants to, until it tells you with wl_buffer.release that it will not > be looking at that buffer again. You must not write to a buffer that > might be read by the compositor, as that can cause misrendering on > screen (e.g. your repaint is shown unfinished). This means you cannot simply use the same off-screen buffer that the toolkit maintains, since the toolkit should not update the buffer once it submits it to Wayland. At some point I thought that I could have separate Wayland buffers and copy damaged regions from the toolkit buffer to one of these Wayland buffers before submitting it to the compositor. The idea would be to copy the set of regions that were damaged since the last update. But just copying damaged regions is not enough either. From Pekka's email: > Also, every buffer you submit must be fully drawn, also outside of the > areas you mark as damage. The compositor may be reading more than just > the damage you submit. So this means that everytime the toolkit updates the off-screen buffer, I may need to copy _the entire thing_ to a Wayland buffer and submit it to the compositor... not very efficient I guess. I have the feeling that Wayland is designed for a model where the client renders the entire frame on demand (most of the examples I've found so far work like this) and not for a model where the client is updating a buffer asynchronously and you just want to tell the compositor to update parts of the frame. I would be very interested to learn about your solution to this problem. Best, Guillermo Rodriguez Garcia ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Add z-order control into kiosk-shell?
Hi Matt,
Mi use case is exactly the same as you describe: embedded systems where the
output is generated from separate apps. In my case there is:
- The main app with its UI (bottom layer)
- Video output from gstreamer should be rendered on top (I don't want to
embed gstreamer in the main app for reliability reasons -- I prefer to keep
them as separate processes)
- An OSD may sometimes be needed above the video layer (again this is a
separate process; not using gstreamer's OSD facilities for several reasons)
I'm currently using the desktop shell for this but with a number of hacks
and patches.
So your proposal sounds really great.
I had originally dismissed kiosk-shell because I thought it only supported
a single top-level surface, same as the fullscreen shell. Now I see that I
was wrong.
So in summary I think your proposal looks great and adding this
functionality into kiosk-shell makes a lot of sense to me.
Guillermo
El vie, 1 oct 2021 a las 21:32, Hoosier, Matt ()
escribió:
> I've been very happy to see kiosk-shell get introduced in the past year or
> so. It seems to tick nearly every box that I frequently find myself wanting
> when trying to do embedded deployment of pre-existing Wayland apps which
> expect to use the customary desktop-centric shells:
>
>
>
>- declarative control over which output gets which surface
>- force the apps full-screen by default
>- no new protocols needed
>
>
>
> So this is really nice. Much lower barrier to entry than IVI Shell, and
> certainly a better re-use story for off-the-rack applications.
>
>
>
> But there's a niche that doesn't have any obvious answer yet: controlling
> the stacking order of different toplevel apps. It's fairly common to
> construct an embedded system using distributed rendering from separate
> programs. This means you need a way to control which things go above or
> below each other to achieve the overall effect.
>
>
>
> Would there be any interest in a contribution to enhance kiosk-shell to
> support configurable stacking orders? This might take the form of either
> relative specifications ("desktop surface XYZ always goes above desktop
> surface UWV") or absolute z-order specifications ("desktop surface XYZ's
> surfaces go into weston_layer #17").
>
>
>
> I haven't thought deeply yet about how the syntax for setting the
> stacking-order configuration in weston.ini would look. Maybe some kind of
> subscript annotation following the surface ID?
>
>
>
> [output]
>
> name=LVDS1
>
> # app1 goes in weston_layer 0. app2 goes in weston_layer 1
>
> app-ids=org.domain.app1[0],com.domain.app2[1]
>
>
>
> Or maybe allow more than one "app-ids" line, keyed by a subscript?
>
>
>
> [output]
>
> name=LVDS1
>
> app-ids[layer0]=org.domain.app1,...
>
> app-ids[layer1]=org.domain.app3,...
>
>
>
> -Matt
>
Wayland client, cleanup on exit
Hi all, Is it necessary to explicitly clean up and release any resources before exit in a Wayland client? Does that happen automatically if the process simply exits (in the same way that other resources such as memory or fds are automatically released) ? Thank you, Guillermo
Re: Wayland client, cleanup on exit
El mar, 4 abr 2023 a las 12:53, Simon Ser () escribió: > On Tuesday, April 4th, 2023 at 12:46, Guillermo Rodriguez Garcia < > guille.rodrig...@gmail.com> wrote: > > > One further question: before posting this here, I was trying to verify > > this by myself, and was wondering whether there is some sort of tool > > that can be used to monitor resources currently in use in a Wayland > > server. Does such a tool exist? > > I'm not aware of any. There is wlhax [1] which can be used to track > which protocol objects are alive for a given client. There is the > standard tooling to monitor allocated memory for a process. But I don't > know of any tool to monitor Wayland objects in a server specifically. > > [1]: https://git.sr.ht/~kennylevinsen/wlhax Thank you for the pointer! This is nice. Out of curiosity, for objects that are only released when a client disconnects (such as wl_registry), how does the Wayland server know how to release this if the client does not disconnect explicitly. in other words how is the resource leak on the server side avoided if the client just exits and the OS cleans up? Thanks again, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: Wayland client, cleanup on exit
El mar, 4 abr 2023 a las 13:28, Simon Ser () escribió: > On Tuesday, April 4th, 2023 at 13:26, Guillermo Rodriguez < > guillerodriguez@gmail.com> wrote: > > > Out of curiosity, for objects that are only released when a client > > disconnects (such as wl_registry), how does the Wayland server know > > how to release this if the client does not disconnect explicitly. in > > other words how is the resource leak on the server side avoided if the > > client just exits and the OS cleans up? > > libwayland-server notices that the socket is disconnected and cleans up > all Wayland objects belonging to it. > Understood, thank you! BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: Best practices for client side buffer management
Hi Brad, El vie., 19 jun. 2020 a las 5:24, Brad Robinson () escribió: [...] > > Finally, the toolkit already maintains an off-screen buffer with the window's > current contents rendered into it. I'll probably replace that with a Wayland > buffer, but wondering about partial updates. eg: if the client only needs to > redraw a part of the window what's the correct process to update just that > part with Wayland. Can I just update the existing buffer and prompt Wayland > to just redraw that part? I am facing a similar situation with a toolkit that maintains an off-screen buffer with the current window contents, and will update that buffer at arbitrary times, when the application needs to update the UI. You must consider the following: Once you submit a buffer to Wayland you cannot touch it anymore until the compositor releases it back (wl_buffer.release callback). From Pekka's email: > When you submit a buffer to a Wayland compositor, it gives the > compositor permission to read the buffer at any time, as many times as > it wants to, until it tells you with wl_buffer.release that it will not > be looking at that buffer again. You must not write to a buffer that > might be read by the compositor, as that can cause misrendering on > screen (e.g. your repaint is shown unfinished). This means you cannot simply use the same off-screen buffer that the toolkit maintains, since the toolkit should not update the buffer once it submits it to Wayland. At some point I thought that I could have separate Wayland buffers and copy damaged regions from the toolkit buffer to one of these Wayland buffers before submitting it to the compositor. The idea would be to copy the set of regions that were damaged since the last update. But just copying damaged regions is not enough either. From Pekka's email: > Also, every buffer you submit must be fully drawn, also outside of the > areas you mark as damage. The compositor may be reading more than just > the damage you submit. So this means that everytime the toolkit updates the off-screen buffer, I may need to copy _the entire thing_ to a Wayland buffer and submit it to the compositor... not very efficient I guess. I have the feeling that Wayland is designed for a model where the client renders the entire frame on demand (most of the examples I've found so far work like this) and not for a model where the client is updating a buffer asynchronously and you just want to tell the compositor to update parts of the frame. I would be very interested to learn about your solution to this problem. Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Basic API usage
El sábado, 12 de septiembre de 2020, Simon Ser escribió: > > > > To me this looks like the generated C code would frequently make use of > > unspecified interface versions, so that distro-maintainers would have to > > intensively take care about the exact version in use for any single app > > that makes use of libwayland-client, if he'd like to avoid random > > app-shutdowns due to calls to random pointers (and/or compilation > > errors) in addition to upstreaming recompiled versions for any such app. > > I don't know if it's just me, but your e-mails sound like rants and > aren't making it very appealing for people to reply to. > It is not just you. Guillermo -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Client-driven orientation change in Weston
Hi, I am asking this because I saw the following from Pekka Paalanen in another thread: > [...] Can the compositor do it all on its own, does the client need to synchronise to the orientation change, does the client need to drive the orientation change, etc. In Weston I am currently controlling the orientation via transform=xxx in the .ini file. Is it possible to drive this change dynamically from the client instead? BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: FW: xrandr and xwayland
Hi Daniel, El vie, 6 ago 2021 a las 10:14, Daniel Stone () escribió: > kiosk-shell is something we have in newer versions of Weston which > sounds like it would work well for your usecases - it's designed to > just run a single application fullscreen. You might want to check out > what we have in git, which will be released as 10.0 in a few weeks' > time. > I have a use case for this which is conceptually one single application, fullscreen, no desktop stuff (navigation bar, window management etc) but needs to support additional processes with separate top-level windows. This would be used e.g. to overlay a video stream (using gstreamer) on top of the "main" application. Will this be supported by kiosk-shell ? BR, guille.rodrig...@gmail.com
Re: FW: xrandr and xwayland
Hi Daniel, El vie, 6 ago 2021 a las 11:57, Daniel Stone () escribió: > Hi Guillermo, > > On Fri, 6 Aug 2021 at 10:44, Guillermo Rodriguez Garcia > wrote: > > El vie, 6 ago 2021 a las 10:14, Daniel Stone () > escribió: > >> kiosk-shell is something we have in newer versions of Weston which > >> sounds like it would work well for your usecases - it's designed to > >> just run a single application fullscreen. You might want to check out > >> what we have in git, which will be released as 10.0 in a few weeks' > >> time. > > > > I have a use case for this which is conceptually one single application, > fullscreen, no desktop stuff (navigation bar, window management etc) but > needs to support additional processes with separate top-level windows. This > would be used e.g. to overlay a video stream (using gstreamer) on top of > the "main" application. Will this be supported by kiosk-shell ? > > For clients to be able to position themselves relative to other > clients, wl_subcompositor gives you the subsurface mechanism for > embedding. This was designed for this exact usecase: an application > embedding media content in its own top-level window. Using this is > very strongly recommended. > But does this require that both "clients" run as the same process? I assume that's the case since I need to pass a handle of the parent wl_surface in order to create a subsurface. An important part of the problem is that we need to run the main application and the gstreamer client as separate processes. Thanks, Guillermo > If you are unable to do this for whatever reason, then you will need > to customise the window manager - in this case, kiosk-shell. We are > planning to extend this with Lua scripting to make this easier, but > have no firmly-defined ETA for this right now. > > Cheers, > Daniel > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
Re: Wayland client, cleanup on exit
Hello, El mar, 4 abr 2023 a las 12:33, Simon Ser () escribió: > Hi, > > On Tuesday, April 4th, 2023 at 12:16, Guillermo Rodriguez < > guillerodriguez@gmail.com> wrote: > > > Is it necessary to explicitly clean up and release any resources > > before exit in a Wayland client? Does that happen automatically if > > the process simply exits (in the same way that other resources such > > as memory or fds are automatically released) ? > > If you don't explicitly cleanup resources allocated by libwayland, it's > fine: the process won't leak any. IOW, resources allocated in a Wayland > client are cleaned up by the OS as usual. > > Thank you, this is very useful! One further question: before posting this here, I was trying to verify this by myself, and was wondering whether there is some sort of tool that can be used to monitor resources currently in use in a Wayland server. Does such a tool exist? Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com
