All of lore.kernel.org
 help / color / mirror / Atom feed
* [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2
@ 2013-10-24 16:06 Andy Voltz
  2013-10-24 17:47 ` Erik Botö
  2013-10-24 17:47 ` Post Lauren-RAA013
  0 siblings, 2 replies; 5+ messages in thread
From: Andy Voltz @ 2013-10-24 16:06 UTC (permalink / raw)
  To: meta-freescale

I've been integrating the gpu-viv-bin-mx6q binaries from meta-fsl-arm into
Timesys Factory, but I've encountered a linker issue which I think illustrates
non-functional lib{EGL,GAL}-wl in the 3.5.7-1.0.0-alpha.2 version yocto
provides. 

I'm not sure if this is an issue that needs to be fixed, given the impending
jump to 3.10, but I figured I'd share it just in case.

Before getting into further details, it's worth stating that the 3.10 stuff in
master-next is fine (KUDOS!) This is just an issue with the master branch. In
fact, replacing libEGL-wl.so and libGAL-wl.so with the binaries found in the
3.10 version in master-next fixes this issue.

Now the details:
With 3.5.7-1.0.0-alpha.2, linking weston throws several undefined symbol
errors around these symbols:

gcoOS_CapturePointer
gcoOS_CopyPixmapBits
gcoOS_CreateClientBuffer
gcoOS_CreateContext
gcoOS_CreateDrawable
gcoOS_CreatePixmap
gcoOS_CreateWindow
gcoOS_DeinitLocalDisplayInfo
...(46 total, all named gcoOS_*)

Using objdump to compare the symbols in 3.5.7 to those in 3.10 version, all 
of these symbols are defined in the 3.10 version of libGAL-wl.so. They are
either *UND* or not found in the 3.5.7 versions of these binaries.

I've run into this with Timesys tools -- my attempts to build weston in yocto
meta-fsl-arm master have been all unsuccessful--clearly the fixups to weston
in master-next are needed for a start.

For Timesys, I think I'll just drop in the 3.10 gpu-viv binaries, and test
using that. weston is working in our environment with this configuration, but
I need to revisit X, DFB, and fb.
-- 
Andy Voltz
Timesys Corporation


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2
  2013-10-24 16:06 [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2 Andy Voltz
@ 2013-10-24 17:47 ` Erik Botö
  2013-10-24 17:47 ` Post Lauren-RAA013
  1 sibling, 0 replies; 5+ messages in thread
From: Erik Botö @ 2013-10-24 17:47 UTC (permalink / raw)
  To: Andy Voltz; +Cc: meta-freescale@yoctoproject.org

I have seen this with 3.5.7 as well, but 3.10 recipes from master-next
seem ok for me.

Cheers,
Erik Botö

On Thu, Oct 24, 2013 at 6:06 PM, Andy Voltz <andy.voltz@timesys.com> wrote:
> I've been integrating the gpu-viv-bin-mx6q binaries from meta-fsl-arm into
> Timesys Factory, but I've encountered a linker issue which I think illustrates
> non-functional lib{EGL,GAL}-wl in the 3.5.7-1.0.0-alpha.2 version yocto
> provides.
>
> I'm not sure if this is an issue that needs to be fixed, given the impending
> jump to 3.10, but I figured I'd share it just in case.
>
> Before getting into further details, it's worth stating that the 3.10 stuff in
> master-next is fine (KUDOS!) This is just an issue with the master branch. In
> fact, replacing libEGL-wl.so and libGAL-wl.so with the binaries found in the
> 3.10 version in master-next fixes this issue.
>
> Now the details:
> With 3.5.7-1.0.0-alpha.2, linking weston throws several undefined symbol
> errors around these symbols:
>
> gcoOS_CapturePointer
> gcoOS_CopyPixmapBits
> gcoOS_CreateClientBuffer
> gcoOS_CreateContext
> gcoOS_CreateDrawable
> gcoOS_CreatePixmap
> gcoOS_CreateWindow
> gcoOS_DeinitLocalDisplayInfo
> ...(46 total, all named gcoOS_*)
>
> Using objdump to compare the symbols in 3.5.7 to those in 3.10 version, all
> of these symbols are defined in the 3.10 version of libGAL-wl.so. They are
> either *UND* or not found in the 3.5.7 versions of these binaries.
>
> I've run into this with Timesys tools -- my attempts to build weston in yocto
> meta-fsl-arm master have been all unsuccessful--clearly the fixups to weston
> in master-next are needed for a start.
>
> For Timesys, I think I'll just drop in the 3.10 gpu-viv binaries, and test
> using that. weston is working in our environment with this configuration, but
> I need to revisit X, DFB, and fb.
> --
> Andy Voltz
> Timesys Corporation
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2
  2013-10-24 16:06 [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2 Andy Voltz
  2013-10-24 17:47 ` Erik Botö
@ 2013-10-24 17:47 ` Post Lauren-RAA013
  2013-10-24 18:07   ` Andy Voltz
  1 sibling, 1 reply; 5+ messages in thread
From: Post Lauren-RAA013 @ 2013-10-24 17:47 UTC (permalink / raw)
  To: Andy Voltz, meta-freescale@yoctoproject.org

Wayland Weston is fully support in 3.10.9-1.0.0 so it is better to use that version over 3.5.7. There were some additional components that needed updates for Weston to work outside of the graphics package that are in the 3.10.9-1.0.0 alpha release.  These changes are in master-next now.

Lauren

-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Andy Voltz
Sent: Thursday, October 24, 2013 11:06 AM
To: meta-freescale@yoctoproject.org
Subject: [meta-freescale] [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2

I've been integrating the gpu-viv-bin-mx6q binaries from meta-fsl-arm into Timesys Factory, but I've encountered a linker issue which I think illustrates non-functional lib{EGL,GAL}-wl in the 3.5.7-1.0.0-alpha.2 version yocto provides. 

I'm not sure if this is an issue that needs to be fixed, given the impending jump to 3.10, but I figured I'd share it just in case.

Before getting into further details, it's worth stating that the 3.10 stuff in master-next is fine (KUDOS!) This is just an issue with the master branch. In fact, replacing libEGL-wl.so and libGAL-wl.so with the binaries found in the
3.10 version in master-next fixes this issue.

Now the details:
With 3.5.7-1.0.0-alpha.2, linking weston throws several undefined symbol errors around these symbols:

gcoOS_CapturePointer
gcoOS_CopyPixmapBits
gcoOS_CreateClientBuffer
gcoOS_CreateContext
gcoOS_CreateDrawable
gcoOS_CreatePixmap
gcoOS_CreateWindow
gcoOS_DeinitLocalDisplayInfo
...(46 total, all named gcoOS_*)

Using objdump to compare the symbols in 3.5.7 to those in 3.10 version, all of these symbols are defined in the 3.10 version of libGAL-wl.so. They are either *UND* or not found in the 3.5.7 versions of these binaries.

I've run into this with Timesys tools -- my attempts to build weston in yocto meta-fsl-arm master have been all unsuccessful--clearly the fixups to weston in master-next are needed for a start.

For Timesys, I think I'll just drop in the 3.10 gpu-viv binaries, and test using that. weston is working in our environment with this configuration, but I need to revisit X, DFB, and fb.
--
Andy Voltz
Timesys Corporation
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2
  2013-10-24 17:47 ` Post Lauren-RAA013
@ 2013-10-24 18:07   ` Andy Voltz
  2013-10-24 20:32     ` Post Lauren-RAA013
  0 siblings, 1 reply; 5+ messages in thread
From: Andy Voltz @ 2013-10-24 18:07 UTC (permalink / raw)
  To: Post Lauren-RAA013; +Cc: meta-freescale@yoctoproject.org

Hi Lauren,

On Thu, Oct 24, 2013 at 01:47:42PM -0400, Post Lauren-RAA013 wrote:
> Wayland Weston is fully support in 3.10.9-1.0.0 so it is better to use that version over 3.5.7. There were some additional components that needed updates for Weston to work outside of the graphics package that are in the 3.10.9-1.0.0 alpha release.  These changes are in master-next now.
> 

Is it ill-advised to use the gpu-viv-bin-mx6q binaries with the 3.0.35-4.1.0 release? It passed a smoke test with wayland, but I haven't dug in further with X, dfb, fb.

Perhaps we'll only pull in the -wl.so libraries for 4.1.0 for now until 3.10 is non-alpha.

Also, when I tried the vivante samples in a 3.10 master-next build, they seemed to take over the framebuffer. The weston 'simple-egl' client runs in a window without an issue. Can you recommend any other tests from viv_samples, or is this pretty much expected functionality? Just trying to make sure things are working properly in our environment.

Thanks for the clarification.

Regards
-- 
Andy Voltz
Timesys Corporation


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2
  2013-10-24 18:07   ` Andy Voltz
@ 2013-10-24 20:32     ` Post Lauren-RAA013
  0 siblings, 0 replies; 5+ messages in thread
From: Post Lauren-RAA013 @ 2013-10-24 20:32 UTC (permalink / raw)
  To: Andy Voltz; +Cc: meta-freescale@yoctoproject.org

3.10.9-1.0.0 graphics is still p12 based which works with 3.0.35-4.1.0.   3.10.9 beta which is not release yet will not without kernel changes.

simple-shm, simple-egl or any of the weston-examples.

We'll be updating the fsl-gpu-sdk in beta to support wayland-weston.

Lauren


-----Original Message-----
From: Andy Voltz [mailto:andy.voltz@timesys.com] 
Sent: Thursday, October 24, 2013 1:08 PM
To: Post Lauren-RAA013
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2

Hi Lauren,

On Thu, Oct 24, 2013 at 01:47:42PM -0400, Post Lauren-RAA013 wrote:
> Wayland Weston is fully support in 3.10.9-1.0.0 so it is better to use that version over 3.5.7. There were some additional components that needed updates for Weston to work outside of the graphics package that are in the 3.10.9-1.0.0 alpha release.  These changes are in master-next now.
> 

Is it ill-advised to use the gpu-viv-bin-mx6q binaries with the 3.0.35-4.1.0 release? It passed a smoke test with wayland, but I haven't dug in further with X, dfb, fb.

Perhaps we'll only pull in the -wl.so libraries for 4.1.0 for now until 3.10 is non-alpha.

Also, when I tried the vivante samples in a 3.10 master-next build, they seemed to take over the framebuffer. The weston 'simple-egl' client runs in a window without an issue. Can you recommend any other tests from viv_samples, or is this pretty much expected functionality? Just trying to make sure things are working properly in our environment.

Thanks for the clarification.

Regards
-- 
Andy Voltz
Timesys Corporation




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-10-24 20:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-24 16:06 [meta-fsl-arm]: Wayland/Weston issue with gpu-viv-bin-mx6q 3.5.7-1.0.0-alpha.2 Andy Voltz
2013-10-24 17:47 ` Erik Botö
2013-10-24 17:47 ` Post Lauren-RAA013
2013-10-24 18:07   ` Andy Voltz
2013-10-24 20:32     ` Post Lauren-RAA013

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.