<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Exchange Server">  <style></style> </head> <body> <font face="Calibri" size="2"><span style="font-size:11pt;"> <div>Hi all,</div> <div> </div> <div>I have come across some strange behavior with Wayland and I wondered if you could share your thoughts on it.</div> <div> </div> <div>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.</div> <div> </div> <div>We only see this after calling wl_client_flush() within Weston 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.</div> <div> </div> <div>[472508.841] -> hmi@3.encoded_buffer_handle(10, 2073600, 409148, 8, 3559793324)</div> <div>[472509.269] hmi @3.encoded_buffer_handle(10, 2073600, 409148, 8, 3559793324)</div> <div>[472517.952] -> hmi @3.release_buffer_handle(8, 0, 1)</div> <div>[472518.146] hmi @3.release_buffer_handle(8, 0, 1)</div> <div>[473005.451] -> hmi @3.encoded_buffer_handle(10, 2073600, 427086, 8, 3559838348)</div> <div>[473005.848] hmi @3.encoded_buffer_handle(10, 2073600, 427086, 8, 3559838348)</div> <div>[473014.914] -> hmi @3.release_buffer_handle(8, 0, 1)</div> <div>[473015.112] hmi @3.release_buffer_handle(8, 0, 1)</div> <div>[473505.149] -> hmi @3.encoded_buffer_handle(10, 2073600, 558179, 8, 3559883345)</div> <div>[473506.794] hmi @3.encoded_buffer_handle(10, 2073600, 558179, 8, 3559883345)</div> <div>[473517.277] -> hmi @3.release_buffer_handle(8, 0, 1)</div> <div>[473517.427] hmi @3.release_buffer_handle(8, 0, 1)</div> <div>[473517.524] hmi @3.encoded_buffer_handle(10, 2073600, 558179, 8, 3559883345)</div> <div>[474002.087] -> hmi @3.encoded_buffer_handle(10, 2073600, 400377, 8, 3559928007)</div> <div>[474507.144] -> hmi @3.encoded_buffer_handle(7, 2073600, 391711, 4, 3559972997)</div> <div>[475002.930] -> hmi @3.encoded_buffer_handle(11, 2073600, 399621, 5, 3560018014)</div> <div>[475503.604] -> hmi @3.encoded_buffer_handle(12, 2073600, 408610, 6, 3560063010)</div> <div>[476002.867] -> hmi @3.encoded_buffer_handle(13, 2073600, 422290, 7, 3560107997)</div> <div> </div> <div>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.</div> <div> </div> <div>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.</div> <div> </div> <div>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.</div> <div> </div> <div>Regards,</div> <div>Lewis</div> <div> </div> </span></font> <p><font style="font-size: 9px;">Intel Deutschland GmbH<br> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany<br> Tel: +49 89 99 8853-0, www.intel.de<br> Managing Directors: Christin Eisenschmid, Christian Lamprechter<br> Chairperson of the Supervisory Board: Nicole Lau<br> Registered Office: Munich<br> Commercial Register: Amtsgericht Muenchen HRB 186928</font><br> </p> </body> </html>