On Thu, 5 Oct 2023 13:28:57 +0300
Pekka Paalanen wrote:
> ...
> If you flush the Wayland connection explicitly, you should be able to
> reliably avoid the deadlocks. Flushing is public stable API.
Thanks!
I will pattern these tests after the fd_passer display-test, since that
is constructed to
On Wed, 4 Oct 2023 11:09:42 -0400
jleivent wrote:
> On Wed, 4 Oct 2023 11:26:02 +0300
> Pekka Paalanen wrote:
>
> > ...
> > For the forked clients, there is stop_display()/display_resume().
> > Maybe that helps?
>
> Maybe if I understand their usage correctly. Is this right?: A client
> wou
On Wed, 4 Oct 2023 11:26:02 +0300
Pekka Paalanen wrote:
> ...
> For the forked clients, there is stop_display()/display_resume().
> Maybe that helps?
Maybe if I understand their usage correctly. Is this right?: A client
would send a sequence of requests followed by a stop_display request.
Anyth
On Tue, 3 Oct 2023 14:46:14 -0400
jleivent wrote:
> I am trying to write some tests that provoke errors in libwayland, but
> it doesn't seem to me like the existing test suite provides a mechanism
> to create specific event orderings that are allowed but not guaranteed
> by the asynchrony of the
I am trying to write some tests that provoke errors in libwayland, but
it doesn't seem to me like the existing test suite provides a mechanism
to create specific event orderings that are allowed but not guaranteed
by the asynchrony of the protocol. Is that correct? It looks to me
like the tests i
