How to enable Wayland when original software support X?

[Pekka Paalanen]

On Wed, 6 Feb 2013 02:07:56 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> Hi, All
> 
> I like to get some comment from you.
> 
> I am planning to enable wayland webgl support in webkit-efl. Basically they support X.
> With the update, I will not change the original mechanism and just
> translate X operation to wayland operation.

Hi,

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

> +        assert(g_nativeDisplay);
> +        struct wl_registry *registry = wl_display_get_registry(g_nativeDisplay);
> +        wl_registry_add_listener(registry, NULL, NULL);
> +        wl_display_dispatch(g_nativeDisplay);
> +        m_window = (void *)wl_egl_window_create(NULL, 1, 1);

I assume the assert() and NULLs and alike are just placeholders for real
code...

> +#else
> +        g_nativeDisplay = XOpenDisplay(0);
> +        g_nativeWindow = XCreateSimpleWindow(g_nativeDisplay, XDefaultRootWindow(g_nativeDisplay),
>                              0, 0, 1, 1, 0,
>                              BlackPixel(g_nativeDisplay, 0), WhitePixel(g_nativeDisplay, 0));
> +        XFlush(g_nativeDisplay);
> +#endif
> 
> Second part: create surface
> 
> +#if ENABLE(TIZEN_WAYLAND)
> +    m_window = (void *)wl_egl_window_create(NULL, 1, 1);
> +    m_surface = eglCreateWindowSurface(m_display, surfaceConfig, (struct wl_egl_window *)m_window, NULL);

...here, too.

> +#else
>      m_pixmapID = XCreatePixmap(g_nativeDisplay, g_nativeWindow, 1, 1, 32);
>      m_surface = eglCreatePixmapSurface(m_display, surfaceConfig, m_pixmapID, NULL);
> +#endif
> 
> Wayland has no pixmap and wl_egl_pixmap has been moved out from mesa and wayland.
> Therefore I have to use window to replace them.

Yeah, as far as I understand, since Wayland does not include any
server-side rendering in the protocol, there is no need for server-side
pixmaps either, hence they were removed. For off-screen rendering,
there are a few choices:
- use FBOs, possibly with
- the surfaceless EGL extension, or as a fallback
- a dummy wl_surface

All the above have drawbacks. I would imagine, that WebGL would benefit
a lot from sub-surfaces, but unfortunately that work is not in a usable
state yet.

> 
> Currently with testing, it is fine. However I am afraid I miss something unexpected.
> Need Wayland expert like you to have a review of them.
> 
> Any suggestion for that?

I'm not sure I saw a real question yet. Are you asking us to review the
placeholder code?


Thanks,
pq