How to enable Wayland when original software support X?

[Pekka Paalanen]

On Thu, 7 Feb 2013 03:30:48 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> 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.

Ok, that part was clear from the start.

> 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.

Yes, but that description does not answer to any of my confusion about
the architecture you want. How are all these things divided into
processes? How do these processes communicate?

> > 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.

So, your browser is actually a Wayland server towards its components
like webGL elements, and your browser is also a Wayland client towards
the session compositor (e.g. Weston)?

> > 
> > Like this:
> > 
> > a Wayland compositor <- the browser as client,
> [Wang, Quanxian] yes.

This was not an alternative, this just the first half of the
definition, and...

> > 
> > the browser as compositor <- multiple processes, one per webGL instance or
> > browser tab or whatever

..this is the second half. They go together, in the way I said
further above.

> > 
> > 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
> > 

Certainly all of those are not in the same process. The kernel does not
even belong to the definition, it's the kernel. The compositor there has
its own process, unless your browser is a Weston plugin.

> > 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.

We seem to be speaking totally different languages.

When I say "compositor", I mean a program running in its own process,
that acts as a Wayland server. Other processes that are Wayland
clients, can connect to the Wayland server using the Wayland protocol.
The point here is that compositor is a separate process, and there is
the Wayland protocol used to communicate with it.

Could you re-think the whole thing, what you want to ask, and write it
again from the start? I can't really understand what you are doing, nor
what you are asking about.

A big problem in commenting about the pseudo-code you had in your first
email is that we have no idea about its context. Is it run exactly once
when the browser starts? Is webkit-efl creating its own connection to
the Wayland server in addition to this? Does it run every time a new
webGL element appears? ...

I would also suggest to use descriptively named variables instead of
just NULL in pseudo-code examples, so that we see it is just a
placeholder word for something real, and not literally NULL.


Sorry,
pq