Latest flutter-auto crashes on rcar3 platforms

Description

As reported by this morning, and confirmed locally, trying to run Flutter apps with agl-ivi-demo-platform on a rcar3 platform like the AGL reference hardware currently fails.  Here's the log:

What I think has happened is that the rcar3 testing that was done last week by myself was with Joel's first meta-flutter bump plus 's patch.  When Joel bumped meta-flutter a second time and the commit message mentioned the EGL 1.4 fix, I did not think to retest on rcar3 locally.  However, that bump included a flutter-auto SRCREV update that included not only Joel's pick of Yamaguchi-san's fix, but several other changes from to update the agl-shell protocol support in flutter-auto.  The issue seems to be in one of those changes, as tweaking the flutter-auto SRCREV backwards locally and applying Yamaguchi-san's change on top results in things working again.  I will upload a change to Gerrit along those lines as a proposed fix to allow shipping Pike M1.

Environment

None

Attachments

1

Activity

Walt Miner 
June 23, 2023 at 1:54 PM

Close fo Pike M1

Marius Vlad 
June 19, 2023 at 9:12 AM

We have a temporary fix from the compositor and two hot-fixes added.

Marius Vlad 
June 19, 2023 at 9:12 AM

Fyi with https://gerrit.automotivelinux.org/gerrit/c/src/agl-compositor/+/29012 in place this won't show up as an issue, as already noticed, but note that the shell client would take output dimensions into account while computing the activation area in the ini configuration file means it would only match a 1080p display resolution. A larger display would show other bits under.

Marius Vlad 
June 19, 2023 at 9:06 AM

Pushed an fix upstream and added as a patch in https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-devel/+/29031 until upstream picks that up and does a meta-flutter update.

Marius Vlad 
June 16, 2023 at 8:34 PM

I sort of suspect this is related to multiple outputs, but I'll need to confirm first and I'll open a new jira ticket to handle that separately. We trip it over it just now, as we never relied on grabbing any output data (by that I mean the code in the embedder). As odd as this sounds, the embedder didn't made use of the output data until now. I think the code picks on the wrong output, rather than the where the embedder is at that moment, resulting in sending invalid data. We use ints in the protocol but uints in the code, hence negative values. This is a just a side-effect there's nothing particular to r-car3 other than ref-hw has two outputs, one of them being disconnected.

If that bump fixes the issue then I think we're fine until I submit a change ivi-homescreen side for Joel to pick-up it and do another meta-flutter update.

Fixed

Details

Assignee

Reporter

Fix versions

Labels

Contract ID

Components

Priority

Created June 15, 2023 at 10:52 PM
Updated June 23, 2023 at 1:54 PM
Resolved June 19, 2023 at 9:12 AM