[meta-freescale] GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Eric Bénard]

Le Thu, 18 Jul 2013 09:18:22 -0300,
Otavio Salvador <otavio at ossystems.com.br> a écrit :

> On Thu, Jul 18, 2013 at 4:16 AM, Eric Bénard <eric at eukrea.com> wrote:
> > Le Wed, 17 Jul 2013 18:02:27 -0300,
> > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> >
> >> On Wed, Jul 17, 2013 at 5:43 PM, Daiane Angolini
> >> <daiane.angolini at freescale.com> wrote:
> >> > On 07/17/2013 10:14 AM, Otavio Salvador wrote:
> >
> >> >> Yes and if you check those they're build failure fixes (except the
> >> >> duplicated assignment in mx28evk) so I could keep autobuilder and
> >> >> users being able to build. So this is the exception :-)
> >> >
> >> > I don't agree it should exists any exception for this.
> >>
> >> For everything there're an exception. However those patches were
> >> failures which NO ONE fixed and I use daily build for checking the
> >> quality of the BSP so it being broken is a problem for me.
> >>
> >> It is clear that *most* people do not run updated master branches (or
> >> they'd have got those failures and send a patch).
> >>
> > some peoples are not only trying to get a successful build on a daily
> > basis but are designing products (sometimes based on master when the
> > product's release is due for the next Yocto's release) and so can't
> > update the master branch every day when they are working on their
> > board's BSP.
> > Being aware patches are applied on master to improve it (or fix it when
> > necessary) is a good information for them.
> 
> I agree and I also have products being done.
> 
> Another thing it seems it would be bad if you update to today's master
> and it is broken, no? So I think  I end helping your product
> development.
> 
> >> > I really think any merged patch MUST be sent to ML previously.
> >>
> >> Most are send. Except the exceptions as said above.
> >>
> >> > I've been "accepting" your master-next approach only because I don't think
> >> > it matter for anyone. However, we must be sure what have in master.
> >>
> >> There's GIT for it. If people matter GIT log have all the information
> >> and I try to keep informative logs.
> >>
> > You're right, we always can find a technical solution. A more community
> > friendly solution would be to use the mailing list as done in most
> > other layers/projects but that's your layer so that's your policy and
> > now we know it. There is not cost for you (only a git send-email before
> > doing the git push - or even just after if you prefer).
> 
> This is to make your life easier. As I said the patches pushed
> directly were to fix build-failures or critical issues.
> 
> Now with this on mind I am curious ... do you review all patches I
> send? In case you do I am doing a good job as you comment very rarely
> on them ;)
> 
> It is very good when someone review my patches and find a issue I
> missed so, in case you're not following the mailing list close, please
> do.
> 
You are right don't change anything, that's perfect.

Best regards
Eric