How to create pixmap or pixmap surface in wayland?

[Wang, Quanxian]

Pq, thanks so much. It is very nice to get great suggestion.

> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> Sent: Friday, February 08, 2013 6:34 PM
> To: Wang, Quanxian
> Cc: wayland-devel at lists.freedesktop.org
> Subject: Re: How to create pixmap or pixmap surface in wayland?
> 
> On Fri, 8 Feb 2013 02:16:39 +0000
> "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
> 
> > Sorry Pq. I confused you so much.
> >
> > Just one requirement not related with architecture. You can imagine write a
> simple program for example glxgears. No compositor manager, no architecture,
> no window manager. Just has x server, or compositor server(weston).
> >
> > I want to call eglCreatePixmapSurface to create a pixmap surface. If the
> xserver is backend, I need to connect with X server and create a pixmap and
> then create the pixmap surface using egl interface provided by mesa.
> > If the backend is weston compositor, I need to connect with weston
> compositor and using egl to create the pixmap and its surface. Before that the
> context is created. Just like the code in simple-egl.c of weston.
> > ===
> > -- function init_egl()
> > ...
> >         display->egl.dpy = eglGetDisplay(display->display);
> >         assert(display->egl.dpy);
> >
> >         ret = eglInitialize(display->egl.dpy, &major, &minor);
> >         assert(ret == EGL_TRUE);
> >         ret = eglBindAPI(EGL_OPENGL_ES_API);
> >         assert(ret == EGL_TRUE);
> >
> >         ret = eglChooseConfig(display->egl.dpy, config_attribs,
> >                               &display->egl.conf, 1, &n);
> >         assert(ret && n == 1);
> >
> >         display->egl.ctx = eglCreateContext(display->egl.dpy,
> >                                             display->egl.conf,
> >                                             EGL_NO_CONTEXT,
> context_attribs);
> >         assert(display->egl.ctx);
> > ...
> > ===
> >
> > The current issue is pixmap of wayland is not supported in wayland protocol
> and mesa. I could not do this like X.
> >
> > Sorry my title and description make you confused, I change it to 'how to
> create pixmap or pixmap surface in wayland'.
> 
> Alright, thanks. Let's see.
> 
> First you need an EGL display. I would recommend to ask EFL or whatever is
> creating the "main" Wayland connection for its struct wl_display pointer, and
> pass that to eglGetDisplay(). This way you are not creating a new Wayland
> connection, and your program will behave as a single Wayland client in the
> compositor's perspective. This will let you take advantage of sub-surfaces[1] in
> the future, once we get them in a usable form.
> 
> I also assume there is no way to create an EGLDisplay without any window
> system connection. At least on a standard Linux system, I think you need to be
> authenticated in DRM, so ignoring the window system would not work.
> 
> Next you have to choose how get a render target. There are couple of
> options:
> A. use the surfaceless EGL extension, and use a FBO for the rendering B. create
> a dummy wl_surface, use it as the EGLSurface, and use FBO for
>    real rendering
> C. create a wl_subsurface, and just use it for rendering
> 
> In case A, depending on your EGL stack, you might not have the extension
> available. I think Mesa always has it, but others might not.
> 
> Both A and B require you to use FBOs. That may or may not be a problem,
> depending on how and what kind of an API you offer to e.g. webGL. If the
> webGL code does glBindFramebuffer(GL_FRAMEBUFFER, 0), can you intercept
> it and change it to activate your FBO?
> 
> The immediate downside of case C is that its not available just yet.
> However, it would have considerable benefits:
> - You get a real EGLSurface for rendering, no need for tricks with FBOs.
> - No need to read back the rendering in the client, i.e. no
>   glReadPixels or copying into the browser window image at client
>   side. The rendering will go directly to the compositor into the
>   sub-surface, and the compositor will combine it with the rest of your
>   browser graphics.
> - The sub-surface can use a different renderer than the main surface,
>   i.e. the sub-surface can be draw with GL and main surface in
>   software, or vice versa.
> - Even the compositor may avoid copying the sub-surface contents, as
>   the sub-surface might be assigned to a hardware overlay, that will
>   scan it out as is, without compositing.
> 
> With cases A and B, that is with FBO, you will render into a temporary buffer,
> and then you probably want to use that rendered image for something, most
> likely as a part of a web page your browser is rendering. So you either use
> glReadPixels (very slow) and draw the web page in software, or you can use the
> FBO render target as a texture, and draw the browser window in GL. After that,
> you send the image to the compositor for display.
> 
> As you see, the context and architecture information is quite essential to get a
> useful reply. You don't only want to create an off-screen rendering target, you
> will also want to use the result for something.
> How you want to use the result matters a great deal, especially for
> performance.
> 
> 
> Thanks,
> pq
> 
> [1]
> http://lists.freedesktop.org/archives/wayland-devel/2012-December/006844.h
> tml