How to implement OSD overlay in Wayland/Weston

[Ilia Bozhinov]

You can try to use a compositor which supports xdg-foreign, except if you
don't already use private weston protocols.

In this case, you can just extend weston with a custom protocol to get the
placement you want to have.

On Tue, 19 Nov 2019, 11:42 Guillermo Rodriguez, <
guillerodriguez.dev at gmail.com> wrote:

> 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 (<ammen99 at gmail.com>)
> 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, <
> guillerodriguez.dev at 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.
> >>
> >> 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 at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20191119/b96bbec5/attachment.html>