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. 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 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. I think this should be possible also with GStreamer. > 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 is no way to send it back or to another client in Wayland. Input event routing is one-way. In Wayland, each client is isolated by default, and we try hard to keep things that way so there is no spying or injection. Thanks, pq
pgpN3eJn0TmCo.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
