<div dir="auto"><div>Hi,</div><div dir="auto"><br></div><div dir="auto">Thanks very much for the patience so far. It's because I didn't do `wl_display_flush` before polling.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">SZ</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">Le jeu. 15 mars 2018 04 h 41, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 15 Mar 2018 00:19:10 +0000<br>
Sichem Zhou <<a href="mailto:sichem.zh@gmail.com" target="_blank" rel="noreferrer">sichem.zh@gmail.com</a>> wrote:<br>
<br>
> Dear Pekka,<br>
><br>
> Thanks for your idea on this, I inserted a callback in the `surface_commit`<br>
> function in libweston. From the log I can see that the `surface commit` was<br>
> blocked on the server side until some other events happen. On the client<br>
> side it was clear that I committed two buffers then sleeped because of<br>
> lacking available buffers. I am using libweston and currently I didn't<br>
> setup any input callbacks. All I did was setting up an interface to set<br>
> views in background layers then call `wl_display_run()`. I hope to know is<br>
> there anyways to follow wayland server event queues in libweston?<br>
<br>
Hi,<br>
<br>
there is only one event queue in the server-side per client. IIRC, it's<br>
not really even a queue as much as just a buffer.<br>
<br>
You can use WAYLAND_DEBUG=server environment variable to have<br>
libwayland-server print all protocol messages at the time they are<br>
processed. That means, the time when requests are being dispatched, and<br>
events are being queued for sending. There is WAYLAND_DEBUG=client<br>
working the same way for clients, but it might be confusing if it is<br>
set for multiple clients at the same time.<br>
<br>
If you need to check the messages on "the wire" instead, the Wayland<br>
website extras have a list of some debugger programs. Messages enter<br>
the wire on flush after send. Forgetting to flush will show the message<br>
in WAYLAND_DEBUG=1 output, but it might not be actually sent at the<br>
time.<br>
<br>
This issue could also be a client bug. If you do not ensure that all<br>
requests have been flushed out before going to sleep in poll(), they<br>
might never actually reach the server until something else happens.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div></div></div>