Fwd: GENIVI Development Platform on NXP
gandersson at genivi.org
Fri Apr 7 07:09:29 EDT 2017
Including the mailing list into this conversation (as agreed with
Claudiu). Feel free to jump in, or just read it to stay informed.
I am aware of several member companies running GDP on NXP already (as
demonstrated in showcases over several years).
Would still want to see that all those adopters involve themselves in
supporting the integration on the actual master branch. If you're adopting
the platform, you should provide changes to the base platform back into
master. It's that simple.
I would also like to see (and I've pointed this out in shared forums)
somebody to jump in and better align how BSPs are set up in GDP vs.
AGL, so we can stop wasted effort on that front at least. The Yocto setup
enables us to get quite far on that but more can be done. I don't
personally have the time right now but it should be beneficial for many
companies to avoid any disparity.
From: Gunnar Andersson [mailto:gandersson at genivi.org]
Sent: Friday, April 07, 2017 12:51 PM
To: Claudiu Ion Lataretu <claudiuion.lataretu at nxp.com>; Zeeshan Ali <zeeshan
.ali at pelagicore.com> (zeeshan.ali at pelagicore.com) <zeeshan.ali at pelagicore.co
Subject: Re: GENIVI Development Platform on NXP (was: Re: Genivi compliance)
On Fri, 2017-04-07 at 09:13 +0000, Claudiu Ion Lataretu wrote:
> I am sorry for my late response. I was working on fixing some problems
> that I had. As I mentioned earlier, I had issues with GDP demo
> applications because it does not rendered the GUI on the screen After
> some debugging on them, I found what caused the issue. In the source
> code of the applications there is a setenv function call that sets
> QT_WAYLAND_DISABLE_WINDOWDECORATION environment variable to 1
> (setenv("QT_WAYLAND_DISABLE_WINDOWDECORATION", "1", 1);). I commented
> this line of code and I removed the window decorator from the view
> itself as
> view.setFlags(Qt::FramelessWindowHint | Qt::Window); This solved
> problem with GUI and now I can see all the GUI elements on the screen.
> Do you consider that I should make a commit into the github repository
> for those applications(HVAC, fmradio and connectedhome) with my
> Or should I keep it just as a patch?
If you have your own personal account on GitHub it's usually better to make
a fork of those projects, commit your changes there, and then you can send a
pull request. We of course would need to test your changes on all other
hardware too but hopefully it works and then we don't need to carry a
special patch for NXP.
> Regarding your below questions. Yes, I do start with
> ved=0 master branch, but my approach was to get a working I.MX yocto bsp
> and include the genivi-dev- platform in that bsp with all the layer
> dependencies that it needs.
OK. I think we more work with the opposite thinking "include the bsp in
genivi-dev-platform". But the end result should be similar, but in the end
we would like this packaged in the same way as all other support for GDP.
There are many BSPs already supported - each of them brought in as a
submodule and this is another.
But that's OK. If you are able to publish your whole project then we start
by comparing and understanding?
This conversation should also be moved to one of our mailing lists so that
others can help out and know what's going on. Do you mind if I post it to
More information about the genivi-projects