Re: [Buildroot] [PATCH] support/runtime-test: fix weston test

[Julien Olivain <ju.o@free.fr>]

Hi Yann,

On 26/09/2023 17:47, Yann E. MORIN wrote:
> The weston runtime test uses the CRC of the framebuffer to detect that
> "something" is being drawned on the framebuffer. This requires that the
> sampling of the CRC happens does not happen too early after trigerring
> an action, or the rendering may be not be finishe, either:
> 
>   - weston may not have had time to initialise, or
>   - the test application may not have started rednering,
> 
> The sequence of rendering that has been observed yields this sequence 
> of
> CRCs (elided for brevity):
> 
>   - boot:
>     - alternating between 0x4c4126bf and 0x5d2f9aa5: console cursor
>       blinking
> 
>   - start weston:
>     - 0x4c4126bf: weston switches to an clearted vt)
>       ...
>     - 0xe54b7895: weston is starting
>       ...
>     - 0xe54b7895: wayland socket appears!
>       ...
>     - 0x6bf28bdf: weston is ready
>       ...
> 
>   - start weston-simple-egl:
>     - 0x6bf28bdf: application is starting
>       ...
>     - 0xNNNNNNNN: random CRCs while the application renders
>       ...
> 
>   - stop weston-simple-egl:
>     - 0xNNNNNNNN: izero, one, or two random CRCs while the application
>         renders before it handles SIGTERM
>     - 0x6bf28bdf: application is stopped
>       ...
> 
>   - stop weston:
>     - 0x6bf28bdf: a few CRC identical to when weston was started, while
>         weston is processing SIGTERM
>     - ocillating between 0x4c4126bf and 0x5d2f9aa5: console cursor
>         blinking, back to initial vt, weston dead.
> 
> So, we need to wait "enough" after each action. Moreover, when the
> wayland socket appears, weston may not have stabilised yet, so we also
> need to wait after the socket appears.
> 
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Julien Olivain <ju.o@free.fr>
> ---
>  support/testing/tests/package/test_weston.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/support/testing/tests/package/test_weston.py 
> b/support/testing/tests/package/test_weston.py
> index 276788c649..df1b7a4135 100644
> --- a/support/testing/tests/package/test_weston.py
> +++ b/support/testing/tests/package/test_weston.py
> @@ -78,6 +78,7 @@ class TestWeston(infra.basetest.BRTest):
>          wayland_socket = "${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}"
>          cmd = f"while [ ! -e \"{wayland_socket}\" ] ; do sleep 1 ; 
> done"
>          self.assertRunOk(cmd, timeout=10)
> +        time.sleep(4)

I was wondering if it would be relevant to add a BRTest.sleep() method
for sleeping on the host test controller, that would adjust the sleep
time with BRTest.timeout_multiplier.

Since those sleep times are meant to adjust the host test controller
with emulator execution speed, I believe it would also make sense to
multiply those sleep time as same as timeout_multiplier for pexect
timeouts. (Maybe timeout_multiplier will need to be renamed to
something else like speed_multiplier).

What do you think?

> 
>      def stop_weston(self):
>          cmd = "killall weston && sleep 3"
> --
> 2.25.1

Best regards,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot