On Thu, 26 Nov 2020 14:53:05 -0500 gherissi ayachi <gaya...@matrox.com> wrote:
> Hi, > > Background: our library allow to grab video to a supplied windows > handle, When using X11 the user pass the XID to the lib Hi, just in case I'm not understanding the question right: you can't read back window contents using Wayland. You need to make the application give the content to your library and anything else your library needs yourself. > and we can paint to this Window and do some interaction (pointer), All > is done in the same process. > > In Wayland, The user has to provide us with his wl_display and > wl_surface and we have to use subsurface to do the paint right ? Yes, that's one possibility, and the recommended one if the additional content is (particularly hardware decoded) video. The catch is that you need to carefully orchestrate all rendering and resizing with the application. Even if you normally have the sub-surface in desynchronized mode, you need to temporarily switch it to synchronized mode during window resizing, so that the window does not "break into parts" momentarily. This requires explicit API between the application and your library, Wayland is not enough. The other possibility is to not touch Wayland at all, and make the application call into your library to draw the additional content as part of drawing its own content. For video this is usually sub-optimal. If your library does create new wl_surfaces, you also need to make sure that the application can cope with Wayland events that deliver your library's wl_surface to the application, e.g. in wl_pointer.enter. Input events from Wayland perspective are no problem: your library can bind to all wl_seats and create its own wl_pointers etc. and those will deliver the same events as the application will get through its own wl_pointer etc. The catch is the above: both the application and the library need to understand which wl_surface is theirs and ignore input events targetting wl_surfaces that are not theirs. All the above assumes that your library is using the same wl_display instance as the application. If they don't, they become two separate Wayland clients, which is effectively the same as separate processes. Btw. "foreign surface" is usually used to refer to cross-process references to Wayland surface, e.g. by using https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml . That is not necessary if you can share the wl_display instance. Thanks, pq
pgpHxqDppoQ0u.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
