qt4-embedded-gles breakage for dra7xx-evm

qt4-embedded-gles breakage for dra7xx-evm

[Maupin, Chase]

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

All,

Currently qt4-embedded-gles breaks for dra7xx-evm machine type (and likely omap5-evm as well) because of the following:


-        For AM devices such as am335x-evm the GLES library is called libGLES_CM.so

-        For OMAP devices such as dra7xx-evm the GLES library is called libGLESv1_CM.so

-        In the linux.conf for qt4-embedded-gles the libraries to include are listed as GLES_CM

This causes the do_configure stage to fail for the qt4-embedded-gles recipe on dra7xx-evm because it cannot find the GLES_CM library since that library for those devices is named GLESv1_CM.  I currently have a work around to fix this configure error of creating a version of the linux.conf for qt4-embedded-gles that uses for omap-a15 machine types.  This works (although there is a compile error I am tracking down due to missing pvr2d.h header files) but I was curious if this is the best way to solve this, or would it be better to fixup the library name or make symlinks between libGLES_CM and libGLESv1_CM in the graphics library recipe.

Inputs appreciated.

Sincerely,
Chase Maupin



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

Re: qt4-embedded-gles breakage for dra7xx-evm

[Maupin, Chase]

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


From: meta-arago-bounces@arago-project.org [mailto:meta-arago-bounces@arago-project.org] On Behalf Of Maupin, Chase
Sent: Wednesday, June 04, 2014 9:49 AM
To: meta-arago@arago-project.org
Subject: [meta-arago] qt4-embedded-gles breakage for dra7xx-evm

All,

Currently qt4-embedded-gles breaks for dra7xx-evm machine type (and likely omap5-evm as well) because of the following:


-        For AM devices such as am335x-evm the GLES library is called libGLES_CM.so

-        For OMAP devices such as dra7xx-evm the GLES library is called libGLESv1_CM.so

-        In the linux.conf for qt4-embedded-gles the libraries to include are listed as GLES_CM

This causes the do_configure stage to fail for the qt4-embedded-gles recipe on dra7xx-evm because it cannot find the GLES_CM library since that library for those devices is named GLESv1_CM.  I currently have a work around to fix this configure error of creating a version of the linux.conf for qt4-embedded-gles that uses for omap-a15 machine types.  This works (although there is a compile error I am tracking down due to missing pvr2d.h header files) but I was curious if this is the best way to solve this, or would it be better to fixup the library name or make symlinks between libGLES_CM and libGLESv1_CM in the graphics library recipe.

BTW, some of this may be a moot point because none of the OMAP SGX packages provide the pvr2d.h header.  So until there is alignment in these packages the version of Qt used for these devices either needs to be Qt5 which doesn’t have SGX acceleration yet, or the sgx MACHINE_FEATURE should be removed from the omap-a15 devices.  Thoughts?


Inputs appreciated.

Sincerely,
Chase Maupin


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

Re: qt4-embedded-gles breakage for dra7xx-evm

[Denys Dmytriyenko]

On Wed, Jun 04, 2014 at 02:57:39PM +0000, Maupin, Chase wrote:
> 
> From: meta-arago-bounces@arago-project.org [mailto:meta-arago-bounces@arago-project.org] On Behalf Of Maupin, Chase
> Sent: Wednesday, June 04, 2014 9:49 AM
> To: meta-arago@arago-project.org
> Subject: [meta-arago] qt4-embedded-gles breakage for dra7xx-evm
> 
> All,
> 
> Currently qt4-embedded-gles breaks for dra7xx-evm machine type (and likely 
> omap5-evm as well) because of the following:
> 
> 
> - For AM devices such as am335x-evm the GLES library is called libGLES_CM.so
> 
> - For OMAP devices such as dra7xx-evm the GLES library is called 
> libGLESv1_CM.so
> 
> - In the linux.conf for qt4-embedded-gles the libraries to include are 
> listed as GLES_CM
> 
> This causes the do_configure stage to fail for the qt4-embedded-gles recipe 
> on dra7xx-evm because it cannot find the GLES_CM library since that library 
> for those devices is named GLESv1_CM.  I currently have a work around to fix 
> this configure error of creating a version of the linux.conf for 
> qt4-embedded-gles that uses for omap-a15 machine types.  This works 
> (although there is a compile error I am tracking down due to missing pvr2d.h 
> header files) but I was curious if this is the best way to solve this, or 
> would it be better to fixup the library name or make symlinks between 
> libGLES_CM and libGLESv1_CM in the graphics library recipe.
> 
> BTW, some of this may be a moot point because none of the OMAP SGX packages 
> provide the pvr2d.h header.  So until there is alignment in these packages 
> the version of Qt used for these devices either needs to be Qt5 which 
> doesn’t have SGX acceleration yet, or the sgx MACHINE_FEATURE should be 
> removed from the omap-a15 devices.  Thoughts?

Qt5 does have GLES acceleation. It can be easily turned on and off, but it's 
required for QtWebkit, IIRC. Why are you saying there's no SGX acceleration?

As of the question - I'm fine disabling sgx MACHINE_FEATURE for now. Let's 
talk to the graphics team to see if/when it will be aligned/resolved.

-- 
Denys

Re: qt4-embedded-gles breakage for dra7xx-evm

[Maupin, Chase]

>-----Original Message-----
>From: Dmytriyenko, Denys
>Sent: Wednesday, June 04, 2014 10:10 AM
>To: Maupin, Chase
>Cc: meta-arago@arago-project.org
>Subject: Re: [meta-arago] qt4-embedded-gles breakage for dra7xx-
>evm
>
>On Wed, Jun 04, 2014 at 02:57:39PM +0000, Maupin, Chase wrote:
>>
>> From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
>bounces@arago-project.org] On Behalf Of Maupin, Chase
>> Sent: Wednesday, June 04, 2014 9:49 AM
>> To: meta-arago@arago-project.org
>> Subject: [meta-arago] qt4-embedded-gles breakage for dra7xx-evm
>>
>> All,
>>
>> Currently qt4-embedded-gles breaks for dra7xx-evm machine type
>(and likely
>> omap5-evm as well) because of the following:
>>
>>
>> - For AM devices such as am335x-evm the GLES library is called
>libGLES_CM.so
>>
>> - For OMAP devices such as dra7xx-evm the GLES library is called
>> libGLESv1_CM.so
>>
>> - In the linux.conf for qt4-embedded-gles the libraries to
>include are
>> listed as GLES_CM
>>
>> This causes the do_configure stage to fail for the qt4-embedded-
>gles recipe
>> on dra7xx-evm because it cannot find the GLES_CM library since
>that library
>> for those devices is named GLESv1_CM.  I currently have a work
>around to fix
>> this configure error of creating a version of the linux.conf for
>> qt4-embedded-gles that uses for omap-a15 machine types.  This
>works
>> (although there is a compile error I am tracking down due to
>missing pvr2d.h
>> header files) but I was curious if this is the best way to solve
>this, or
>> would it be better to fixup the library name or make symlinks
>between
>> libGLES_CM and libGLESv1_CM in the graphics library recipe.
>>
>> BTW, some of this may be a moot point because none of the OMAP
>SGX packages
>> provide the pvr2d.h header.  So until there is alignment in
>these packages
>> the version of Qt used for these devices either needs to be Qt5
>which
>> doesn’t have SGX acceleration yet, or the sgx MACHINE_FEATURE
>should be
>> removed from the omap-a15 devices.  Thoughts?
>
>Qt5 does have GLES acceleation. It can be easily turned on and
>off, but it's
>required for QtWebkit, IIRC. Why are you saying there's no SGX
>acceleration?

I thought Qt5 required similar patches to use the pvr2d library as Qt4 did.  I figured it could find the GLES libraries on it's own though.  Would it have the same issue with the renamed library?

>
>As of the question - I'm fine disabling sgx MACHINE_FEATURE for
>now. Let's
>talk to the graphics team to see if/when it will be
>aligned/resolved.

Or when do we want to change the default Qt to Qt5?  If you are saying the Qt5 can work with our SGX as is then maybe that should be the new default with Wayland/Weston as the window manager.  What are your thoughts?  Hopefully Franklin can chime in as well.

>
>--
>Denys

Re: qt4-embedded-gles breakage for dra7xx-evm

[Denys Dmytriyenko]

On Wed, Jun 04, 2014 at 11:52:32AM -0400, Maupin, Chase wrote:
> >-----Original Message-----
> >From: Dmytriyenko, Denys
> >Sent: Wednesday, June 04, 2014 10:10 AM
> >To: Maupin, Chase
> >Cc: meta-arago@arago-project.org
> >Subject: Re: [meta-arago] qt4-embedded-gles breakage for dra7xx-
> >evm
> >
> >On Wed, Jun 04, 2014 at 02:57:39PM +0000, Maupin, Chase wrote:
> >>
> >> From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
> >bounces@arago-project.org] On Behalf Of Maupin, Chase
> >> Sent: Wednesday, June 04, 2014 9:49 AM
> >> To: meta-arago@arago-project.org
> >> Subject: [meta-arago] qt4-embedded-gles breakage for dra7xx-evm
> >>
> >> All,
> >>
> >> Currently qt4-embedded-gles breaks for dra7xx-evm machine type
> >(and likely
> >> omap5-evm as well) because of the following:
> >>
> >>
> >> - For AM devices such as am335x-evm the GLES library is called
> >libGLES_CM.so
> >>
> >> - For OMAP devices such as dra7xx-evm the GLES library is called
> >> libGLESv1_CM.so
> >>
> >> - In the linux.conf for qt4-embedded-gles the libraries to
> >include are
> >> listed as GLES_CM
> >>
> >> This causes the do_configure stage to fail for the qt4-embedded-
> >gles recipe
> >> on dra7xx-evm because it cannot find the GLES_CM library since
> >that library
> >> for those devices is named GLESv1_CM.  I currently have a work
> >around to fix
> >> this configure error of creating a version of the linux.conf for
> >> qt4-embedded-gles that uses for omap-a15 machine types.  This
> >works
> >> (although there is a compile error I am tracking down due to
> >missing pvr2d.h
> >> header files) but I was curious if this is the best way to solve
> >this, or
> >> would it be better to fixup the library name or make symlinks
> >between
> >> libGLES_CM and libGLESv1_CM in the graphics library recipe.
> >>
> >> BTW, some of this may be a moot point because none of the OMAP
> >SGX packages
> >> provide the pvr2d.h header.  So until there is alignment in
> >these packages
> >> the version of Qt used for these devices either needs to be Qt5
> >which
> >> doesn’t have SGX acceleration yet, or the sgx MACHINE_FEATURE
> >should be
> >> removed from the omap-a15 devices.  Thoughts?
> >
> >Qt5 does have GLES acceleation. It can be easily turned on and
> >off, but it's
> >required for QtWebkit, IIRC. Why are you saying there's no SGX
> >acceleration?
> 
> I thought Qt5 required similar patches to use the pvr2d library as Qt4 did.  
> I figured it could find the GLES libraries on it's own though.  Would it 
> have the same issue with the renamed library?
> 
> >
> >As of the question - I'm fine disabling sgx MACHINE_FEATURE for
> >now. Let's
> >talk to the graphics team to see if/when it will be
> >aligned/resolved.
> 
> Or when do we want to change the default Qt to Qt5?  If you are saying the 
> Qt5 can work with our SGX as is then maybe that should be the new default 
> with Wayland/Weston as the window manager.  What are your thoughts?  
> Hopefully Franklin can chime in as well.

As we just discussed on IRC, Qt5 uses GLES2 and the library name is the same 
between libgles-omap3 and omap5-sgx-ddk, so no issues building Qt5 with gles2 
enabled for dra7xx/omap5. There are still some runtime issues expected though.

Looks like Qt5 is becoming a requirement for going forward with the new 
platforms. We need to finish porting remainder of AMSDK to start using Qt5 and 
Wayland/Weston...

-- 
Denys