Two wayland connection in single process context

Fri Jul 29 12:47:32 UTC 2016

On Fri, 29 Jul 2016 17:53:38 +0530
Vikas Patil <vikasmpatil at gmail.com> wrote:

> 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?

Those two demo the sub-compositor approach, where you have another
process providing part of the content. It is about embedding where you
really want a separate process for whatever reason, e.g. security.

nested.c is a normal Wayland client, but it is also a Wayland
mini-server. nested-client.c is a Wayland mini-client. The mini-client
draws with GL and commits its buffer to the mini-server, which then
composes its own window and commits that to the proper Wayland server.

If it displays just black, something is broken. Unfortunately the demo
depends on cairo-egl, so I believe it receives very little testing. It
is also possible that proprietary graphics stacks just don't implement
enough.

> 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)?

No. I just mean 'struct wl_display *' as an argument or return value
to/from a function. Or a 'struct wl_surface *'.

E.g. display_get_display():
https://cgit.freedesktop.org/wayland/weston/tree/clients/window.c?id=1.11.0#n5822

> 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?

Uhh, I'm not sure what to give you. It's really just about designing a
library API so that instead of the library opening its own connection,
it exports a function that takes 'struct wl_display *' as an argument
and uses that.

If you cannot modify the media library, the only remaining option is to
follow the nested.c example and implement embedding. There the media
playback will be a separate process, which opens a Wayland connection
to your application. Then your application acts as an intermediate
server (mini-server). Depending on the expectations of the media
library, you may need to implement a lot more of Wayland interfaces
than nested.c does.

Thanks,
pq

> 
> 
> > 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160729/6791354a/attachment.sig>