On Thu, 15 Mar 2018 00:19:10 +0000 Sichem Zhou <sichem...@gmail.com> wrote:
> Dear Pekka, > > Thanks for your idea on this, I inserted a callback in the `surface_commit` > function in libweston. From the log I can see that the `surface commit` was > blocked on the server side until some other events happen. On the client > side it was clear that I committed two buffers then sleeped because of > lacking available buffers. I am using libweston and currently I didn't > setup any input callbacks. All I did was setting up an interface to set > views in background layers then call `wl_display_run()`. I hope to know is > there anyways to follow wayland server event queues in libweston? Hi, there is only one event queue in the server-side per client. IIRC, it's not really even a queue as much as just a buffer. You can use WAYLAND_DEBUG=server environment variable to have libwayland-server print all protocol messages at the time they are processed. That means, the time when requests are being dispatched, and events are being queued for sending. There is WAYLAND_DEBUG=client working the same way for clients, but it might be confusing if it is set for multiple clients at the same time. If you need to check the messages on "the wire" instead, the Wayland website extras have a list of some debugger programs. Messages enter the wire on flush after send. Forgetting to flush will show the message in WAYLAND_DEBUG=1 output, but it might not be actually sent at the time. This issue could also be a client bug. If you do not ensure that all requests have been flushed out before going to sleep in poll(), they might never actually reach the server until something else happens. Thanks, pq
pgpd0I94raUMW.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
