Two wayland connection in single process context

[Pekka Paalanen]

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

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,
pq
-------------- 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/8b2db696/attachment.sig>