Wayland Message Behaviour

[Derek Foreman]

On 2017-11-08 10:02 AM, Turner, LewisX wrote:
> Hi all,
> I have come across some strange behavior with Wayland and I wondered if 
> you could share your thoughts on it.
> The trace below is a sanitized version of what I captured of the 
> behavior of Wayland messages between our client and Weston. Towards the 
> end of the trace, we see an encoded buffer handle message sent out once 
> but for some reason the client ends up receiving this message twice. At 
> this point, the bridge between Weston and the client is broken and 
> although both can send messages to each other, the messages themselves 
> are never getting to their destinations.
> We only see this after calling wl_client_flush() within Weston 

Probably a silly question, but have you added a thread to weston?  If 
you call wl_client_flush() from a thread it could occasionally interrupt 
weston's own wl_client_flush() and the same events would be sent twice 
(without showing up in the log as being sent twice).

> immediately after sending a message to a client. On top of this, the 
> client can run at 60FPS for anywhere between 2-30 seconds before 
> encountering it. The wl_client_flush() is called immediately after the 
> call to encoded_buffer_handle() on every frame. There is no obvious 
> difference between the frame on which the issue occurs and the other 
> frames that work fine.
> [472508.841]  -> hmi at 3.encoded_buffer_handle(10, 2073600, 409148, 8, 
> 3559793324)
> [472509.269] hmi @3.encoded_buffer_handle(10, 2073600, 409148, 8, 
> 3559793324)
> [472517.952]  -> hmi @3.release_buffer_handle(8, 0, 1)
> [472518.146] hmi @3.release_buffer_handle(8, 0, 1)
> [473005.451]  -> hmi @3.encoded_buffer_handle(10, 2073600, 427086, 8, 
> 3559838348)
> [473005.848] hmi @3.encoded_buffer_handle(10, 2073600, 427086, 8, 
> 3559838348)
> [473014.914]  -> hmi @3.release_buffer_handle(8, 0, 1)
> [473015.112] hmi @3.release_buffer_handle(8, 0, 1)
> [473505.149]  -> hmi @3.encoded_buffer_handle(10, 2073600, 558179, 8, 
> 3559883345)
> [473506.794] hmi @3.encoded_buffer_handle(10, 2073600, 558179, 8, 
> 3559883345)
> [473517.277]  -> hmi @3.release_buffer_handle(8, 0, 1)
> [473517.427] hmi @3.release_buffer_handle(8, 0, 1)
> [473517.524] hmi @3.encoded_buffer_handle(10, 2073600, 558179, 8, 
> 3559883345)
> [474002.087]  -> hmi @3.encoded_buffer_handle(10, 2073600, 400377, 8, 
> 3559928007)
> [474507.144]  -> hmi @3.encoded_buffer_handle(7, 2073600, 391711, 4, 
> 3559972997)
> [475002.930]  -> hmi @3.encoded_buffer_handle(11, 2073600, 399621, 5, 
> 3560018014)
> [475503.604]  -> hmi @3.encoded_buffer_handle(12, 2073600, 408610, 6, 
> 3560063010)
> [476002.867]  -> hmi @3.encoded_buffer_handle(13, 2073600, 422290, 7, 
> 3560107997)
> Also, when this happens it’s worth nothing that wl_display_roundtrip() 
> reports an error, and wl_display_get_error() returns an error code. The 
> documentation online suggests errors here are fatal and we cannot use 
> the display again.
> Also note that commenting out the call to wl_client_flush() makes the 
> issue go away. However, we then see an unacceptable delay before the 
> event is received on the client side.

I've seen client side stalls related to libraries dispatching their own 
queues, which reads everything from the wayland connection into a buffer 
so the file descriptor is no longer flagged readable upon entering 
select().  (mesa does this, it's perfectly acceptable library behavior)

That would be easily fixed by calling wl_display_dispatch_pending() 
before calling select() in the client.

> The main question at this point is whether anyone else has seen similar 
> behavior. We do not want to spend more time investigating this if the 
> cause is a known issue.

Never seen anything quite like this, no.  I don't think you're seeing a 
known bug.

strace might be useful in determining if you're actually seeing the 
compositor send the event twice (and determine if it's twice from the 
same write vs two independent writes), as well as seeing if the client 
received it twice or processed it twice...

> Regards,
> Lewis

Good luck,
Derek

> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>