 Okay, so I just have a few slides and then I wanted to mostly focus on people's questions. Really would like to hear after, you know, all this time with AGL, what are your suggestions for what we could improve on AGL because that's really what we want to focus on is the developer experience and how we can make your life easier. So just a quick overview, most of you should already know this where AGL is, you know, collaborating to develop the car of the future through rapid innovation. We are hosted at the Linux Foundation myself. I'm Walt Minor. I'm the community manager on Simon. You can see him as well. He's the release manager and we both are employees of the Linux Foundation. The open source software, everything we do is completely in the open. All these slides, by the way, should already be posted. I posted them on SCED just before the session started here. So we have 11 OEM supporting AGL at the moment, including most of the major Japanese manufacturers, including Toyota, Mazda, Honda, Subaru, Suzuki, Mitsubishi. We have European manufacturers like Mercedes-Benz and Volkswagen and we have, you know, Ford here in the US and we're always, and we even have a Chinese manufacturer SAIC. So a pretty good variety of different manufacturers who are participating in AGL. We have a total of 155 member companies. This might even be a little out of date since I got this slide, but again, we're signing up members at quite a good rate this year, even despite the COVID epidemic. And we're focusing on all of the vehicle in the car. As we like to say, if there's Linux in the vehicle, it should be running AGL. So infotainment was our original profile that we worked on. Now we've been focusing on instrument cluster, but we're adding things like, we've added telematics, a head-up display with a sand cloud board. And we're working with Alisa on functional safety. And eventually we'll add ADAS and hopefully Autonomous Driving to our portfolio of software. So we have the AGL Unified Codebase, which is what everybody should be using, basically a single open-source software platform for the entire industry. We aim to provide at least 70% of the base platform for production projects. And really our goal over the last five or six years that I've been involved is cultivating an ecosystem of developers and suppliers and automotive expertise using open-source and using this single platform. And our goal has been to create reference hardware and software and applications that are available for the entire community. So just a quick overview of our schedule. This year we released, at the beginning of the year, we released our 9.0 release, HGAS Fish. In September last month we released 10.0 Jumping Jellyfish. We are now working on Kuki Koi, and I've got a few more detailed slides about those schedules in a second here. So the UCB for Jumping Jellyfish, which was 10.0, which was released in September, we up revved to the YAKTO 3.1, which is the long-term support version of YAKTO. We basically, we updated the Window Manager compositor and home screen, and we all, that was all done to match the demo feature set that we had at CES last year, or earlier this year, rather. We had other new features that were driven by GAP analysis and member donations. We extended some of the existing HGL binders. We created some new test plans, and our CI group continues to add to the test infrastructure. So for Jellyfish, we basically, we worked throughout the year. We did the final release in September, but should be filled in. It's already out, available, and we're working on a, the first patch release we're working on for next month, for November, for Kuki Koi. So the plan is, we'll continue with YAKTO 3.1, the long-term support version. Right now, we plan to continue with that for at least the two-year life cycle, but we'll continue to revisit that, but that's the plan for now. We'll be adding features like instrument cluster containers, which is something our instrument cluster expert group has been working on. And I'll talk about the expert groups in a second, but the instrument cluster expert group is working on creating a, creating a production-ready or close-to-production-ready version of an instrument cluster that is also functional, you know, ASLB functional safety ready by the end of next year. Our virtualization expert group is working on Vert.io, and then Denzo is contributing something called rules-based arbitration for the user interface that we also hope to get in for Kuki Koi. So the schedule for Koi, right now, this schedule was originally created around the idea that we would be attending CES in January. Obviously, that's not happening, CES is now virtual only. So basically we'll stick with this schedule with the final release in the February timeframe, February 12th, and then patch updates next year. So just wanted to touch on the expert groups. So in terms of developers, probably there's several ways to get involved. I've got some slides coming up on developer resources, such as meetings and documentation website, things like that, where to get the code. But really, if there's a particular area of interest that you have, the best way to get involved is to participate in one of these expert groups. And I like to say you don't need to be an expert to participate in our expert groups. You just need to be willing to work on these areas, have some knowledge is great. But even if you're just looking to learn something new, participating in the expert groups is a great thing. This is the list of currently active expert groups. And if you go, later on I'll have some links to our groups.io page and to our wiki page. And you can find out when the meetings are for each of these groups. They meet every other week. They each have an active page on the wiki page and in some cases on confluence for documenting requirements and meeting minutes and what they're working on. The virtualization expert group is what's focusing on the Verdi OU's case. Continuous integration and automated tests, they're doing all of the work with our test infrastructure with Jenkins and Lava and everything that's associated with that. Yon Simon is also looking at how do we integrate FOS tools and like he gave a presentation on yesterday as well as possibly some static analysis tools into the CI loop. Instrument cluster is very, very, oops, sorry, shouldn't have done that, I want to go back. Instrument cluster is very, very active looking at creating that instrument cluster reference. And to compliment that, we've got an IVI expert group that's forming to focus on adding some more production-ready features to the IVI profile. That's something that we just, we're just in the process of forming. We're thinking Toyota will be leading that expert group. Suzuki currently leads the instrument cluster expert group. So I think just in general as a developer, it's probably the best way to get involved in a particular area that you might be interested in. The other, so this is again, I uploaded all these slides already to SCED. You can see our wiki page, our documentation site. There's a getting started guide both on the documentation site and on the wiki page. I think the documentation site I should link to now instead of the wiki. We've got pre-built binaries and sourced hard balls. Our release notes are on the wiki page, Garrett and Git are available. We use Garrett for code review and we've got a Git mirror as well. We have every Tuesday, except for today, we didn't have one because of ELCE here. We have a developer call so anybody can call in. If you have a question about how to do something, you can either ask it on the mailing list. You can ask it on IRC or on IRC or you can call into the dev call and we'll try to get you the help that you need. And then we typically, in addition to that, again, we try to have regular face-to-face meetings among the developers. Typically, in a more typical year, we would try to do something about every two months, six weeks to two months. You can see this was what we did last year. This year, it's been a little more limited. We had some events that were just canceled. We had some face-to-faces that were canceled. But we have had a few virtual ones. And we have another virtual face-to-face meeting scheduled for December 7th through 9th. So it's another opportunity to participate on a larger scale with the developers. I think for the October one, we had about 35 to 40 people participating. And that's really it. I wanted to really spend most of the time here answering any questions people have or discussing anything that people might want to bring up. So I don't know, Yann Simon, were there any questions that appeared in the chat? No, not so far. So if not, you can unmute your mic and ask a question or put it in the chat here. Or I can sing some really bad songs. Hello, Rakesh. I have a question. So it's a general one. So when you mean that you are going to bring in ADAS capability or, let's say, you already brought a certain part of that into Automotive Grid and Linux, how is it, let's say, how is the AI part coming into picture here? Like what are the developments that are happening specifically to artificial intelligence? Really, at this point, we've more focused on the sensor side of ADAS and trying to provide a sensor framework and vehicle signaling architecture so that you could combine sensor inputs. We've not really focused on the AI part and how to bring that in. A lot of that, our OEMs are saying are proprietary and they're not really willing to contribute that at this point. So like any open source project, we're reliant to a great extent on what people are willing to contribute and bring into the project. So at this point, we've not seen a lot of interest from the car manufacturers to bring that into AGL, but it's definitely something we're hoping for. Absolutely. Yeah, thank you. Yeah, no, you're welcome. Thank you for the question. I'll just jump on there. People have done demos with the, I think I'm trying to name it the name of it. There's a couple of different open source stacks, although I think both of them you end up needing to potentially play some games around training data. But the by-do system, I think I've seen demos of running on top of AGL. Forget the name of that one off the top of my head. An NTT data MSC was showing some things in some demos, running on top of AGL. Yeah, I mean, if something runs on Linux, you can pretty much easily get it to work on top of AGL. So yeah, a lot of what we see people, a lot of applications, you know, and that's more on the application side. A lot of applications we see people bringing to various trade shows or CES. And it's always surprising to me to see what people are running on top of AGL. It's always interesting and surprising to see that. Anybody else have any questions, how they can participate? I'd like to open it up to also hear what could we, if you've been using AGL, what could we do to improve your life or your experience as a developer? Simon, do you have anything you want to bring up while we're here? Well, I could ask what hardware people might be interested in. So we have the support on IMX8 going on. So there's support for that being contributed and worked on by community members. So we would like to hear if any of you have interest in that, or what other boards or platforms might be interesting to you. So we have, just in general, we have IMX8, we have Raspberry Pi, we have Renaissance support, Intel, both QMU and up square and middle board. Yeah, basically, if you need to demo or want to check out AGL, any touchscreen laptop or anything X86 will do for a quick try. Raspberry Pi 4 will work fine with HDMI. So that's easy to try that. Well, this can be a short session if nobody has any more questions. It's a pretty generic question, since I'm pretty new to the whole project. But do you completely focus maybe only on the device side or is there also something like interfacing the vehicle for instance from the cloud and especially having a common abstraction layer for that on how to access data from the vehicles or is it out of scope for your project? So we do have, OK, there's two parts to that question. So we do have a vehicle signal manager and a CAN interface. So and there's been a lot of work around that. So there's so you can access the vehicle data through CAN. And some guys at Roitlingen University have been integrating that more and more into their car simulator and trying to build out some more of the generic infrastructure around that. And then we have a vehicle to cloud and that's being done through our connectivity expert group. If I go to the if I want to go back to the group slides. And then we have a vehicle to cloud expert group that's been focusing on the how to get that data up into the cloud for analysis. And that's been led by ForgeRock and they've done so some companies that have done some work with plugins for for AWS and for Azure Cloud to get the data up there. So they've been working on the generic interface there on that side. So there are plenty of pieces already available in EGL for that. And of course, that's that's an area that we continually like to to build up on. That's a question from Jan Lüber in the chat window. So it says, I see the release knows that you are now using it now with on IMX6. How is your experience with that? And are you also using it on IMX8? Probably a question for Scott. Yeah. Well, for six, it just kind of happened. I mean, I had done work in the previous, I guess, the last couple of releases where I was explicitly configuring to build with that new V for the IMX6 boards that are community supported, just because it I mean, at this point, it consents as it works at least as well or better than Vivante on those on on the eight. Initially, when I did some work, there's some worse in community people trying to get one of the NXP BSP layers working and weren't having huge success. So I kind of rigged up something with Vivante for the first go around because that was more straightforward. But then once we upgraded to Dunfeld that Nivea became more doable, then there were new enough bits in in the various layers. So the at least initially, we were I was seeing some issues. And I think one of the community members that was playing with it, we're seeing some issues with with that Nivea. But the Walter Lozano from Collabra did some work. There were a couple of things missing in the five for stable kernel that were needed to get at Nivea kind of working well on the at least on the particular the board that we're sort of focusing on at the moment for the community support, which is the the IMXMQ, the EVK board. So at least for me, I haven't done a huge amount of testing on it. I just kind of do light support for it. It's I think now, at least with on the five for kernel with current MESA and Wayland and Weston, the performance is in the ballpark of Avante. There's a couple of times where now and again, I think maybe it's slightly slower, but it seems reasonable and I think it would be usable in production if you were not in need of some of the other like video to code and I think there's some stuff in Avante for integrating with a couple of the there's some hardware like video processing unit stuff in the the IMX kernel that NXP sort of support that I don't think there's anything upstream for yet. So if you didn't mean the fancier things like that that are only in an XP's BSP and enabled with Avante, then I think you could probably get by with that Nivea. I don't think there's anybody from Collabron the call. I think I got the impression they were doing a bit more research on that when Walter was looking at it a couple of months ago. But no, it's reasonable. I mean, at this point, I think it's pretty clear that I'm at six. It's very obviously, you know, a good choice to use it. I'm excited. I think there's still enough stuff. I mean, we did have to patch a couple of minor things to get it working on the EBK. But I think if you're running newer, if you're on like upstream five, you know, eight or nine kernel, I think it's probably going to be pretty straightforward. So but yeah, no, I think it's reasonable. It would be nice to have maybe some people who have other IMX8 hardware jumped in and do other testing. The IMX8 MQ EBK is about the only board that we have ready access to. But I know there's a bunch of people out there with SOM based boards, so quite a few different Psalms out from Phytec and several other companies that would be interesting to see some contributions on getting images built for them. So hopefully that answered your question. I think I don't have my microphone working. So thanks for the extensive answer. Is there a particular IMX8 board you're looking at, Jan? I was just interested in how your experience with Adnavif is that matches what our experience is or if there's anything we've missed that causes you problems. Yeah, I think the only real issue I've seen, I mean, it was back last fall, it was less obvious of how to get it to work well on on, especially the AMQ. I mean, there's the NXP didn't do themselves any favors because there's like six different flavors of IMX8. And there's, I think, three different GPUs in there. So you could say like, I mean, working on like the mini, the MM was lots of people could point at that working, but the AMQ was a lot more do-it-yourself for quite a while. And you should have been working earlier because that was the first thing Lucas had on his desk. So yeah, I mean, the thing with that was mostly, I mean, our hands are a little bit tight because we want to keep testing with a consistent set of layers in AGL. So we were stuck on thud up until early this year, which made it harder to pick and choose bits. I mean, I had trees here locally where I had hacked up, you know, back porting several things. And I think I did get it working quite a bit earlier before I pushed something to like AGL upstream just because it was gonna be a big, you know, a bunch of changes the project wouldn't want to carry for any length of time. So I mean, it was doable before, but once we went to Dunfell, it was pretty straightforward. So yeah, I think today it's in a way better shape now. It's a lot more obvious how to put it together. If you have any other questions or maybe on the M-plus or on the video input output stuff, there's the Adnavift channel on FreeNode. Yeah, I'm subscribed. I don't post there. I keep track of what's going on in there. Just ask there and I'll answer some. I think I asked a question way back, like in the spring. And I exchanged notes with Merrick somewhat originally on Adnavift stuff, so. Yeah, thanks a lot. Yeah, worries. Yeah, thank you, Jan. Okay, anybody else have something they would like to ask? Feel free to unmute your microphone or type a question into the chat window. Someone's got to have a question. Can I ask the audience a question? Sure. Since I see people from companies that I have a suspicion that they might have an answer is if you're already using a Yachto project or open embedded based Linux system in a vehicle environment, could you maybe either in the chat or unmute and give us a little description of the reason why you wouldn't currently be using AGL for that as opposed to your own in-house custom distribution? If you want to say, if not, I can live with that. And what could we do to make AGL closer to something you'd be interested in adopting? That's worth a shot. Okay, anything else? Well, if there's nothing else, I guess we'll end this early or we'll just hang out and you can all stare at me. Either way. All right, well, I guess we'll wrap this up early then. Thank you, everybody. Thanks, Walt. All right. Bye. Bye. Bye-bye.