On Fri, 29 Jul 2016 17:53:38 +0530 Vikas Patil <vikasmpa...@gmail.com> wrote:
> On Fri, Jul 29, 2016 at 4:53 PM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Fri, 29 Jul 2016 15:03:39 +0530 > > Vikas Patil <vikasmpa...@gmail.com> wrote: > > > >> On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen <ppaala...@gmail.com> > >> wrote: > >> > >> > On Wed, 27 Jul 2016 17:06:04 +0530 > >> > Vikas Patil <vikasmpa...@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
pgpidQuqRuD1V.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel