Re: Two wayland connection in single process context
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 example and implement embedding. There the media playback will be a separate process, which opens a Wayland connection
Re: Two wayland connection in single process context
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 communicating with wayland: Protocol error >> Error communicating with wayland: Protocol error >>
Re: Two wayland connection in single process context
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
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
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
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