weston 13.0.1 assert fail #scarthgap

weston 13.0.1 assert fail #scarthgap

[Jarno]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Hello,

anybody willing to share guidance or solution to overcome known (?) bug on weston crash. I'm able to get weston up and running but when ever moving mouse weston crashes. From gdb stack:

#5  0x0000007f9ac35624 in __assert_fail
(assertion=assertion@entry=0x7f99eff420 "fb", file=file@entry=0x7f99efead0 "/usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c", line=line@entry=506, function=function@entry=0x7f99f00ab0 <__PRETTY_FUNCTION__.5> "drm_output_find_plane_for_view") at assert.c:105
#6  0x0000007f99ef784c in drm_output_find_plane_for_view
(current_lowest_zpos=18446744073709551615, scanout_state=0x0, mode=DRM_OUTPUT_PROPOSE_STATE_PLANES_ONLY, pnode=0x55b20579b0, state=0x55b1f3d0e0)
at /usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c:506

[-- Attachment #2: Type: text/html, Size: 976 bytes --]

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Gyorgy Sarvari]

On 11/19/25 14:52, Jarno via lists.yoctoproject.org wrote:
> Hello,
>  
> anybody willing to share guidance or solution to overcome known (?)
> bug on weston crash. I'm able to get weston up and running but when
> ever moving mouse weston crashes. From gdb stack:
>  
> #5  0x0000007f9ac35624 in __assert_fail
>     (assertion=assertion@entry=0x7f99eff420 "fb",
> file=file@entry=0x7f99efead0
> "/usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c",
> line=line@entry=506, function=function@entry=0x7f99f00ab0
> <__PRETTY_FUNCTION__.5> "drm_output_find_plane_for_view") at assert.c:105
> #6  0x0000007f99ef784c in drm_output_find_plane_for_view
>     (current_lowest_zpos=18446744073709551615, scanout_state=0x0,
> mode=DRM_OUTPUT_PROPOSE_STATE_PLANES_ONLY, pnode=0x55b20579b0,
> state=0x55b1f3d0e0)
>     at
> /usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c:506
>  
>

How to reproduce this? Is it platform/layer dependent?
I just compiled a core-image-weston from Scarthgap, it didn't crash with
qemux86-64 at least.

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Jarno]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

there's a issue at github where's detailed istructions how to reproduce it.
https://github.com/agherzan/meta-raspberrypi/issues/1407

I'm working on raspberrypi4-64, and my layer/recipes based on core-image-weston. I had this previously working but stopped working due to recent update.

[-- Attachment #2: Type: text/html, Size: 443 bytes --]

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Gyorgy Sarvari]

On 11/20/25 10:21, Jarno via Lists.Yoctoproject.Org wrote:
> there's a issue at github where's detailed istructions how to
> reproduce it.
> https://github.com/agherzan/meta-raspberrypi/issues/1407
>  
> I'm working on raspberrypi4-64, and my layer/recipes based on
> core-image-weston. I had this previously working but stopped working
> due to recent update.

I have opened a PR[1] for this. If you could test it, it would be really
nice of you.

[1]: https://github.com/agherzan/meta-raspberrypi/pull/1548

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Jarno]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]

Hey yes of course i will. Being quite novice could you tell me how to test, thank you.

So far i did bitbake -c cleanall weston && bitbake <my image> and still have the same behaviour.

[-- Attachment #2: Type: text/html, Size: 279 bytes --]

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Gyorgy Sarvari]

On 11/24/25 15:15, Jarno via lists.yoctoproject.org wrote:
> Hey yes of course i will. Being quite novice could you tell me how to
> test, thank you.
>  
> So far i did bitbake -c cleanall weston && bitbake <my image> and
> still have the same behaviour.
>  

That supposed to be enough, after pulling the latest version of the
scarthgap branch of meta-raspberrypi. Which revision are you using now?
It should be 5240b5c200e594b494a7f1a8f9d81e7c09bc8939.

Otherwise, if you are already using this revision, what is the output of
"MACHINE=${YOUR_MACHINE_NAME} bitbake -e weston | grep ^SRC_URI"
command? Does it contain the newly added patch? (Currently the patch
should be applied automatically for rpi machines, but if you are using a
custom derivative, it might not be present, depending on how you
configured it)

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Jarno]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

git rev-parse HEAD
5240b5c200e594b494a7f1a8f9d81e7c09bc8939

MACHINE=raspberrypi4-64 bitbake -e weston | grep ^SRC_URI
SRC_URI="file://0001-libweston-tools-Include-libgen.h-for-basename-signat.patch file://0001-vnc-Allow-neatvnc-in-version-0.8.0.patch file://weston.png file://weston.desktop file://xwayland.weston-start file://systemd-notify.weston-start file://0001-Adapt-weston-to-64-bit-plane-IDs.patch"

After build and flash same behaviour persist.

core dump:

#4  0x0000007f93ba55a0 in __assert_fail_base
(fmt=0x7f93cbdb70 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f92e6f420 "fb", file=file@entry=0x7f92e6ead0 "/usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c", line=line@entry=506, function=function@entry=0x7f92e70ab0 <__PRETTY_FUNCTION__.5> "drm_output_find_plane_for_view") at assert.c:96
#5  0x0000007f93ba5624 in __assert_fail
(assertion=assertion@entry=0x7f92e6f420 "fb", file=file@entry=0x7f92e6ead0 "/usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c", line=line@entry=506, function=function@entry=0x7f92e70ab0 <__PRETTY_FUNCTION__.5> "drm_output_find_plane_for_view") at assert.c:105
#6  0x0000007f92e6784c in drm_output_find_plane_for_view
(current_lowest_zpos=18446744073709551615, scanout_state=0x0, mode=DRM_OUTPUT_PROPOSE_STATE_PLANES_ONLY, pnode=0x55812dab90, state=0x558137fc70) at /usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c:506

[-- Attachment #2: Type: text/html, Size: 1733 bytes --]

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Gyorgy Sarvari]

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

On 11/25/25 16:39, Jarno via Lists.Yoctoproject.Org wrote:
> git rev-parse HEAD
> 5240b5c200e594b494a7f1a8f9d81e7c09bc8939
>  
> MACHINE=raspberrypi4-64 bitbake -e weston | grep ^SRC_URI
> SRC_URI="file://0001-libweston-tools-Include-libgen.h-for-basename-signat.patch
> file://0001-vnc-Allow-neatvnc-in-version-0.8.0.patch file://weston.png
> file://weston.desktop file://xwayland.weston-start
> file://systemd-notify.weston-start
> file://0001-Adapt-weston-to-64-bit-plane-IDs.patch"
>  
> After build and flash same behaviour persist.

Hmmm... this is strange, I tested using the same hw (rpi4-64) with the
same revision, and just verified the patch again earlier today with both
6.6 and 6.12 kernels.

I have attached another patch, which is similar to the one in the
repository. You can just overwrite
0001-Adapt-weston-to-64-bit-plane-IDs.patch in meta-raspberrypi with
this (as a test, revert it afterwards), and build a new image. 

Does it crash also?

If yes, do you get the same backtrace, or is it different?


>  
> core dump:
>  
> #4  0x0000007f93ba55a0 in __assert_fail_base
>     (fmt=0x7f93cbdb70 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f92e6f420 "fb",
> file=file@entry=0x7f92e6ead0
> "/usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c",
> line=line@entry=506, function=function@entry=0x7f92e70ab0
> <__PRETTY_FUNCTION__.5> "drm_output_find_plane_for_view") at assert.c:96
> #5  0x0000007f93ba5624 in __assert_fail
>     (assertion=assertion@entry=0x7f92e6f420 "fb",
> file=file@entry=0x7f92e6ead0
> "/usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c",
> line=line@entry=506, function=function@entry=0x7f92e70ab0
> <__PRETTY_FUNCTION__.5> "drm_output_find_plane_for_view") at assert.c:105
> #6  0x0000007f92e6784c in drm_output_find_plane_for_view
>     (current_lowest_zpos=18446744073709551615, scanout_state=0x0,
> mode=DRM_OUTPUT_PROPOSE_STATE_PLANES_ONLY, pnode=0x55812dab90,
> state=0x558137fc70) at
> /usr/src/debug/weston/13.0.1/libweston/backend-drm/state-propose.c:506
>  
>  

[-- Attachment #2: 0001-Adapt-weston-to-64-bit-plane-IDs.patch --]
[-- Type: text/x-patch, Size: 4449 bytes --]

From b66f14a812c96b92a83cec4bb637c1b982168d24 Mon Sep 17 00:00:00 2001
From: Gyorgy Sarvari <skandigraun@gmail.com>
Date: Sat, 22 Nov 2025 09:00:39 +0100
Subject: [PATCH] backend-drm: support 64-bit plane_mask

This change was prompted by a recent change in the Raspberry Pi
kernel[1], which has changed the plane_mask width to 64-bit in
their drm driver. Due to this weston behaved in an erratic way
on Raspberry Pi devices - usually this manifested in a crash
immediatelly when the mouse is moved (which was worked around
since by removing a failing assert[2]).

This change adapts libweston to accept 64-bit wide plane masks.

NB: the mentioned kernel change seems to be Raspberry Pi specific,
and there are no signs of it being mainlined.

[1]: https://github.com/raspberrypi/linux/commit/8181e682d6f4ef209845ec24f0a1eb37764d6731
[2]: https://gitlab.freedesktop.org/wayland/weston/-/issues/1039

Upstream-Status: Pending

Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
---
 libweston/backend-drm/drm-internal.h  |  2 +-
 libweston/backend-drm/drm.c           |  4 ++++
 libweston/backend-drm/fb.c            |  2 +-
 libweston/backend-drm/state-propose.c | 10 +++++-----
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/libweston/backend-drm/drm-internal.h b/libweston/backend-drm/drm-internal.h
index e008a8d1..305abbce 100644
--- a/libweston/backend-drm/drm-internal.h
+++ b/libweston/backend-drm/drm-internal.h
@@ -410,7 +410,7 @@ struct drm_fb {
 	int width, height;
 	int fd;
 
-	uint32_t plane_mask;
+	uint64_t plane_mask;
 
 	/* Used by gbm fbs */
 	struct gbm_bo *bo;
diff --git a/libweston/backend-drm/fb.c b/libweston/backend-drm/fb.c
index 350aaf60..7baaa1b9 100644
--- a/libweston/backend-drm/fb.c
+++ b/libweston/backend-drm/fb.c
@@ -760,7 +760,7 @@ drm_fb_get_from_paint_node(struct drm_output_state *state,
 			continue;
 
 		if (drm_fb_compatible_with_plane(fb, plane))
-			fb->plane_mask |= 1 << (plane->plane_idx);
+			fb->plane_mask |= 1UL << (plane->plane_idx);
 	}
 	if (fb->plane_mask == 0) {
 		drm_fb_unref(fb);
--- ./libweston/backend-drm/state-propose.c.oeig	2025-11-25 12:49:15.280259892 +0100
+++ ./libweston/backend-drm/state-propose.c	2025-11-25 12:50:08.247823256 +0100
@@ -393,7 +393,7 @@
 	struct drm_fb *fb = NULL;
 
 	bool view_matches_entire_output, scanout_has_view_assigned;
-	uint32_t possible_plane_mask = 0;
+	uint64_t possible_plane_mask = 0;
 
 	pnode->try_view_on_plane_failure_reasons = FAILURE_REASONS_NONE;
 
@@ -437,7 +437,7 @@
 			return NULL;
 		}
 
-		possible_plane_mask = (1 << output->cursor_plane->plane_idx);
+		possible_plane_mask = (1UL << output->cursor_plane->plane_idx);
 	} else {
 		if (mode == DRM_OUTPUT_PROPOSE_STATE_RENDERER_ONLY) {
 			drm_debug(b, "\t\t\t\t[view] not assigning view %p "
@@ -450,7 +450,7 @@
 				continue;
 
 			if (drm_paint_node_transform_supported(pnode, plane))
-				possible_plane_mask |= 1 << plane->plane_idx;
+				possible_plane_mask |= 1UL << plane->plane_idx;
 		}
 
 		if (!possible_plane_mask) {
@@ -483,10 +483,10 @@
 		if (possible_plane_mask == 0)
 			break;
 
-		if (!(possible_plane_mask & (1 << plane->plane_idx)))
+		if (!(possible_plane_mask & (1UL << plane->plane_idx)))
 			continue;
 
-		possible_plane_mask &= ~(1 << plane->plane_idx);
+		possible_plane_mask &= ~(1UL << plane->plane_idx);
 
 		switch (plane->type) {
 		case WDRM_PLANE_TYPE_CURSOR:
--- ./libweston/backend-drm/state-propose.c.orig	2025-11-25 13:26:58.173810837 +0100
+++ ./libweston/backend-drm/state-propose.c	2025-11-25 13:28:21.576255290 +0100
@@ -43,6 +43,8 @@
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf-unstable-v1-server-protocol.h"
 
+#define MAX_PLANE_NR 64
+
 enum drm_output_propose_state_mode {
 	DRM_OUTPUT_PROPOSE_STATE_MIXED, /**< mix renderer & planes */
 	DRM_OUTPUT_PROPOSE_STATE_RENDERER_ONLY, /**< only assign to renderer & cursor */
@@ -395,6 +397,8 @@
 	bool view_matches_entire_output, scanout_has_view_assigned;
 	uint64_t possible_plane_mask = 0;
 
+	assert(output->cursor_plane->plane_idx < MAX_PLANE_NR);
+
 	pnode->try_view_on_plane_failure_reasons = FAILURE_REASONS_NONE;
 
 	/* check view for valid buffer, doesn't make sense to even try */
@@ -449,6 +453,7 @@
 			if (plane->type == WDRM_PLANE_TYPE_CURSOR)
 				continue;
 
+			assert(plane->plane_idx < MAX_PLANE_NR);
 			if (drm_paint_node_transform_supported(pnode, plane))
 				possible_plane_mask |= 1UL << plane->plane_idx;
 		}

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Jarno]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

have spend the whole day on this subject. I did try with the patch provided (thank you) and no luck. After spending some time debugging until frustration with chaptgpt i did what i should have done much earlier: start new project and build "core-image-weston", well it did not crash. I'll try to find the reason and post it here.

[-- Attachment #2: Type: text/html, Size: 342 bytes --]

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Jarno]

[-- Attachment #1: Type: text/plain, Size: 55 bytes --]

how to compare kernel settings of two yocto projects?

[-- Attachment #2: Type: text/html, Size: 66 bytes --]

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Jarno]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

as stated earlier i'm still a novice and this took me a while to solve. There was a devtool created layer which had weston_13.0.1.bbappend deleting it and rebuild i got this working with '0001-Adapt-weston-to-64-bit-plane-IDs.patch' than you Gyorgy Sarvari.

[-- Attachment #2: Type: text/html, Size: 396 bytes --]

Re: [yocto] weston 13.0.1 assert fail #scarthgap

[Gyorgy Sarvari]

On 11/27/25 20:52, Jarno via lists.yoctoproject.org wrote:
> as stated earlier i'm still a novice and this took me a while to
> solve. There was a devtool created layer which had
> weston_13.0.1.bbappend deleting it and rebuild i got this working with
> '0001-Adapt-weston-to-64-bit-plane-IDs.patch' than you Gyorgy Sarvari._
> _

Happy to hear, thanks for the feedback.