* [Buildroot] [PATCH] support/runtime-test: fix weston test
@ 2023-09-26 15:47 Yann E. MORIN
2023-09-30 9:00 ` Yann E. MORIN
2023-10-06 20:09 ` Julien Olivain
0 siblings, 2 replies; 3+ messages in thread
From: Yann E. MORIN @ 2023-09-26 15:47 UTC (permalink / raw)
To: buildroot; +Cc: Julien Olivain, Yann E. MORIN
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)
def stop_weston(self):
cmd = "killall weston && sleep 3"
--
2.25.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [Buildroot] [PATCH] support/runtime-test: fix weston test
2023-09-26 15:47 [Buildroot] [PATCH] support/runtime-test: fix weston test Yann E. MORIN
@ 2023-09-30 9:00 ` Yann E. MORIN
2023-10-06 20:09 ` Julien Olivain
1 sibling, 0 replies; 3+ messages in thread
From: Yann E. MORIN @ 2023-09-30 9:00 UTC (permalink / raw)
To: buildroot; +Cc: Julien Olivain
All,
On 2023-09-26 17:47 +0200, Yann E. MORIN spake thusly:
> 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>
Applied to master after fixing the typoes, thanks.
Regards,
Yann E. MORIN.
> ---
> 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)
>
> def stop_weston(self):
> cmd = "killall weston && sleep 3"
> --
> 2.25.1
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Buildroot] [PATCH] support/runtime-test: fix weston test
2023-09-26 15:47 [Buildroot] [PATCH] support/runtime-test: fix weston test Yann E. MORIN
2023-09-30 9:00 ` Yann E. MORIN
@ 2023-10-06 20:09 ` Julien Olivain
1 sibling, 0 replies; 3+ messages in thread
From: Julien Olivain @ 2023-10-06 20:09 UTC (permalink / raw)
To: Yann E. MORIN; +Cc: buildroot
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-10-06 20:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-09-26 15:47 [Buildroot] [PATCH] support/runtime-test: fix weston test Yann E. MORIN
2023-09-30 9:00 ` Yann E. MORIN
2023-10-06 20:09 ` Julien Olivain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox