Patchwork RFC regarding glimagesink

login
register
mail settings
Submitter Eric Nelson
Date July 28, 2013, 11:44 p.m.
Message ID <51F5ACD3.8000505@boundarydevices.com>
Download mbox | patch
Permalink /patch/54627/
State Not Applicable
Delegated to: Otavio Salvador
Headers show

Comments

Eric Nelson - July 28, 2013, 11:44 p.m.
Hi all,

I spent some time looking at the internals of glimagesink
yesterday with the thought that it should be capable of
doing some things that our customers are currently doing
via mfw_isink (in the non-X case).

In particular, I was hoping to shoe-horn some element
properties for window positioning.

I had previously noted that the fbCreateWindow() routine
accepts parameters for window positioning, but it was
currently hard-coding things for full-screen:

	https://bitbucket.org/Freescale/gstreamer-gst-plugins-gl/src/1d6c0abf217a90e160fd7e4c45f02a23da974130/gst-libs/gst/gl/gstglwindow_fbES2.c?at=fsl-0.10#cl-321

That module is also trying to configure some properties, so
adding "x,y,w,h" shouldn't be very hard.

Unfortunately, it appears that things are not quite as
they appear. The gstglwindow_fbES2 isn't properly a
gstreamer element, and appears to be invoked in-directly
through the glimagesink element.

Does anybody know of a way to set the properties of the
GstGLWindow element created by the fbES2 module?

If so, can this be done through gst-launch, or only
by an app?

I hacked up a quick test of the idea, as shown in
the attached patch that reads the window "bounds"
from the environment and the results are promising.

I was able to play three instances of 1080P video in
three separate windows and the overall system load
was quite low (~7%).

I did run into a couple of issues, but these are systemic
and didn't stem from this patch:

	- In high-motion sections of video, tearing is evident
	because nothing's doing frame flipping.

	- I had to play whack-a-mole with memory allocation
	failures. I was able to get 2x1080P to run in
	a loop overnight, but attempts to run 3 fail pretty
	quickly after the first iteration. I suspect that
	tuning the various drivers' allocations as done
	in Jack's patch is needed to make this stable:

		https://community.freescale.com/thread/304368

The first of those above highlights the need for a compositing
layer, which clearly needs cooperation of the toolkit used
for the rest of the U/I.

By the way, the attached patch is against branch fsl-0.10
in the Bitbucket tree, which appears to match up with the
Yocto build, but I notice that Jeremy has a patch applied
in the Yocto-0.10.

Is 'fsl-0.10' the right baseline to use for future work?

I'm interested in hearing the experiences of others with
this component.

It seems to me that there's a lot of function in this
code base, but if it's restricted to full-screen operation,
it's not very useful.

That said, I have yet to explore the other elements in the
package.

Regards,


Eric
Rogerio Nunes - July 29, 2013, 2:35 p.m.
Hi Eric,

I've been usually working without X, so don't know much about glimagesink.
I have some comments about bitbuck branches bellow.

On Sun, Jul 28, 2013 at 7:44 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi all,
>
> I spent some time looking at the internals of glimagesink
> yesterday with the thought that it should be capable of
> doing some things that our customers are currently doing
> via mfw_isink (in the non-X case).
>
> In particular, I was hoping to shoe-horn some element
> properties for window positioning.
>
> I had previously noted that the fbCreateWindow() routine
> accepts parameters for window positioning, but it was
> currently hard-coding things for full-screen:
>
>
> https://bitbucket.org/Freescale/gstreamer-gst-plugins-gl/src/1d6c0abf217a90e160fd7e4c45f02a23da974130/gst-libs/gst/gl/gstglwindow_fbES2.c?at=fsl-0.10#cl-321
>
> That module is also trying to configure some properties, so
> adding "x,y,w,h" shouldn't be very hard.
>
> Unfortunately, it appears that things are not quite as
> they appear. The gstglwindow_fbES2 isn't properly a
> gstreamer element, and appears to be invoked in-directly
> through the glimagesink element.
>
> Does anybody know of a way to set the properties of the
> GstGLWindow element created by the fbES2 module?
>
> If so, can this be done through gst-launch, or only
> by an app?
>
> I hacked up a quick test of the idea, as shown in
> the attached patch that reads the window "bounds"
> from the environment and the results are promising.
>
> I was able to play three instances of 1080P video in
> three separate windows and the overall system load
> was quite low (~7%).
>
> I did run into a couple of issues, but these are systemic
> and didn't stem from this patch:
>
>         - In high-motion sections of video, tearing is evident
>         because nothing's doing frame flipping.
>
>         - I had to play whack-a-mole with memory allocation
>         failures. I was able to get 2x1080P to run in
>         a loop overnight, but attempts to run 3 fail pretty
>         quickly after the first iteration. I suspect that
>         tuning the various drivers' allocations as done
>         in Jack's patch is needed to make this stable:
>
>                 https://community.freescale.com/thread/304368
>
> The first of those above highlights the need for a compositing
> layer, which clearly needs cooperation of the toolkit used
> for the rest of the U/I.
>
> By the way, the attached patch is against branch fsl-0.10
> in the Bitbucket tree, which appears to match up with the
> Yocto build, but I notice that Jeremy has a patch applied
> in the Yocto-0.10.
>
> Is 'fsl-0.10' the right baseline to use for future work?

fsl-0.10 - branch with  "as is" code from fsl BSPs.

yocto-0.10 - branch with patch(es) from the poky layer

0.10 - branch to merge fsl-0.10, yocto-0.10, upstream-0.10 and to
refactor the code to port to master (still ongoing)

>
> I'm interested in hearing the experiences of others with
> this component.
>
> It seems to me that there's a lot of function in this
> code base, but if it's restricted to full-screen operation,
> it's not very useful.
>
> That said, I have yet to explore the other elements in the
> package.
>
> Regards,
>
>
> Eric
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
Eric Nelson - July 29, 2013, 3:08 p.m.
Thanks Rogerio,

On 07/29/2013 07:35 AM, Rogerio Nunes wrote:
> Hi Eric,
>
> I've been usually working without X, so don't know much about glimagesink.
> I have some comments about bitbuck branches bellow.
>

Note that my testing was also without X.

> On Sun, Jul 28, 2013 at 7:44 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> Hi all,
>>
>> <snip>
 >>
>> By the way, the attached patch is against branch fsl-0.10
>> in the Bitbucket tree, which appears to match up with the
>> Yocto build, but I notice that Jeremy has a patch applied
>> in the Yocto-0.10.
>>
>> Is 'fsl-0.10' the right baseline to use for future work?
>
> fsl-0.10 - branch with  "as is" code from fsl BSPs.
>
> yocto-0.10 - branch with patch(es) from the poky layer
>
> 0.10 - branch to merge fsl-0.10, yocto-0.10, upstream-0.10 and to
> refactor the code to port to master (still ongoing)
>

That's good to know.

Regards,


Eric
Rogerio Nunes - July 29, 2013, 7:29 p.m.
My apologies, Eric.

I misread your email the first time.

I'm trying a clean build now with master-next, but I'm having dependency issues.
As soon as I fix this I'll look into glimagesink.

On Mon, Jul 29, 2013 at 11:08 AM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Thanks Rogerio,
>
>
> On 07/29/2013 07:35 AM, Rogerio Nunes wrote:
>>
>> Hi Eric,
>>
>> I've been usually working without X, so don't know much about glimagesink.
>> I have some comments about bitbuck branches bellow.
>>
>
> Note that my testing was also without X.
>
>> On Sun, Jul 28, 2013 at 7:44 PM, Eric Nelson
>> <eric.nelson@boundarydevices.com> wrote:
>>>
>>> Hi all,
>>>
>>> <snip>
>
>>>
>>>
>>> By the way, the attached patch is against branch fsl-0.10
>>> in the Bitbucket tree, which appears to match up with the
>>> Yocto build, but I notice that Jeremy has a patch applied
>>> in the Yocto-0.10.
>>>
>>> Is 'fsl-0.10' the right baseline to use for future work?
>>
>>
>> fsl-0.10 - branch with  "as is" code from fsl BSPs.
>>
>> yocto-0.10 - branch with patch(es) from the poky layer
>>
>> 0.10 - branch to merge fsl-0.10, yocto-0.10, upstream-0.10 and to
>> refactor the code to port to master (still ongoing)
>>
>
> That's good to know.
>
> Regards,
>
>
> Eric
>
Eric Nelson - July 29, 2013, 7:54 p.m.
Hi Rogerio,

On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
> My apologies, Eric.
>
> I misread your email the first time.
>
> I'm trying a clean build now with master-next, but I'm having dependency issues.
> As soon as I fix this I'll look into glimagesink.
>
I had some dependency issues as well, and I had to revert
Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
to get past them.

For some reason, with that patch, I was seeing the wayland version
of some libraries, so configure failed on gst-plugins-gl.

Regards,


Eric
Otavio Salvador - July 29, 2013, 8:06 p.m.
On Mon, Jul 29, 2013 at 4:54 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi Rogerio,
>
>
> On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>>
>> My apologies, Eric.
>>
>> I misread your email the first time.
>>
>> I'm trying a clean build now with master-next, but I'm having dependency
>> issues.
>> As soon as I fix this I'll look into glimagesink.
>>
> I had some dependency issues as well, and I had to revert
> Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
> to get past them.
>
> For some reason, with that patch, I was seeing the wayland version
> of some libraries, so configure failed on gst-plugins-gl.

You need to build the system without x11 and wayland distro features;
it should fix the issue.

--
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
Rogerio Nunes - July 29, 2013, 8:06 p.m.
On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi Rogerio,
>
>
> On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>>
>> My apologies, Eric.
>>
>> I misread your email the first time.
>>
>> I'm trying a clean build now with master-next, but I'm having dependency
>> issues.
>> As soon as I fix this I'll look into glimagesink.
>>
> I had some dependency issues as well, and I had to revert
> Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
> to get past them.
>
> For some reason, with that patch, I was seeing the wayland version
> of some libraries, so configure failed on gst-plugins-gl.
>

That's exactly the same issue I'm having here... no fb* symbols in
libEGL, so configure fails to link...

Thanks.

> Regards,
>
>
> Eric
>
Rogerio Nunes - July 29, 2013, 8:11 p.m.
Indeed.

I removed x11 but didn't realize wayland was still there.

DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia
usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc ipv4 ipv6
libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets
libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz
libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn
libc-inet-anl libc-libm libc-locales libc-locale-code libc-memusage
libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn
libc-streams libc-sunrpc libc-utmp libc-utmpx libc-wordexp
libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc
libc-posix-wchar-io pulseaudio sysvinit largefile opengl multiarch
wayland"

Actually I am using the definition I've always used in my local.conf:
DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia
usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc
${DISTRO_FEATURES_LIBC}"

So need to check how wayland is being added now.

Thx

On Mon, Jul 29, 2013 at 4:06 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, Jul 29, 2013 at 4:54 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> Hi Rogerio,
>>
>>
>> On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>>>
>>> My apologies, Eric.
>>>
>>> I misread your email the first time.
>>>
>>> I'm trying a clean build now with master-next, but I'm having dependency
>>> issues.
>>> As soon as I fix this I'll look into glimagesink.
>>>
>> I had some dependency issues as well, and I had to revert
>> Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
>> to get past them.
>>
>> For some reason, with that patch, I was seeing the wayland version
>> of some libraries, so configure failed on gst-plugins-gl.
>
> You need to build the system without x11 and wayland distro features;
> it should fix the issue.
>
> --
> 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
Eric Nelson - July 29, 2013, 8:12 p.m.
On 07/29/2013 01:06 PM, Otavio Salvador wrote:
> On Mon, Jul 29, 2013 at 4:54 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> Hi Rogerio,
>>
>>
>> On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>>>
>>> My apologies, Eric.
>>>
>>> I misread your email the first time.
>>>
>>> I'm trying a clean build now with master-next, but I'm having dependency
>>> issues.
>>> As soon as I fix this I'll look into glimagesink.
>>>
>> I had some dependency issues as well, and I had to revert
>> Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
>> to get past them.
>>
>> For some reason, with that patch, I was seeing the wayland version
>> of some libraries, so configure failed on gst-plugins-gl.
>
> You need to build the system without x11 and wayland distro features;
> it should fix the issue.
>

I tried figuring out where/how DISTRO_FEATURES gets set, but
kinda got lost in the structure.

Does something need to be defined to prevent Wayland from leaking
into the image? I certainly didn't **ask** for it...

I'm still quite the n00b, but don't see anything in my
image file:

IMAGE_FEATURES += "splash package-management ssh-server-openssh"

# In case we have X11 enabled, provide a working session for use
IMAGE_FEATURES += "${@base_contains("DISTRO_FEATURES", "x11", 
"x11-base", "", d)}"

LICENSE = "MIT"

inherit core-image

CORE_IMAGE_EXTRA_INSTALL += " \
     gpu-viv-bin-mx6q \
     packagegroup-fsl-gstreamer \
     i2c-tools \
     iperf \
     strace \
     net-tools \
     psmisc \
"
Rogerio Nunes - July 29, 2013, 8:24 p.m.
On Mon, Jul 29, 2013 at 4:12 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> On 07/29/2013 01:06 PM, Otavio Salvador wrote:
>>
>> On Mon, Jul 29, 2013 at 4:54 PM, Eric Nelson
>> <eric.nelson@boundarydevices.com> wrote:
>>>
>>> Hi Rogerio,
>>>
>>>
>>> On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>>>>
>>>>
>>>> My apologies, Eric.
>>>>
>>>> I misread your email the first time.
>>>>
>>>> I'm trying a clean build now with master-next, but I'm having dependency
>>>> issues.
>>>> As soon as I fix this I'll look into glimagesink.
>>>>
>>> I had some dependency issues as well, and I had to revert
>>> Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
>>> to get past them.
>>>
>>> For some reason, with that patch, I was seeing the wayland version
>>> of some libraries, so configure failed on gst-plugins-gl.
>>
>>
>> You need to build the system without x11 and wayland distro features;
>> it should fix the issue.
>>
>
> I tried figuring out where/how DISTRO_FEATURES gets set, but
> kinda got lost in the structure.
>

Wayland seems to be the default for poky:
poky/meta-yocto/conf/distro/poky.conf:DISTRO_FEATURES_append = "
largefile opengl multiarch wayland"

> Does something need to be defined to prevent Wayland from leaking
> into the image? I certainly didn't **ask** for it...
>

I'm not sure what to do now... as wayland is an append, even if we
overwrite the whole DISTRO_FEATURES in local.conf, poky will append
the string anyway...
It seems to me it's getting harder and harder to work with poky out of
an X environment.

> I'm still quite the n00b, but don't see anything in my
> image file:
>
> IMAGE_FEATURES += "splash package-management ssh-server-openssh"
>
> # In case we have X11 enabled, provide a working session for use
> IMAGE_FEATURES += "${@base_contains("DISTRO_FEATURES", "x11", "x11-base",
> "", d)}"
>
> LICENSE = "MIT"
>
> inherit core-image
>
> CORE_IMAGE_EXTRA_INSTALL += " \
>     gpu-viv-bin-mx6q \
>     packagegroup-fsl-gstreamer \
>     i2c-tools \
>     iperf \
>     strace \
>     net-tools \
>     psmisc \
> "
>
Rogerio Nunes - July 29, 2013, 8:28 p.m.
I meant: "out of an X-LIKE environment" ;)

On Mon, Jul 29, 2013 at 4:24 PM, Rogerio Nunes <ronunes@gmail.com> wrote:
> On Mon, Jul 29, 2013 at 4:12 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> On 07/29/2013 01:06 PM, Otavio Salvador wrote:
>>>
>>> On Mon, Jul 29, 2013 at 4:54 PM, Eric Nelson
>>> <eric.nelson@boundarydevices.com> wrote:
>>>>
>>>> Hi Rogerio,
>>>>
>>>>
>>>> On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>>>>>
>>>>>
>>>>> My apologies, Eric.
>>>>>
>>>>> I misread your email the first time.
>>>>>
>>>>> I'm trying a clean build now with master-next, but I'm having dependency
>>>>> issues.
>>>>> As soon as I fix this I'll look into glimagesink.
>>>>>
>>>> I had some dependency issues as well, and I had to revert
>>>> Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
>>>> to get past them.
>>>>
>>>> For some reason, with that patch, I was seeing the wayland version
>>>> of some libraries, so configure failed on gst-plugins-gl.
>>>
>>>
>>> You need to build the system without x11 and wayland distro features;
>>> it should fix the issue.
>>>
>>
>> I tried figuring out where/how DISTRO_FEATURES gets set, but
>> kinda got lost in the structure.
>>
>
> Wayland seems to be the default for poky:
> poky/meta-yocto/conf/distro/poky.conf:DISTRO_FEATURES_append = "
> largefile opengl multiarch wayland"
>
>> Does something need to be defined to prevent Wayland from leaking
>> into the image? I certainly didn't **ask** for it...
>>
>
> I'm not sure what to do now... as wayland is an append, even if we
> overwrite the whole DISTRO_FEATURES in local.conf, poky will append
> the string anyway...
> It seems to me it's getting harder and harder to work with poky out of
> an X environment.
>
>> I'm still quite the n00b, but don't see anything in my
>> image file:
>>
>> IMAGE_FEATURES += "splash package-management ssh-server-openssh"
>>
>> # In case we have X11 enabled, provide a working session for use
>> IMAGE_FEATURES += "${@base_contains("DISTRO_FEATURES", "x11", "x11-base",
>> "", d)}"
>>
>> LICENSE = "MIT"
>>
>> inherit core-image
>>
>> CORE_IMAGE_EXTRA_INSTALL += " \
>>     gpu-viv-bin-mx6q \
>>     packagegroup-fsl-gstreamer \
>>     i2c-tools \
>>     iperf \
>>     strace \
>>     net-tools \
>>     psmisc \
>> "
>>
Thomas Senyk - July 30, 2013, 9:06 a.m.
On Monday, 29 July, 2013 16:06:17 Rogerio Nunes wrote:
> On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
> 
> <eric.nelson@boundarydevices.com> wrote:
> > Hi Rogerio,
> > 
> > On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
> >> My apologies, Eric.
> >> 
> >> I misread your email the first time.
> >> 
> >> I'm trying a clean build now with master-next, but I'm having dependency
> >> issues.
> >> As soon as I fix this I'll look into glimagesink.
> > 
> > I had some dependency issues as well, and I had to revert
> > Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
> > to get past them.
> > 
> > For some reason, with that patch, I was seeing the wayland version
> > of some libraries, so configure failed on gst-plugins-gl.
> 
> That's exactly the same issue I'm having here... no fb* symbols in
> libEGL, so configure fails to link...

I wonder if the fb* symbols should actually vanish?

In a wl enabled version I've tested before I had both, wl_* and fb* symbols.
  .. and IMO this is the right way, because it enabled you to have opengl-
based compositors and wayland-egl based clients with the same libraries.


Also from a include/define perspective only if EGL_API_FB is set, it makes 
sense to set WL_EGL_PLATFORM.
quote from eglvivante.h:

...
#elif defined(LINUX) && defined(EGL_API_FB) && !defined(__APPLE__)

#if defined(WL_EGL_PLATFORM)
...


Does anyone know the reason why fb* symbols got removed from libEGL-wl.so?

Greet
Thomas

> 
> Thanks.
> 
> > Regards,
> > 
> > 
> > Eric
> 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
Abhijit Potnis - July 30, 2013, 9:52 a.m.
On Tue, Jul 30, 2013 at 2:06 AM, Thomas Senyk
<thomas.senyk@pelagicore.com>wrote:

> On Monday, 29 July, 2013 16:06:17 Rogerio Nunes wrote:
> > On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
> >
> > <eric.nelson@boundarydevices.com> wrote:
> > > Hi Rogerio,
> > >
> > > On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
> > >> My apologies, Eric.
> > >>
> > >> I misread your email the first time.
> > >>
> > >> I'm trying a clean build now with master-next, but I'm having
> dependency
> > >> issues.
> > >> As soon as I fix this I'll look into glimagesink.
> > >
> > > I had some dependency issues as well, and I had to revert
> > > Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
> > > to get past them.
> > >
> > > For some reason, with that patch, I was seeing the wayland version
> > > of some libraries, so configure failed on gst-plugins-gl.
> >
> > That's exactly the same issue I'm having here... no fb* symbols in
> > libEGL, so configure fails to link...
>
> I wonder if the fb* symbols should actually vanish?
>
> In a wl enabled version I've tested before I had both, wl_* and fb*
> symbols.
>   .. and IMO this is the right way, because it enabled you to have opengl-
> based compositors and wayland-egl based clients with the same libraries.
>
>
> Also from a include/define perspective only if EGL_API_FB is set, it makes
> sense to set WL_EGL_PLATFORM.
> quote from eglvivante.h:
>
> ...
> #elif defined(LINUX) && defined(EGL_API_FB) && !defined(__APPLE__)
>
> #if defined(WL_EGL_PLATFORM)
> ...
>
>
> Does anyone know the reason why fb* symbols got removed from libEGL-wl.so?
>

Freescale probides framebuffer based backend implementation for weston,
which run
with libEGL-wl.so. So this does equate to libEGL-wl.so having fb* symbols.
I did check
that a few functions like `fbGetDisplayByIndex`  `fbGetDisplayGeometry'
`fbCreateWindow'
are supported over libEGL-wl.so

I used the attached sample code to test fb on the imx6qsaberlite.

arm-none-linux-gnueabi-g++ fb_test.c -o n900gles -lEGL-wl -lGAL-wl
-lgc_wayland_protocol -lwayland-client -lffi -lwayland-server

Note the above never ending list of libs to link to. That where it gets
messy. GAL-wl lib throws in
dependencies over to Wayland client and server library and I ended up
adding them.

Regards,
Abhijit

>
> Greet
> Thomas
>
> >
> > Thanks.
> >
> > > Regards,
> > >
> > >
> > > Eric
> >
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
Thomas Senyk - July 30, 2013, 10:58 a.m.
On Tuesday, 30 July, 2013 2:52:38 Abhijit Potnis wrote:
> On Tue, Jul 30, 2013 at 2:06 AM, Thomas Senyk
> 
> <thomas.senyk@pelagicore.com>wrote:
> > On Monday, 29 July, 2013 16:06:17 Rogerio Nunes wrote:
> > > On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
> > > 
> > > <eric.nelson@boundarydevices.com> wrote:
> > > > Hi Rogerio,
> > > > 
> > > > On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
> > > >> My apologies, Eric.
> > > >> 
> > > >> I misread your email the first time.
> > > >> 
> > > >> I'm trying a clean build now with master-next, but I'm having
> > 
> > dependency
> > 
> > > >> issues.
> > > >> As soon as I fix this I'll look into glimagesink.
> > > > 
> > > > I had some dependency issues as well, and I had to revert
> > > > Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
> > > > to get past them.
> > > > 
> > > > For some reason, with that patch, I was seeing the wayland version
> > > > of some libraries, so configure failed on gst-plugins-gl.
> > > 
> > > That's exactly the same issue I'm having here... no fb* symbols in
> > > libEGL, so configure fails to link...
> > 
> > I wonder if the fb* symbols should actually vanish?
> > 
> > In a wl enabled version I've tested before I had both, wl_* and fb*
> > symbols.
> > 
> >   .. and IMO this is the right way, because it enabled you to have opengl-
> > 
> > based compositors and wayland-egl based clients with the same libraries.
> > 
> > 
> > Also from a include/define perspective only if EGL_API_FB is set, it makes
> > sense to set WL_EGL_PLATFORM.
> > quote from eglvivante.h:
> > 
> > ...
> > #elif defined(LINUX) && defined(EGL_API_FB) && !defined(__APPLE__)
> > 
> > #if defined(WL_EGL_PLATFORM)
> > ...
> > 
> > 
> > Does anyone know the reason why fb* symbols got removed from libEGL-wl.so?
> 
> Freescale probides framebuffer based backend implementation for weston,
> which run
> with libEGL-wl.so. So this does equate to libEGL-wl.so having fb* symbols.
> I did check
> that a few functions like `fbGetDisplayByIndex`  `fbGetDisplayGeometry'
> `fbCreateWindow'
> are supported over libEGL-wl.so
> 
> I used the attached sample code to test fb on the imx6qsaberlite.
> 
> arm-none-linux-gnueabi-g++ fb_test.c -o n900gles -lEGL-wl -lGAL-wl
> -lgc_wayland_protocol -lwayland-client -lffi -lwayland-server
> 
> Note the above never ending list of libs to link to. That where it gets
> messy. GAL-wl lib throws in
> dependencies over to Wayland client and server library and I ended up
> adding them.

I though I just tested this and didn't have fb* symbols ..I must have made a 
mistake!
After checking again I see them with objdump -x

So yes all the fb* symbols are present! :)

> 
> Regards,
> Abhijit
> 
> > Greet
> > Thomas
> > 
> > > Thanks.
> > > 
> > > > Regards,
> > > > 
> > > > 
> > > > Eric
> > > 
> > > _______________________________________________
> > > meta-freescale mailing list
> > > meta-freescale@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/meta-freescale
> > 
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
Rogerio Nunes - July 30, 2013, 2:14 p.m.
Just to make sure. What version of the GPU package are you guys using?

I've just uncompressed gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp, and I do not
see any fb* symbols in libEGL-wl.so:
objdump -x libEGL-wl.so | grep -i fb

*EMPTY*

On Tue, Jul 30, 2013 at 6:58 AM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
> On Tuesday, 30 July, 2013 2:52:38 Abhijit Potnis wrote:
>> On Tue, Jul 30, 2013 at 2:06 AM, Thomas Senyk
>>
>> <thomas.senyk@pelagicore.com>wrote:
>> > On Monday, 29 July, 2013 16:06:17 Rogerio Nunes wrote:
>> > > On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
>> > >
>> > > <eric.nelson@boundarydevices.com> wrote:
>> > > > Hi Rogerio,
>> > > >
>> > > > On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>> > > >> My apologies, Eric.
>> > > >>
>> > > >> I misread your email the first time.
>> > > >>
>> > > >> I'm trying a clean build now with master-next, but I'm having
>> >
>> > dependency
>> >
>> > > >> issues.
>> > > >> As soon as I fix this I'll look into glimagesink.
>> > > >
>> > > > I had some dependency issues as well, and I had to revert
>> > > > Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
>> > > > to get past them.
>> > > >
>> > > > For some reason, with that patch, I was seeing the wayland version
>> > > > of some libraries, so configure failed on gst-plugins-gl.
>> > >
>> > > That's exactly the same issue I'm having here... no fb* symbols in
>> > > libEGL, so configure fails to link...
>> >
>> > I wonder if the fb* symbols should actually vanish?
>> >
>> > In a wl enabled version I've tested before I had both, wl_* and fb*
>> > symbols.
>> >
>> >   .. and IMO this is the right way, because it enabled you to have opengl-
>> >
>> > based compositors and wayland-egl based clients with the same libraries.
>> >
>> >
>> > Also from a include/define perspective only if EGL_API_FB is set, it makes
>> > sense to set WL_EGL_PLATFORM.
>> > quote from eglvivante.h:
>> >
>> > ...
>> > #elif defined(LINUX) && defined(EGL_API_FB) && !defined(__APPLE__)
>> >
>> > #if defined(WL_EGL_PLATFORM)
>> > ...
>> >
>> >
>> > Does anyone know the reason why fb* symbols got removed from libEGL-wl.so?
>>
>> Freescale probides framebuffer based backend implementation for weston,
>> which run
>> with libEGL-wl.so. So this does equate to libEGL-wl.so having fb* symbols.
>> I did check
>> that a few functions like `fbGetDisplayByIndex`  `fbGetDisplayGeometry'
>> `fbCreateWindow'
>> are supported over libEGL-wl.so
>>
>> I used the attached sample code to test fb on the imx6qsaberlite.
>>
>> arm-none-linux-gnueabi-g++ fb_test.c -o n900gles -lEGL-wl -lGAL-wl
>> -lgc_wayland_protocol -lwayland-client -lffi -lwayland-server
>>
>> Note the above never ending list of libs to link to. That where it gets
>> messy. GAL-wl lib throws in
>> dependencies over to Wayland client and server library and I ended up
>> adding them.
>
> I though I just tested this and didn't have fb* symbols ..I must have made a
> mistake!
> After checking again I see them with objdump -x
>
> So yes all the fb* symbols are present! :)
>
>>
>> Regards,
>> Abhijit
>>
>> > Greet
>> > Thomas
>> >
>> > > Thanks.
>> > >
>> > > > Regards,
>> > > >
>> > > >
>> > > > Eric
>> > >
>> > > _______________________________________________
>> > > meta-freescale mailing list
>> > > meta-freescale@yoctoproject.org
>> > > https://lists.yoctoproject.org/listinfo/meta-freescale
>> >
>> > _______________________________________________
>> > meta-freescale mailing list
>> > meta-freescale@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/meta-freescale
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
Thomas Senyk - July 30, 2013, 2:38 p.m.
http://download.ossystems.com.br/bsp/freescale/source/gpu-viv-wl-bin-mx6q-3.0.35-4.0.0.bin

I haven't seen the 3.5.7 drivers yet.
Maybe freescale removed the fb* symbols in that version?

On Tuesday, 30 July, 2013 10:14:10 Rogerio Nunes wrote:
> Just to make sure. What version of the GPU package are you guys using?
> 
> I've just uncompressed gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp, and I do not
> see any fb* symbols in libEGL-wl.so:
> objdump -x libEGL-wl.so | grep -i fb
> 
> *EMPTY*
> 
> On Tue, Jul 30, 2013 at 6:58 AM, Thomas Senyk
> 
> <thomas.senyk@pelagicore.com> wrote:
> > On Tuesday, 30 July, 2013 2:52:38 Abhijit Potnis wrote:
> >> On Tue, Jul 30, 2013 at 2:06 AM, Thomas Senyk
> >> 
> >> <thomas.senyk@pelagicore.com>wrote:
> >> > On Monday, 29 July, 2013 16:06:17 Rogerio Nunes wrote:
> >> > > On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
> >> > > 
> >> > > <eric.nelson@boundarydevices.com> wrote:
> >> > > > Hi Rogerio,
> >> > > > 
> >> > > > On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
> >> > > >> My apologies, Eric.
> >> > > >> 
> >> > > >> I misread your email the first time.
> >> > > >> 
> >> > > >> I'm trying a clean build now with master-next, but I'm having
> >> > 
> >> > dependency
> >> > 
> >> > > >> issues.
> >> > > >> As soon as I fix this I'll look into glimagesink.
> >> > > > 
> >> > > > I had some dependency issues as well, and I had to revert
> >> > > > Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
> >> > > > to get past them.
> >> > > > 
> >> > > > For some reason, with that patch, I was seeing the wayland version
> >> > > > of some libraries, so configure failed on gst-plugins-gl.
> >> > > 
> >> > > That's exactly the same issue I'm having here... no fb* symbols in
> >> > > libEGL, so configure fails to link...
> >> > 
> >> > I wonder if the fb* symbols should actually vanish?
> >> > 
> >> > In a wl enabled version I've tested before I had both, wl_* and fb*
> >> > symbols.
> >> > 
> >> >   .. and IMO this is the right way, because it enabled you to have
> >> >   opengl-
> >> > 
> >> > based compositors and wayland-egl based clients with the same
> >> > libraries.
> >> > 
> >> > 
> >> > Also from a include/define perspective only if EGL_API_FB is set, it
> >> > makes
> >> > sense to set WL_EGL_PLATFORM.
> >> > quote from eglvivante.h:
> >> > 
> >> > ...
> >> > #elif defined(LINUX) && defined(EGL_API_FB) && !defined(__APPLE__)
> >> > 
> >> > #if defined(WL_EGL_PLATFORM)
> >> > ...
> >> > 
> >> > 
> >> > Does anyone know the reason why fb* symbols got removed from
> >> > libEGL-wl.so?
> >> 
> >> Freescale probides framebuffer based backend implementation for weston,
> >> which run
> >> with libEGL-wl.so. So this does equate to libEGL-wl.so having fb*
> >> symbols.
> >> I did check
> >> that a few functions like `fbGetDisplayByIndex`  `fbGetDisplayGeometry'
> >> `fbCreateWindow'
> >> are supported over libEGL-wl.so
> >> 
> >> I used the attached sample code to test fb on the imx6qsaberlite.
> >> 
> >> arm-none-linux-gnueabi-g++ fb_test.c -o n900gles -lEGL-wl -lGAL-wl
> >> -lgc_wayland_protocol -lwayland-client -lffi -lwayland-server
> >> 
> >> Note the above never ending list of libs to link to. That where it gets
> >> messy. GAL-wl lib throws in
> >> dependencies over to Wayland client and server library and I ended up
> >> adding them.
> > 
> > I though I just tested this and didn't have fb* symbols ..I must have made
> > a mistake!
> > After checking again I see them with objdump -x
> > 
> > So yes all the fb* symbols are present! :)
> > 
> >> Regards,
> >> Abhijit
> >> 
> >> > Greet
> >> > Thomas
> >> > 
> >> > > Thanks.
> >> > > 
> >> > > > Regards,
> >> > > > 
> >> > > > 
> >> > > > Eric
> >> > > 
> >> > > _______________________________________________
> >> > > meta-freescale mailing list
> >> > > meta-freescale@yoctoproject.org
> >> > > https://lists.yoctoproject.org/listinfo/meta-freescale
> >> > 
> >> > _______________________________________________
> >> > meta-freescale mailing list
> >> > meta-freescale@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/meta-freescale
> > 
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
Rogerio Nunes - July 30, 2013, 5:26 p.m.
Thanks, Thomas.

Confirming:
fb* symbols present in libEGL-wl.so in
gpu-viv-wl-bin-mx6q-3.0.35-4.0.0, but *not* present in
gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp.

On Tue, Jul 30, 2013 at 10:38 AM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
> http://download.ossystems.com.br/bsp/freescale/source/gpu-viv-wl-bin-mx6q-3.0.35-4.0.0.bin
>
> I haven't seen the 3.5.7 drivers yet.
> Maybe freescale removed the fb* symbols in that version?
>
> On Tuesday, 30 July, 2013 10:14:10 Rogerio Nunes wrote:
>> Just to make sure. What version of the GPU package are you guys using?
>>
>> I've just uncompressed gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp, and I do not
>> see any fb* symbols in libEGL-wl.so:
>> objdump -x libEGL-wl.so | grep -i fb
>>
>> *EMPTY*
>>
>> On Tue, Jul 30, 2013 at 6:58 AM, Thomas Senyk
>>
>> <thomas.senyk@pelagicore.com> wrote:
>> > On Tuesday, 30 July, 2013 2:52:38 Abhijit Potnis wrote:
>> >> On Tue, Jul 30, 2013 at 2:06 AM, Thomas Senyk
>> >>
>> >> <thomas.senyk@pelagicore.com>wrote:
>> >> > On Monday, 29 July, 2013 16:06:17 Rogerio Nunes wrote:
>> >> > > On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
>> >> > >
>> >> > > <eric.nelson@boundarydevices.com> wrote:
>> >> > > > Hi Rogerio,
>> >> > > >
>> >> > > > On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
>> >> > > >> My apologies, Eric.
>> >> > > >>
>> >> > > >> I misread your email the first time.
>> >> > > >>
>> >> > > >> I'm trying a clean build now with master-next, but I'm having
>> >> >
>> >> > dependency
>> >> >
>> >> > > >> issues.
>> >> > > >> As soon as I fix this I'll look into glimagesink.
>> >> > > >
>> >> > > > I had some dependency issues as well, and I had to revert
>> >> > > > Abhijit's wayland patch (78936c1994cb2db102bd200123be976a7c051b98)
>> >> > > > to get past them.
>> >> > > >
>> >> > > > For some reason, with that patch, I was seeing the wayland version
>> >> > > > of some libraries, so configure failed on gst-plugins-gl.
>> >> > >
>> >> > > That's exactly the same issue I'm having here... no fb* symbols in
>> >> > > libEGL, so configure fails to link...
>> >> >
>> >> > I wonder if the fb* symbols should actually vanish?
>> >> >
>> >> > In a wl enabled version I've tested before I had both, wl_* and fb*
>> >> > symbols.
>> >> >
>> >> >   .. and IMO this is the right way, because it enabled you to have
>> >> >   opengl-
>> >> >
>> >> > based compositors and wayland-egl based clients with the same
>> >> > libraries.
>> >> >
>> >> >
>> >> > Also from a include/define perspective only if EGL_API_FB is set, it
>> >> > makes
>> >> > sense to set WL_EGL_PLATFORM.
>> >> > quote from eglvivante.h:
>> >> >
>> >> > ...
>> >> > #elif defined(LINUX) && defined(EGL_API_FB) && !defined(__APPLE__)
>> >> >
>> >> > #if defined(WL_EGL_PLATFORM)
>> >> > ...
>> >> >
>> >> >
>> >> > Does anyone know the reason why fb* symbols got removed from
>> >> > libEGL-wl.so?
>> >>
>> >> Freescale probides framebuffer based backend implementation for weston,
>> >> which run
>> >> with libEGL-wl.so. So this does equate to libEGL-wl.so having fb*
>> >> symbols.
>> >> I did check
>> >> that a few functions like `fbGetDisplayByIndex`  `fbGetDisplayGeometry'
>> >> `fbCreateWindow'
>> >> are supported over libEGL-wl.so
>> >>
>> >> I used the attached sample code to test fb on the imx6qsaberlite.
>> >>
>> >> arm-none-linux-gnueabi-g++ fb_test.c -o n900gles -lEGL-wl -lGAL-wl
>> >> -lgc_wayland_protocol -lwayland-client -lffi -lwayland-server
>> >>
>> >> Note the above never ending list of libs to link to. That where it gets
>> >> messy. GAL-wl lib throws in
>> >> dependencies over to Wayland client and server library and I ended up
>> >> adding them.
>> >
>> > I though I just tested this and didn't have fb* symbols ..I must have made
>> > a mistake!
>> > After checking again I see them with objdump -x
>> >
>> > So yes all the fb* symbols are present! :)
>> >
>> >> Regards,
>> >> Abhijit
>> >>
>> >> > Greet
>> >> > Thomas
>> >> >
>> >> > > Thanks.
>> >> > >
>> >> > > > Regards,
>> >> > > >
>> >> > > >
>> >> > > > Eric
>> >> > >
>> >> > > _______________________________________________
>> >> > > meta-freescale mailing list
>> >> > > meta-freescale@yoctoproject.org
>> >> > > https://lists.yoctoproject.org/listinfo/meta-freescale
>> >> >
>> >> > _______________________________________________
>> >> > meta-freescale mailing list
>> >> > meta-freescale@yoctoproject.org
>> >> > https://lists.yoctoproject.org/listinfo/meta-freescale
>> >
>> > _______________________________________________
>> > meta-freescale mailing list
>> > meta-freescale@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/meta-freescale
Abhijit Potnis - Aug. 1, 2013, 8:47 a.m.
Hello Rogeiro,

Where can I find the gpu-viv-bin-mx6q-3.5.7-1.0.0-
hfp. release ?

-Abhijit


On Tue, Jul 30, 2013 at 10:56 PM, Rogerio Nunes <ronunes@gmail.com> wrote:

> Thanks, Thomas.
>
> Confirming:
> fb* symbols present in libEGL-wl.so in
> gpu-viv-wl-bin-mx6q-3.0.35-4.0.0, but *not* present in
> gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp.
>
> On Tue, Jul 30, 2013 at 10:38 AM, Thomas Senyk
> <thomas.senyk@pelagicore.com> wrote:
> >
> http://download.ossystems.com.br/bsp/freescale/source/gpu-viv-wl-bin-mx6q-3.0.35-4.0.0.bin
> >
> > I haven't seen the 3.5.7 drivers yet.
> > Maybe freescale removed the fb* symbols in that version?
> >
> > On Tuesday, 30 July, 2013 10:14:10 Rogerio Nunes wrote:
> >> Just to make sure. What version of the GPU package are you guys using?
> >>
> >> I've just uncompressed gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp, and I do not
> >> see any fb* symbols in libEGL-wl.so:
> >> objdump -x libEGL-wl.so | grep -i fb
> >>
> >> *EMPTY*
> >>
> >> On Tue, Jul 30, 2013 at 6:58 AM, Thomas Senyk
> >>
> >> <thomas.senyk@pelagicore.com> wrote:
> >> > On Tuesday, 30 July, 2013 2:52:38 Abhijit Potnis wrote:
> >> >> On Tue, Jul 30, 2013 at 2:06 AM, Thomas Senyk
> >> >>
> >> >> <thomas.senyk@pelagicore.com>wrote:
> >> >> > On Monday, 29 July, 2013 16:06:17 Rogerio Nunes wrote:
> >> >> > > On Mon, Jul 29, 2013 at 3:54 PM, Eric Nelson
> >> >> > >
> >> >> > > <eric.nelson@boundarydevices.com> wrote:
> >> >> > > > Hi Rogerio,
> >> >> > > >
> >> >> > > > On 07/29/2013 12:29 PM, Rogerio Nunes wrote:
> >> >> > > >> My apologies, Eric.
> >> >> > > >>
> >> >> > > >> I misread your email the first time.
> >> >> > > >>
> >> >> > > >> I'm trying a clean build now with master-next, but I'm having
> >> >> >
> >> >> > dependency
> >> >> >
> >> >> > > >> issues.
> >> >> > > >> As soon as I fix this I'll look into glimagesink.
> >> >> > > >
> >> >> > > > I had some dependency issues as well, and I had to revert
> >> >> > > > Abhijit's wayland patch
> (78936c1994cb2db102bd200123be976a7c051b98)
> >> >> > > > to get past them.
> >> >> > > >
> >> >> > > > For some reason, with that patch, I was seeing the wayland
> version
> >> >> > > > of some libraries, so configure failed on gst-plugins-gl.
> >> >> > >
> >> >> > > That's exactly the same issue I'm having here... no fb* symbols
> in
> >> >> > > libEGL, so configure fails to link...
> >> >> >
> >> >> > I wonder if the fb* symbols should actually vanish?
> >> >> >
> >> >> > In a wl enabled version I've tested before I had both, wl_* and fb*
> >> >> > symbols.
> >> >> >
> >> >> >   .. and IMO this is the right way, because it enabled you to have
> >> >> >   opengl-
> >> >> >
> >> >> > based compositors and wayland-egl based clients with the same
> >> >> > libraries.
> >> >> >
> >> >> >
> >> >> > Also from a include/define perspective only if EGL_API_FB is set,
> it
> >> >> > makes
> >> >> > sense to set WL_EGL_PLATFORM.
> >> >> > quote from eglvivante.h:
> >> >> >
> >> >> > ...
> >> >> > #elif defined(LINUX) && defined(EGL_API_FB) && !defined(__APPLE__)
> >> >> >
> >> >> > #if defined(WL_EGL_PLATFORM)
> >> >> > ...
> >> >> >
> >> >> >
> >> >> > Does anyone know the reason why fb* symbols got removed from
> >> >> > libEGL-wl.so?
> >> >>
> >> >> Freescale probides framebuffer based backend implementation for
> weston,
> >> >> which run
> >> >> with libEGL-wl.so. So this does equate to libEGL-wl.so having fb*
> >> >> symbols.
> >> >> I did check
> >> >> that a few functions like `fbGetDisplayByIndex`
>  `fbGetDisplayGeometry'
> >> >> `fbCreateWindow'
> >> >> are supported over libEGL-wl.so
> >> >>
> >> >> I used the attached sample code to test fb on the imx6qsaberlite.
> >> >>
> >> >> arm-none-linux-gnueabi-g++ fb_test.c -o n900gles -lEGL-wl -lGAL-wl
> >> >> -lgc_wayland_protocol -lwayland-client -lffi -lwayland-server
> >> >>
> >> >> Note the above never ending list of libs to link to. That where it
> gets
> >> >> messy. GAL-wl lib throws in
> >> >> dependencies over to Wayland client and server library and I ended up
> >> >> adding them.
> >> >
> >> > I though I just tested this and didn't have fb* symbols ..I must have
> made
> >> > a mistake!
> >> > After checking again I see them with objdump -x
> >> >
> >> > So yes all the fb* symbols are present! :)
> >> >
> >> >> Regards,
> >> >> Abhijit
> >> >>
> >> >> > Greet
> >> >> > Thomas
> >> >> >
> >> >> > > Thanks.
> >> >> > >
> >> >> > > > Regards,
> >> >> > > >
> >> >> > > >
> >> >> > > > Eric
> >> >> > >
> >> >> > > _______________________________________________
> >> >> > > meta-freescale mailing list
> >> >> > > meta-freescale@yoctoproject.org
> >> >> > > https://lists.yoctoproject.org/listinfo/meta-freescale
> >> >> >
> >> >> > _______________________________________________
> >> >> > meta-freescale mailing list
> >> >> > meta-freescale@yoctoproject.org
> >> >> > https://lists.yoctoproject.org/listinfo/meta-freescale
> >> >
> >> > _______________________________________________
> >> > meta-freescale mailing list
> >> > meta-freescale@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/meta-freescale
>
Otavio Salvador - Aug. 1, 2013, 12:50 p.m.
On Thu, Aug 1, 2013 at 5:47 AM, Abhijit Potnis <abhijitpotnis@gmail.com> wrote:
> Hello Rogeiro,
>
> Where can I find the gpu-viv-bin-mx6q-3.5.7-1.0.0-
> hfp. release ?

master-next has it.
Rogerio Nunes - Aug. 1, 2013, 1:05 p.m.
You can download from here:
http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp.bin



On Thu, Aug 1, 2013 at 8:50 AM, Otavio Salvador <otavio@ossystems.com.br>wrote:

> On Thu, Aug 1, 2013 at 5:47 AM, Abhijit Potnis <abhijitpotnis@gmail.com>
> wrote:
> > Hello Rogeiro,
> >
> > Where can I find the gpu-viv-bin-mx6q-3.5.7-1.0.0-
> > hfp. release ?
>
> master-next has it.
>
> --
> 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
>

Patch

From 409464fc3f49eadac4bf3b7a050b76ab419303a0 Mon Sep 17 00:00:00 2001
From: Eric Nelson <eric.nelson@boundarydevices.com>
Date: Sun, 28 Jul 2013 15:09:19 -0700
Subject: [PATCH] gstglwindow_fbES2: allow window size/position to be specified
 through the environment

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
 gst-libs/gst/gl/gstglwindow_fbES2.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gst-libs/gst/gl/gstglwindow_fbES2.c b/gst-libs/gst/gl/gstglwindow_fbES2.c
index 57c02e1..2fb86e2 100644
--- a/gst-libs/gst/gl/gstglwindow_fbES2.c
+++ b/gst-libs/gst/gl/gstglwindow_fbES2.c
@@ -297,6 +297,8 @@  gst_gl_window_new (gulong external_gl_context)
   EGLConfig config;
 
   int index = 0;
+  int x=-1,y=-1,w=0,h=0;
+  char const *bounds;
 
   setlocale (LC_NUMERIC, "C");
 
@@ -319,6 +321,11 @@  gst_gl_window_new (gulong external_gl_context)
   }
 
   priv->internal_win_id = fbCreateWindow (priv->device, -1, -1, 0, 0);
+  bounds=getenv("bounds");
+  if (bounds) {
+	  sscanf(bounds,"%ux%u+%u+%u",&w,&h,&x,&y);
+  }
+  priv->internal_win_id = fbCreateWindow (priv->device, x, y, w, h);
 
   fbGetDisplayGeometry (priv->device, &priv->device_width,
       &priv->device_height);
-- 
1.8.1.2