Pq, thanks so much. It is very nice to get great suggestion.
-Original Message-
From: Pekka Paalanen [mailto:ppaala...@gmail.com]
Sent: Friday, February 08, 2013 6:34 PM
To: Wang, Quanxian
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: How to create pixmap or pixmap surface in wayland?
On Fri, 8 Feb 2013 02:16:39 +
Wang, Quanxian quanxian.w...@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
