Hello, El mar., 19 nov. 2019 a las 13:28, Pekka Paalanen (<ppaala...@gmail.com>) escribió: > > On Tue, 19 Nov 2019 12:48:10 +0100 > Guillermo Rodriguez <guillerodriguez....@gmail.com> wrote: > > > El mar., 19 nov. 2019 a las 11:47, Pekka Paalanen > > (<ppaala...@gmail.com>) escribió: > > > > > > On Tue, 19 Nov 2019 09:53:39 +0100 > > > Guillermo Rodriguez <guillerodriguez....@gmail.com> 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 my use case, I assume that implementing this is better than rolling my own protocol extension. > On initialization, the > plugin creates a wl_global for the protocol extension and handles the > OSD-specific requests through that. > > Examples of such custom wl_surface roles are weston_desktop.set_panel > and weston_desktop.set_background requests in Weston's > protocol/weston-desktop-shell.xml. The server implementation of these > can be found in desktop-shell/shell.c. > > Since it's always-on-top, you create a new weston_layer with a position > around WESTON_LAYER_POSITION_TOP_UI or so. When the OSD wl_surface > needs to be mapped, the weston_view of it is set into that > weston_layer. That should be all, on a high level idea. Great. Lots of useful information here. Will need to have a closer look into this. Thank you! > > The catch here is, that you would need to get GStreamer use the OSD > role instead of the top-level window role for the wl_surface. I believe > that should be well possible in a couple of ways even: you could write > an app-sink element, or, I do believe that waylandsink should allow > using an existing wl_display and a sub-surface... or some > Wayland-enabled sink should. I'm not too familiar with Gst but I'm sure > it's doable without too much hassle somehow. I assumed this wasn't supported out of the box in waylandsink but as Daniel Stone has already pointed out, I was wrong :-) Thanks again, Guillermo Rodriguez _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
