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....@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 (<amme...@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....@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@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
