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@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
