wl_buffer is not released for long time.

[Sichem Zhou]

Hi,

Sorry for the trouble, I forgot to ask that is it safe to call
`wl_display_flush` and `wl_display_dispatch` in different threads?

Regards,
SZ


Le jeu. 15 mars 2018 11 h 17, Sichem Zhou <sichem.zh at gmail.com> a écrit :

> Hi,
>
> Thanks very much for the patience so far. It's because I didn't do
> `wl_display_flush` before polling.
>
> Regards,
> SZ
>
> Le jeu. 15 mars 2018 04 h 41, Pekka Paalanen <ppaalanen at gmail.com> a
> écrit :
>
>> On Thu, 15 Mar 2018 00:19:10 +0000
>> Sichem Zhou <sichem.zh at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180315/6cb2a032/attachment-0001.html>