Re: Two wayland connection in single process context

[Pekka Paalanen]

On Fri, 29 Jul 2016 17:53:38 +0530
Vikas Patil  wrote:

> On Fri, Jul 29, 2016 at 4:53 PM, Pekka Paalanen  wrote:
> > On Fri, 29 Jul 2016 15:03:39 +0530
> > Vikas Patil  wrote:
> >  
> >> On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen  
> >> wrote:
> >>  
> >> > On Wed, 27 Jul 2016 17:06:04 +0530
> >> > Vikas Patil  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 

Re: Two wayland connection in single process context

[Vikas Patil]

On Fri, Jul 29, 2016 at 4:53 PM, Pekka Paalanen  wrote:
> On Fri, 29 Jul 2016 15:03:39 +0530
> Vikas Patil  wrote:
>
>> On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen  wrote:
>>
>> > On Wed, 27 Jul 2016 17:06:04 +0530
>> > Vikas Patil  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 

Re: Two wayland connection in single process context

[Pekka Paalanen]

On Fri, 29 Jul 2016 15:03:39 +0530
Vikas Patil  wrote:

> On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen  wrote:
> 
> > On Wed, 27 Jul 2016 17:06:04 +0530
> > Vikas Patil  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


pgpF3n9cj1Lii.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Two wayland connection in single process context

[Vikas Patil]

On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen  wrote:

> On Wed, 27 Jul 2016 17:06:04 +0530
> Vikas Patil  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.

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


Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Two wayland connection in single process context

[Pekka Paalanen]

On Wed, 27 Jul 2016 17:06:04 +0530
Vikas Patil  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.


Thanks,
pq


pgpcWNyZ1x33i.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Two wayland connection in single process context

[Armin Krezović]

On 27.07.2016 13:36, Vikas Patil 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.
> 
> Will this work? Is it this the right way to do it or is there any
> other mechanism available for such requirement?
> 
> Thanks & Regards,
> Vikash
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

Hi, have you looked at clients/nested.c and clients/nested-client.c?

It seems to be similar to what you want, but instead from a single process,
it appears to combine two differ clients into one, by making a nested
act as a wayland server and then letting the nested-client use nested as
its server.

I believe its aim was to solve a problem for Webkit's separate process
architecture, where renderer process was separate from the webkit's main
one.



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Two wayland connection in single process context

[Vikas Patil]

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.

Will this work? Is it this the right way to do it or is there any
other mechanism available for such requirement?

Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel