How to enable Wayland when original software support X?

[Wang, Quanxian]

Thanks pq.

> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> Sent: Wednesday, February 06, 2013 7:34 PM
> To: Wang, Quanxian
> Subject: Re: How to enable Wayland when original software support X?
> 
> > > I don't really see the "replace X operations with Wayland
> > > operations" as a feasible approach, in the way you have it below. I
> > > think it will become a nightmare to develop and maintain. The separation to
> X vs.
> > > Wayland paths should be done on a higher level, because usually
> > > there is no one-to-one correspondence at libwayland/xlib function
> > > level. At least you should use functions in different files instead of #ifdefs.
> > >
> > > > I think more and more developers will come across such issue when
> > > > they
> > > want to support Wayland.
> > > >
> > > > Here are some code translation.
> > > >
> > > > First part: open Display
> > > >
> > > > +#if ENABLE(TIZEN_WAYLAND)
> > > > +        g_nativeDisplay = wl_display_connect(NULL);
> > >
> > > Are you creating a new Wayland connection just for the WebGL widget,
> > > while the rest of the application is already using another connection?
> > [Wang, Quanxian] Yes. Other apps will use another connection. If they start
> another web page for that.
> > > That simply won't work, as you cannot integrate display elements
> > > from different clients. Even if the originating process is the same,
> > > a new connection is seen as a new client in the compositor, and so they are
> isolated.
> > [Wang, Quanxian] They should be isolated. I just provide the surface for user
> to do rendering. When client finished rendering, compositor will take the work
> and composite them. I will not care about the rest since app is just the client.
> 
> Okay, now I'm completely lost. It sounds like you are writing a compositor. I
> thought you were talking about one application, which is one Wayland client,
> and consists of webkit-efl with webGL capabilities.
[Wang, Quanxian] no, you are not lost. Low level compositor is weston. Window is created as a dummy to provide off-screen surface. The difference is the rendered surface will be located in web browser as a element in web page.
Webkit-efl is just a middleware which provide the interface for user to communicate with low level including libraries or device. For example, apps create egl surface through webkit-efl.
> 
> What I was talking about is that you cannot have one connection for webkit,
> another connection for webGL implementation, and assume that you can stitch
> together a web page with a webGL element in the middle. That won't work
> with a generic Wayland compositor.
> 
> Is your web browser actually an intermediate compositor?
[Wang, Quanxian] I think so.
> 
> Like this:
> 
> a Wayland compositor <- the browser as client,
[Wang, Quanxian] yes.
> 
> the browser as compositor <- multiple processes, one per webGL instance or
> browser tab or whatever
> 
> It seems I didn't understand your overall architecture. If it is something else
> than browser+webGL+everything as a single Wayland client in one process, you
> should definitely explain that on the mailing list.
[Wang, Quanxian] Generally architecture is browser(webapi)+webkit(including webgl)+EFL(Enlightenment Foundation Libraries)+compositor(weston/enlightment-X)+kernel
> 
> Or do you mean that your webGL thing will never display anything else than the
> webGL canvas: no other HTML elements, no window decorations?
> Do you even have any floating windows in your target system?
[Wang, Quanxian] All above are included.
> 
> 
> Thanks,
> pq