Re: 'Merry' Magic Marlin Milestone 1 (v12.91.0) release

["Scott Murray" <scott.murray@xxxxxxxxxxxx>]

On Mon, 17 Jan 2022, Jan-Simon Moeller wrote:

> Hi Vasyl,
>
> Thanks for sharing this release. I have checked it out and collected
> > some comments. Will appreciate your help.
>
> > I have noticed AGL MM milestone 1 misses agl-cluster-demo-platform
> > image. We need it to demo our dual-linux use-case. Do you plan to
> > recover it?
>
> The agl-cluster-demo-platform is replaced with the work of the IC-EG .
> I'm sure the app itself can be ported with a bit of effort to not use the
> old appfw.
> Then we could restore it. As usual, patches welcome.

As Walt has said a few times on calls, Marlin is an interim release, so
not everything that works in Lamprey is necessarily going to be available,
and sticking with Lamprey may be better for the purpose of demoing some
things.  That said, working out what to do with the existing cluster demo
is on my TODO list, as it demos things that the WIP IC EG container-based
demo does not.

> > We need cluster-dashboard and IVI dashboard read data from CAN to demo
> > virtio-can, but this feature is gone at the moment. Scott mentioned
> > Eclipse KUKSA, what about ETA? How about patching those apps to read
> > from CAN using sockets temporarely, is it hard? Is it suitable for AGL
> > at least temporary?
>
> This is still in early stages and right now you'd just use plain socketcan.
> The discussion is happening in the Appfw and Connectivity EG calls.
> Your input and use-cases are highly welcome there.

My somewhat loose plan is to replace signal composer usage with kuksa.val.
Given the cluster demo dashboard app shares vehicle signal code with some
of the other Qt demo apps via libqtappfw, my thinking was to leverage
that if we try to get the cluster demo working in the Marlin timeframe,
as I should have code in hand from the dashboard app.  My expected
timeframe for getting to this is within the next month, and it's possible
it comes in 13.0.1 and not the initial Marlin release.  If for some
reason you need to demo something on Marlin today, then the best I can
say is to try hacking in direct SocketCAN use.  I'd somewhat prefer
people not rush ahead and do this with an eye on getting it merged since
it's not really what I think we want to maintain upstream going forward.
I would recommend joining the connectivity EG calls if you want to provide
input on this.

> > At the moment I am working on using virtio-gpu for IVI-to-IC display. I
> > have noticed that there is tbtnavi application which can be used to demo
> > IVI-to-IC display. But how tbtnavi supposed to work without old
> > application framework?
>
> tbtnavi is internally a gstreamer recorder pipeline. It should not be hard
> to convert it to not use the appfw.

This is not quite correct.  The tbtnavi app renders the map display that
gets sent to the cluster by the weston remote display gstreamer stuff.
Getting the app itself to build and run without the app framework isn't
necessarily a big job, but the wrinkle is that it was reworked at one
point to use the navigation binding to receive the routing to use from the
main navigation app.  The previous implementation was D-Bus based (GENIVI
Navicore API), which we could potentially try to resurrect in some
updated form, though I am somewhat a bit loathe to do so.  It might be
simpler to rig up something with the navigation values from VSS, though,
since we could leverage kuksa.val for that.  I am open to suggestions on
how to proceed, or pointers to something we could reuse.

Scott



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9626): https://lists.automotivelinux.org/g/agl-dev-community/message/9626
Mute This Topic: https://lists.automotivelinux.org/mt/87944808/2167316
Group Owner: agl-dev-community+owner@xxxxxxxxxxxxxxxxxxxxxxxxx
Unsubscribe: https://lists.automotivelinux.org/g/agl-dev-community/leave/4543822/2167316/883735764/xyzzy [list-automotive-discussions82@xxxxxxxxxxx]
-=-=-=-=-=-=-=-=-=-=-=-