Two wayland connection in single process context

[Vikas Patil]

On Fri, Jul 29, 2016 at 4:53 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 29 Jul 2016 15:03:39 +0530
> Vikas Patil <vikasmpatil at gmail.com> wrote:
>
>> On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>
>> > On Wed, 27 Jul 2016 17:06:04 +0530
>> > Vikas Patil <vikasmpatil at gmail.com> wrote:
>> >
>> >> Dear All,
>> >>
>> >> Could you comment/suggest on following approach of using two different
>> >> wayland connection in single process?
>> >>
>> >> First wayland connection for creating wl_shm backed wayland surface
>> >> for receiving touch inputs in main thread or as separate thread. Like
>> >> simple-touch.c example but without painting and transparent.
>> >>
>> >> Second wayland connection for another egl wayland surface for
>> >> rendering in shared library which will be loaded by above application.
>> >> Like simple-egl.c example.
>> >
>> > Hi,
>> >
>> > if you never want your first connection to handle input events on the
>> > surface created on the second connection, I suppose it would work. You
>> > also will not be able position your surfaces from the different
>> > connections relative to each other at all.
>> >
>> > The main thing to remember is that *everything* is private to a
>> > connection. If you create a wl_surface on one connection, it is as if
>> > it does not exist at all for any other connection. It does not matter
>> > if the connections come from the same thread, process, or not.
>> >
>> > If you expect any sort of interoperability, you *must* use the same
>> > connection for everything. Opening a second connection from the same
>> > program to the same server is practically always a design mistake.
>> >
>> > Of course, one could make Wayland extensions to work around this, but
>> > don't go there.
>> >
>> > So, in short: don't do it.
>> >
>> >> Will this work? Is it this the right way to do it or is there any
>> >> other mechanism available for such requirement?
>> >
>> > What do you want to achieve?
>> > You didn't explain what you really want to do.
>> >
>>
>> I have a video rendering library (which handles all media related
>> functions too) which is used by application, and that library make use
>> of first wayland connection and don't handle the touch events as there
>> is no way to pass that information to application so thinking to make
>> transparent wayland surface on top of wayland surface to which the
>> video is rendered by library to handle the touch events by creating
>> second wayland connection in application.
>
> There is no quick solution AFAIK.
>
> You have to fix both the application and the media library to become
> Wayland-friendly. The minimal starting point is:
>
> - the application (or its toolkit) opens the one Wayland connection
> - the application passes the open Wayland connection to the library
> - the library does not open new Wayland connections
>

Thanks a lot for putting your detail thought here.

Do you know if clients/nested.c, clients/nested-client.c mentioned by
"Armin Krezović " is helpful here in anyways? When I tried to run it
it just displayed black window? What functionality it demos?

What do you mean by passing "wayland connection" or passing
wl_surface? Does it mean passing the object handle with some kind of
IPC mechanism (possibly UNIX domain socket)?

Do you know any such implementation available for reference? I don't
have the code for our media library so I could try to create simple
POC for this first?


> Once you have done that, you have several options to choose from. I can
> think of at least these:
>
> - The application creates the wl_surface and tells the media library to
>   use it, or
> - the media library creates the wl_surface, and tells the app about it.
> - You handle input on the wl_surface that is being used by media
>   library either in the application, or
> - add media library API to handle or export input events.
> - Or you have two surfaces, one being the sub-surface for the other,
>   the media library uses one and the application uses the other for
>   input.
>
> If the media library can draw a complete window, it would be best to
> deal with just one wl_surface.
>
> If you have to have different wl_surfaces for input and output, you
> would use sub-surface protocol to tie them together. If the media
> library only draws video, you can set the input region there to empty,
> in which case input falls through to the next surface. That next
> surface could be your input surface, not transparent but painted with
> the background pattern and perhaps with decorations.
>
>> I tried creating and handling touch event (similar to simple-touch.c)
>> with second wayland connection after the application loads the library
>> but it gave me following errors. So I thought it might not be
>> possible. Also I think you hinted same here
>> https://lists.freedesktop.org/archives/wayland-devel/2015-September/024211.html
>>
>> Error communicating with wayland: Protocol error
>> Error communicating with wayland: Protocol error
>> Error communicating with wayland: Protocol error
>> Error communicating with wayland: Protocol error
>> Error communicating with wayland: Protocol error
>
> Yes, all protocol objects are valid only for the connection where they
> were created in.
>
> We lack the sanity checks in libwayland-client to abort() in the cases
> where that rule is broken.
>
> Really the very first step is to get everything to use the one and the
> same Wayland connection.
>

Thanks & Regards,
Vikash