GPU 2d/3d acceleration not working in yocto qte-in-use-image

GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Carrillodominguez Francisco Alberto-B35153]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]



We have a client that is using Qt4.8 compiled with Yocto dylan, they report that the GPU acceleration is not enabled.  Talking with Leo, he mentioned that the enablement to GPU have been done in one of the working branches  master-next or other one.

Could you help me to confirm which branch is the correct one, and if it is true that the GPU acceleration would be enabled for Qt on that branch?

Is it possible for the client to use these branches ?


Francisco C.

[-- Attachment #2: Type: text/html, Size: 2461 bytes --]

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Thomas Senyk]

On Monday, 15 July, 2013 15:46:32 Carrillodominguez Francisco Alberto-B35153 
wrote:
> We have a client that is using Qt4.8 compiled with Yocto dylan, they report
> that the GPU acceleration is not enabled.  Talking with Leo, he mentioned
> that the enablement to GPU have been done in one of the working branches 
> master-next or other one.
> 
> Could you help me to confirm which branch is the correct one, and if it is
> true that the GPU acceleration would be enabled for Qt on that branch?
> 
> Is it possible for the client to use these branches ?

What GPU acceleration to you mean?
One doesn't simple 'enable GPU acceleration' :)

What does your application do, what do you want to achieve and what isn't 
working/isn't as fast as you expected?
"they report"? 'they'? 'report'?


> 
> 
> Francisco C.

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Carrillodominguez Francisco Alberto-B35153]

[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]


Hi Thomas thank you for your answer.


This is the question from the client:

The GPU 2D/3D acceleration is not working in the Yocto qte-in-use-image.  Looks like the "virtual/libgles2" and "-opengl es2 -openvg" are missing from imx6 in files qt4-embedded_4.8.4.bbappend and qt4-x11-free_4.8.4.bbappend, as shown below.
 
     DEPENDS_append_mx5 = " virtual/kernel virtual/libgles2"
     PACKAGE_ARCH_mx5 = "${MACHINE_ARCH}"
     QT_GLFLAGS_mx5 = "-opengl es2 -openvg"
     QT_CONFIG_FLAGS_append_mx5 = " -I${STAGING_KERNEL_DIR}/include/"
 
     DEPENDS_append_mx6 = " virtual/kernel"
     PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}"
     QT_CONFIG_FLAGS_append_mx6 = " -I${STAGING_KERNEL_DIR}/include/"
 
Adding "virtual/libgles2" and "-opengl es2 -openvg" for the imx6 as below resulted in the attached build errors.
 
     DEPENDS_append_mx6 = " virtual/kernel virtual/libgles2"
     PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}"
     QT_GLFLAGS_mx6 = "-opengl es2 -openvg"
     QT_CONFIG_FLAGS_append_mx6 = " -I${STAGING_KERNEL_DIR}/include/"
 
What is the correct way to enable GPU 2D/3D acceleration for imx6 in the Yocto qte-in-use-image?

-----------------------------------------------------------------------------------------------------



In the log you can see that the EGL appears disabled. And OpenVG fails too.

>EGL (EGL/egl.h) disabled.

Francisco C.


-----Original Message-----
From: Thomas Senyk [mailto:thomas.senyk@pelagicore.com] 
Sent: Monday, July 15, 2013 11:12 AM
To: Carrillodominguez Francisco Alberto-B35153
Cc: Otavio Salvador; Sandoval Gonzalez Leonardo-B42214; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] GPU 2d/3d acceleration not working in yocto qte-in-use-image

On Monday, 15 July, 2013 15:46:32 Carrillodominguez Francisco Alberto-B35153
wrote:
> We have a client that is using Qt4.8 compiled with Yocto dylan, they 
> report that the GPU acceleration is not enabled.  Talking with Leo, he 
> mentioned that the enablement to GPU have been done in one of the 
> working branches master-next or other one.
> 
> Could you help me to confirm which branch is the correct one, and if 
> it is true that the GPU acceleration would be enabled for Qt on that branch?
> 
> Is it possible for the client to use these branches ?

What GPU acceleration to you mean?
One doesn't simple 'enable GPU acceleration' :)

What does your application do, what do you want to achieve and what isn't working/isn't as fast as you expected?
"they report"? 'they'? 'report'?


> 
> 
> Francisco C.


[-- Attachment #2: log.do_configure.951.zip --]
[-- Type: application/x-zip-compressed, Size: 4216 bytes --]

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Mon, Jul 15, 2013 at 1:28 PM, Carrillodominguez Francisco
Alberto-B35153 <B35153@freescale.com> wrote:
>
> Hi Thomas thank you for your answer.
>
>
> This is the question from the client:

Maybe it'd be good to ask him/her to join here too?

> The GPU 2D/3D acceleration is not working in the Yocto qte-in-use-image.  Looks like the "virtual/libgles2" and "-opengl es2 -openvg" are missing from imx6 in files qt4-embedded_4.8.4.bbappend and qt4-x11-free_4.8.4.bbappend, as shown below.
>
>      DEPENDS_append_mx5 = " virtual/kernel virtual/libgles2"
>      PACKAGE_ARCH_mx5 = "${MACHINE_ARCH}"
>      QT_GLFLAGS_mx5 = "-opengl es2 -openvg"
>      QT_CONFIG_FLAGS_append_mx5 = " -I${STAGING_KERNEL_DIR}/include/"
>
>      DEPENDS_append_mx6 = " virtual/kernel"
>      PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}"
>      QT_CONFIG_FLAGS_append_mx6 = " -I${STAGING_KERNEL_DIR}/include/"
>
> Adding "virtual/libgles2" and "-opengl es2 -openvg" for the imx6 as below resulted in the attached build errors.
>
>      DEPENDS_append_mx6 = " virtual/kernel virtual/libgles2"
>      PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}"
>      QT_GLFLAGS_mx6 = "-opengl es2 -openvg"
>      QT_CONFIG_FLAGS_append_mx6 = " -I${STAGING_KERNEL_DIR}/include/"
>
> What is the correct way to enable GPU 2D/3D acceleration for imx6 in the Yocto qte-in-use-image?

It is in master-next, at:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=5bc7e2fd94ac9311665bb4aac7cc34c7ac2e9a09

It needs testing; It had issues in past but I didn't check it again.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Dunham Ragan-B37558]

On 7/15/13 11:35 AM, "Otavio Salvador" <otavio@ossystems.com.br> wrote:

>Maybe it'd be good to ask him/her to join here too?

Agree.  I have now done so.

/rd

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Eric Bénard]

Hi Otavio,

Le Mon, 15 Jul 2013 13:35:47 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :
> On Mon, Jul 15, 2013 at 1:28 PM, Carrillodominguez Francisco
> Alberto-B35153 <B35153@freescale.com> wrote:
> > What is the correct way to enable GPU 2D/3D acceleration for imx6 in the Yocto qte-in-use-image?
> 
> It is in master-next, at:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=5bc7e2fd94ac9311665bb4aac7cc34c7ac2e9a09
> 
may you please post patches to the mailing list before (or at least
when) applying them to the git tree so that some review is possible
(more and more patches are applied directly without going to the ML
which makes it hard to follow the development) ?

Thanks
Eric

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Wed, Jul 17, 2013 at 5:13 AM, Eric Bénard <eric@eukrea.com> wrote:
> Hi Otavio,
>
> Le Mon, 15 Jul 2013 13:35:47 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>> On Mon, Jul 15, 2013 at 1:28 PM, Carrillodominguez Francisco
>> Alberto-B35153 <B35153@freescale.com> wrote:
>> > What is the correct way to enable GPU 2D/3D acceleration for imx6 in the Yocto qte-in-use-image?
>>
>> It is in master-next, at:
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=5bc7e2fd94ac9311665bb4aac7cc34c7ac2e9a09
>>
> may you please post patches to the mailing list before (or at least
> when) applying them to the git tree so that some review is possible
> (more and more patches are applied directly without going to the ML
> which makes it hard to follow the development) ?

I do; this patch were post long  time ago and I was not tracking it
anymore. When Francisco said he needed it I wanted to share my last
version so he could give it a try.

I have some patches ready for review and will post them this afternoon.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Eric Bénard]

Hi Otavio,

Le Wed, 17 Jul 2013 09:12:14 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :

> On Wed, Jul 17, 2013 at 5:13 AM, Eric Bénard <eric@eukrea.com> wrote:
> > Hi Otavio,
> >
> > Le Mon, 15 Jul 2013 13:35:47 -0300,
> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >> On Mon, Jul 15, 2013 at 1:28 PM, Carrillodominguez Francisco
> >> Alberto-B35153 <B35153@freescale.com> wrote:
> >> > What is the correct way to enable GPU 2D/3D acceleration for imx6 in the Yocto qte-in-use-image?
> >>
> >> It is in master-next, at:
> >>
> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=5bc7e2fd94ac9311665bb4aac7cc34c7ac2e9a09
> >>
> > may you please post patches to the mailing list before (or at least
> > when) applying them to the git tree so that some review is possible
> > (more and more patches are applied directly without going to the ML
> > which makes it hard to follow the development) ?
> 
> I do; this patch were post long  time ago and I was not tracking it

now I found the previous version which was not sent as a patch but as
an attachement when answering to another thread making its review even
harder.

If you need more examples of commits not sent to the ML, there are these
ones :
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=704b1ad5b307367f2c62b9b33d024aa09ec43d84
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=6589099d872a085c839aede369908b64203c42b1
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=5538fb61375eeffa92329f5f8f22c235d34838ba
and I'm only talking of the last ones but you can find more in the
history.

One solution : is it possible to configure the git server to send a
mail to the ML for each commits so that we get a chance to be notified
of new commits without having to dig in the history each time we
sync ?

Thanks,

Eric

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Wed, Jul 17, 2013 at 9:26 AM, Eric Bénard <eric@eukrea.com> wrote:
> Hi Otavio,
>
> Le Wed, 17 Jul 2013 09:12:14 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>
>> On Wed, Jul 17, 2013 at 5:13 AM, Eric Bénard <eric@eukrea.com> wrote:
>> > Hi Otavio,
>> >
>> > Le Mon, 15 Jul 2013 13:35:47 -0300,
>> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
>> >> On Mon, Jul 15, 2013 at 1:28 PM, Carrillodominguez Francisco
>> >> Alberto-B35153 <B35153@freescale.com> wrote:
>> >> > What is the correct way to enable GPU 2D/3D acceleration for imx6 in the Yocto qte-in-use-image?
>> >>
>> >> It is in master-next, at:
>> >>
>> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=5bc7e2fd94ac9311665bb4aac7cc34c7ac2e9a09
>> >>
>> > may you please post patches to the mailing list before (or at least
>> > when) applying them to the git tree so that some review is possible
>> > (more and more patches are applied directly without going to the ML
>> > which makes it hard to follow the development) ?
>>
>> I do; this patch were post long  time ago and I was not tracking it
>
> now I found the previous version which was not sent as a patch but as
> an attachement when answering to another thread making its review even
> harder.
>
> If you need more examples of commits not sent to the ML, there are these
> ones :
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=704b1ad5b307367f2c62b9b33d024aa09ec43d84
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=6589099d872a085c839aede369908b64203c42b1
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=master-next&id=5538fb61375eeffa92329f5f8f22c235d34838ba
> and I'm only talking of the last ones but you can find more in the
> history.

Those in master-next will be send to mailing list for review.

> One solution : is it possible to configure the git server to send a
> mail to the ML for each commits so that we get a chance to be notified
> of new commits without having to dig in the history each time we
> sync ?

No.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Eric Bénard]

Le Wed, 17 Jul 2013 09:30:18 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :
> Those in master-next will be send to mailing list for review.
> 
so if I understand well master-next is a sandbox which can get commits
not sent to the ML ?

Eric

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Wed, Jul 17, 2013 at 9:33 AM, Eric Bénard <eric@eukrea.com> wrote:
> Le Wed, 17 Jul 2013 09:30:18 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>> Those in master-next will be send to mailing list for review.
>>
> so if I understand well master-next is a sandbox which can get commits
> not sent to the ML ?

No; master-next is a place I have been using to push things to
autobuilder or people test. It sometimes has patches not sent to
mailing list for my convenience so I can get autobuilder test and
feedback.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Eric Bénard]

Le Wed, 17 Jul 2013 09:37:09 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :

> On Wed, Jul 17, 2013 at 9:33 AM, Eric Bénard <eric@eukrea.com> wrote:
> > Le Wed, 17 Jul 2013 09:30:18 -0300,
> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >> Those in master-next will be send to mailing list for review.
> >>
> > so if I understand well master-next is a sandbox which can get commits
> > not sent to the ML ?
> 
> No; master-next is a place I have been using to push things to
> autobuilder or people test. It sometimes has patches not sent to
> mailing list for my convenience so I can get autobuilder test and
> feedback.

so you confirm that master-next can get commits not sent to the ML so
the answer to the question is "yes" ;-) that's not a big issue for
master-next the only thing is to be aware of that.

Just FYI, unless I'm mistaken, these ones are in master and were not
sent to the ML :
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=30f65ca2688a4c94f9790968fa2a8408e8e50a34
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=5398e59900cfceb995f924bd06dc8e3801599767
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=4a91984318cbc8c8b56f319a6eb7856e81fa9cac
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=daf582c93a7283fb0af3b25fe2ada48f4c9985c4
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=ba487405f60c38ea2a77b7a6866f954b665eefa7
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=d48e4022824a13206f2a893759cf332a174e6d7d
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=f8a8a5eddc9e0d7e39e219dfb1fd137c8f77addc
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=1cb885570c9666bf4c7f8986623fc66988cec292

Here again not a big problem : the only thing is to be aware patches can
reach master without being sent to the ML, that can be important for
peoples having external layers based on meta-fsl-arm's master branch.

Eric

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Wed, Jul 17, 2013 at 10:01 AM, Eric Bénard <eric@eukrea.com> wrote:
> Le Wed, 17 Jul 2013 09:37:09 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>
>> On Wed, Jul 17, 2013 at 9:33 AM, Eric Bénard <eric@eukrea.com> wrote:
>> > Le Wed, 17 Jul 2013 09:30:18 -0300,
>> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
>> >> Those in master-next will be send to mailing list for review.
>> >>
>> > so if I understand well master-next is a sandbox which can get commits
>> > not sent to the ML ?
>>
>> No; master-next is a place I have been using to push things to
>> autobuilder or people test. It sometimes has patches not sent to
>> mailing list for my convenience so I can get autobuilder test and
>> feedback.
>
> so you confirm that master-next can get commits not sent to the ML so
> the answer to the question is "yes" ;-) that's not a big issue for
> master-next the only thing is to be aware of that.
>
> Just FYI, unless I'm mistaken, these ones are in master and were not
> sent to the ML :
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=30f65ca2688a4c94f9790968fa2a8408e8e50a34
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=5398e59900cfceb995f924bd06dc8e3801599767
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=4a91984318cbc8c8b56f319a6eb7856e81fa9cac
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=daf582c93a7283fb0af3b25fe2ada48f4c9985c4
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=ba487405f60c38ea2a77b7a6866f954b665eefa7
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=d48e4022824a13206f2a893759cf332a174e6d7d
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=f8a8a5eddc9e0d7e39e219dfb1fd137c8f77addc
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=1cb885570c9666bf4c7f8986623fc66988cec292
>
> Here again not a big problem : the only thing is to be aware patches can
> reach master without being sent to the ML, that can be important for
> peoples having external layers based on meta-fsl-arm's master branch.

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 am happy you understand it.

Regards,

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Eric Bénard]

Le Wed, 17 Jul 2013 10:14:40 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :
> I am happy you understand it.
> 
I would also be happy if you understood that sending an email to the ML
with the patch (even when comitting it directly) makes it easier for
peoples to follow the git repository's activity.

Eric

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Daiane Angolini]

On 07/17/2013 10:14 AM, Otavio Salvador wrote:
> On Wed, Jul 17, 2013 at 10:01 AM, Eric Bénard <eric@eukrea.com> wrote:
>> Le Wed, 17 Jul 2013 09:37:09 -0300,
>> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>>
>>> On Wed, Jul 17, 2013 at 9:33 AM, Eric Bénard <eric@eukrea.com> wrote:
>>>> Le Wed, 17 Jul 2013 09:30:18 -0300,
>>>> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>>>>> Those in master-next will be send to mailing list for review.
>>>>>
>>>> so if I understand well master-next is a sandbox which can get commits
>>>> not sent to the ML ?
>>>
>>> No; master-next is a place I have been using to push things to
>>> autobuilder or people test. It sometimes has patches not sent to
>>> mailing list for my convenience so I can get autobuilder test and
>>> feedback.
>>
>> so you confirm that master-next can get commits not sent to the ML so
>> the answer to the question is "yes" ;-) that's not a big issue for
>> master-next the only thing is to be aware of that.
>>
>> Just FYI, unless I'm mistaken, these ones are in master and were not
>> sent to the ML :
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=30f65ca2688a4c94f9790968fa2a8408e8e50a34
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=5398e59900cfceb995f924bd06dc8e3801599767
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=4a91984318cbc8c8b56f319a6eb7856e81fa9cac
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=daf582c93a7283fb0af3b25fe2ada48f4c9985c4
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=ba487405f60c38ea2a77b7a6866f954b665eefa7
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=d48e4022824a13206f2a893759cf332a174e6d7d
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=f8a8a5eddc9e0d7e39e219dfb1fd137c8f77addc
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=1cb885570c9666bf4c7f8986623fc66988cec292
>>
>> Here again not a big problem : the only thing is to be aware patches can
>> reach master without being sent to the ML, that can be important for
>> peoples having external layers based on meta-fsl-arm's master branch.
>
> 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.

I really think any merged patch MUST be sent to ML previously.

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.

Is there any restriction from Yoctoproject daily build server that it 
must build every single time, with no failure?



>
> I am happy you understand it.

I'm not happy

>
> Regards,
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://projetos.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>


-- 
Daiane

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Wed, Jul 17, 2013 at 5:43 PM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 07/17/2013 10:14 AM, Otavio Salvador wrote:
>>
>> On Wed, Jul 17, 2013 at 10:01 AM, Eric Bénard <eric@eukrea.com> wrote:
>>>
>>> Le Wed, 17 Jul 2013 09:37:09 -0300,
>>> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>>>
>>>> On Wed, Jul 17, 2013 at 9:33 AM, Eric Bénard <eric@eukrea.com> wrote:
>>>>>
>>>>> Le Wed, 17 Jul 2013 09:30:18 -0300,
>>>>> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>>>>>>
>>>>>> Those in master-next will be send to mailing list for review.
>>>>>>
>>>>> so if I understand well master-next is a sandbox which can get commits
>>>>> not sent to the ML ?
>>>>
>>>>
>>>> No; master-next is a place I have been using to push things to
>>>> autobuilder or people test. It sometimes has patches not sent to
>>>> mailing list for my convenience so I can get autobuilder test and
>>>> feedback.
>>>
>>>
>>> so you confirm that master-next can get commits not sent to the ML so
>>> the answer to the question is "yes" ;-) that's not a big issue for
>>> master-next the only thing is to be aware of that.
>>>
>>> Just FYI, unless I'm mistaken, these ones are in master and were not
>>> sent to the ML :
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=30f65ca2688a4c94f9790968fa2a8408e8e50a34
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=5398e59900cfceb995f924bd06dc8e3801599767
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=4a91984318cbc8c8b56f319a6eb7856e81fa9cac
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=daf582c93a7283fb0af3b25fe2ada48f4c9985c4
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=ba487405f60c38ea2a77b7a6866f954b665eefa7
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=d48e4022824a13206f2a893759cf332a174e6d7d
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=f8a8a5eddc9e0d7e39e219dfb1fd137c8f77addc
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=1cb885570c9666bf4c7f8986623fc66988cec292
>>>
>>> Here again not a big problem : the only thing is to be aware patches can
>>> reach master without being sent to the ML, that can be important for
>>> peoples having external layers based on meta-fsl-arm's master branch.
>>
>>
>> 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).

> 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.

> Is there any restriction from Yoctoproject daily build server that it must
> build every single time, with no failure?

No; this is my restriction. The more time it is failing to build more
failure accumulate and I keep it working all the time to avoid having
hidden issues there.

Regards,

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Eric Bénard]

Le Wed, 17 Jul 2013 18:02:27 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :

> On Wed, Jul 17, 2013 at 5:43 PM, Daiane Angolini
> <daiane.angolini@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 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).

> > Is there any restriction from Yoctoproject daily build server that it must
> > build every single time, with no failure?
> 
> No; this is my restriction. The more time it is failing to build more
> failure accumulate and I keep it working all the time to avoid having
> hidden issues there.
> 
the important thing is to be aware of your policies (and their
evolutions).

Eric

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Thu, Jul 18, 2013 at 4:16 AM, Eric Bénard <eric@eukrea.com> wrote:
> Le Wed, 17 Jul 2013 18:02:27 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>
>> On Wed, Jul 17, 2013 at 5:43 PM, Daiane Angolini
>> <daiane.angolini@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.

>> > Is there any restriction from Yoctoproject daily build server that it must
>> > build every single time, with no failure?
>>
>> No; this is my restriction. The more time it is failing to build more
>> failure accumulate and I keep it working all the time to avoid having
>> hidden issues there.
>>
> the important thing is to be aware of your policies (and their
> evolutions).

Regards,

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: 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@ossystems.com.br> a écrit :

> On Thu, Jul 18, 2013 at 4:16 AM, Eric Bénard <eric@eukrea.com> wrote:
> > Le Wed, 17 Jul 2013 18:02:27 -0300,
> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >
> >> On Wed, Jul 17, 2013 at 5:43 PM, Daiane Angolini
> >> <daiane.angolini@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

Re: GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Fabio Estevam]

On Thu, Jul 18, 2013 at 4:16 AM, Eric Bénard <eric@eukrea.com> wrote:

> 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).

Yes, please always send the patches to the list, Otavio.

Last week, for example I sent two patches updating the kernel commits
from git.freescale.com, then you replied that such changes were
already done.

If I had seen your patches in the list, I would not have spent time
working on the exact same change.

I also do not agree with the policy of silently applying patches, no
matter if they are trivial fixes or build breaks.

Just post everything here and this will makes things easier for everybody.