How to create client in child thread

[Pekka Paalanen]

On Thu, 16 Jun 2016 09:54:54 +0800 (CST)
袁嘉伟 <yuanjw1025 at 163.com> wrote:

> Yes, I want to achieve that drawing the client from a thread but not
> the main thread. Before I have tested that creating display and
> drawing surface from main thread, and I try to call the
> functions(xdg_surface_xxxx) of wayland to control the client from
> child thread, but failed. The reason is function blocked. Through
> referring some websites, I thought  the drawing and control might be
> in the same thread. I continue to test that drawing the client in
> child thread, but it still block in function eglGetDisplay(&display).
> I don't know why. Because of HMI framework, I must call the function
> to control the client in child thread. My test code is sample-egl.c.
> Thanks.
> 
> 
> 
> 
> 在 2016-06-16 04:24:19，"Benoit Gschwind" <gschwind at gnu-log.net>
> 写道：
> >Hello,
> >
> >The reply from Pekka is about compositor using a client to make the
> >rendering, but I not sure this is what you asking for.
> >
> >Are you talking about building a compositor ? It look like you are
> >making a wayland client that try to delegate the drawing to a
> >thread. Is it what you want to do ?
> >
> >Best regards
> >

Oh indeed, sorry for my confusion. First, some general background
information:

eglSwapBuffers() counts as a Wayland protocol call, because it is
guaranteed to call wl_surface.commit before it returns and with the
newly rendered buffer attached, and it will also wait for
wl_buffer.release events if necessary, and by default it also waits for
wl_surface.frame callbacks to return.

Here is what I wrote about EGL elsewhere:

	eglSwapBuffers will be waiting for the previous eglSwapBuffers'
	frame callback and only if it has not arrived already for the
	particular surface. If you call eglSwapBuffers as a response to
	receiving your own copy of the frame callback or later,
	eglSwapBuffers will never block.

	To be more precise, wait for the frame callback happens on the
	eglSwapBuffers *after* the current one as I explained above,
	and waits for wl_buffer.releases happen at the first draw call
	that would need a buffer to draw into if necessary.

	Those are the two orthogonal throttling mechanisms in Mesa.
	Setting swap interval to 0 will prevent waits for the frame
	callbacks, but not for buffer releases, because Mesa does not
	want to potentially allocate an unlimited number of buffers in
	case the server is slow to send out releases (which would imply
	your whole system is already hosed anyway, so putting even more
	pressure to it would only make things worse).

The above describes the expected behaviour of EGL. Bugs, which we know
to be around, are another matter.

Do note, that I am only talking about Mesa and what a proper EGL
implementation would do. If you are using any properietary EGL
implementation, especially Vivante, you might be in trouble.

Other things you must take care of are:

- every thread where you want Wayland events dispatched must have its
  own wl_event_queue (Mesa EGL creates one for itself)

- you must use the wl_display_prepare_read() API of libwayland-client
  in all callers of libwayland-client properly

- Pay attention to all bugs linked from
  https://bugs.freedesktop.org/show_bug.cgi?id=91769 ,
  particularly https://bugs.freedesktop.org/show_bug.cgi?id=91273 which
  also requires a fix in the EGL implementation (for Mesa, see
  https://lists.freedesktop.org/archives/mesa-dev/2016-May/115617.html
  for a patch that does not seem to have been even merged yet).

In general, Wayland functions are *not* meant for controlling things
across thread boundaries. It is safe to send requests from multiple
threads, but you are still responsible for ordering them correctly
yourself in cases where the order matters.

If this gives you the impression that using threads with EGL/Wayland in
particular is rare and not really tested, you are right. I do not know
of any good code examples, maybe others have some?

You say you are blocked in eglGetDisplay(). I have not heard of that
before. Which EGL implementation is that? If it is not Mesa, and you
cannot reproduce the problem with Mesa, then I suspect you have to
contact your EGL vendor about it.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160616/5abadfb7/attachment-0001.sig>