* RFC regarding glimagesink
@ 2013-07-28 23:44 Eric Nelson
2013-07-29 14:35 ` Rogerio Nunes
0 siblings, 1 reply; 20+ messages in thread
From: Eric Nelson @ 2013-07-28 23:44 UTC (permalink / raw)
To: meta-freescale
[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]
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
[-- Attachment #2: 0001-gstglwindow_fbES2-allow-window-size-position-to-be-s.patch --]
[-- Type: text/x-diff, Size: 1265 bytes --]
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
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-28 23:44 RFC regarding glimagesink Eric Nelson
@ 2013-07-29 14:35 ` Rogerio Nunes
2013-07-29 15:08 ` Eric Nelson
0 siblings, 1 reply; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-29 14:35 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 14:35 ` Rogerio Nunes
@ 2013-07-29 15:08 ` Eric Nelson
2013-07-29 19:29 ` Rogerio Nunes
0 siblings, 1 reply; 20+ messages in thread
From: Eric Nelson @ 2013-07-29 15:08 UTC (permalink / raw)
To: Rogerio Nunes; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 15:08 ` Eric Nelson
@ 2013-07-29 19:29 ` Rogerio Nunes
2013-07-29 19:54 ` Eric Nelson
0 siblings, 1 reply; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-29 19:29 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 19:29 ` Rogerio Nunes
@ 2013-07-29 19:54 ` Eric Nelson
2013-07-29 20:06 ` Otavio Salvador
2013-07-29 20:06 ` Rogerio Nunes
0 siblings, 2 replies; 20+ messages in thread
From: Eric Nelson @ 2013-07-29 19:54 UTC (permalink / raw)
To: Rogerio Nunes; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 19:54 ` Eric Nelson
@ 2013-07-29 20:06 ` Otavio Salvador
2013-07-29 20:11 ` Rogerio Nunes
2013-07-29 20:12 ` Eric Nelson
2013-07-29 20:06 ` Rogerio Nunes
1 sibling, 2 replies; 20+ messages in thread
From: Otavio Salvador @ 2013-07-29 20:06 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 19:54 ` Eric Nelson
2013-07-29 20:06 ` Otavio Salvador
@ 2013-07-29 20:06 ` Rogerio Nunes
2013-07-30 9:06 ` Thomas Senyk
1 sibling, 1 reply; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-29 20:06 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 20:06 ` Otavio Salvador
@ 2013-07-29 20:11 ` Rogerio Nunes
2013-07-29 20:12 ` Eric Nelson
1 sibling, 0 replies; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-29 20:11 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 20:06 ` Otavio Salvador
2013-07-29 20:11 ` Rogerio Nunes
@ 2013-07-29 20:12 ` Eric Nelson
2013-07-29 20:24 ` Rogerio Nunes
1 sibling, 1 reply; 20+ messages in thread
From: Eric Nelson @ 2013-07-29 20:12 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
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 \
"
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 20:12 ` Eric Nelson
@ 2013-07-29 20:24 ` Rogerio Nunes
2013-07-29 20:28 ` Rogerio Nunes
0 siblings, 1 reply; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-29 20:24 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale, Otavio Salvador
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 \
> "
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 20:24 ` Rogerio Nunes
@ 2013-07-29 20:28 ` Rogerio Nunes
0 siblings, 0 replies; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-29 20:28 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale, Otavio Salvador
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 \
>> "
>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-29 20:06 ` Rogerio Nunes
@ 2013-07-30 9:06 ` Thomas Senyk
2013-07-30 9:52 ` Abhijit Potnis
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Senyk @ 2013-07-30 9:06 UTC (permalink / raw)
To: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-30 9:06 ` Thomas Senyk
@ 2013-07-30 9:52 ` Abhijit Potnis
2013-07-30 10:58 ` Thomas Senyk
0 siblings, 1 reply; 20+ messages in thread
From: Abhijit Potnis @ 2013-07-30 9:52 UTC (permalink / raw)
To: Thomas Senyk; +Cc: meta-freescale
[-- Attachment #1.1: Type: text/plain, Size: 2828 bytes --]
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
>
[-- Attachment #1.2: Type: text/html, Size: 4263 bytes --]
[-- Attachment #2: fb_test.c --]
[-- Type: text/x-csrc, Size: 5289 bytes --]
#include <stdio.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>
#include <errno.h>
#include <unistd.h>
#include <sys/ioctl.h>
#define LINUX
#define EGL_API_FB
#include <EGL/egl.h>
#include <GLES2/gl2.h>
#include <GLES2/gl2ext.h>
#include <EGL/eglvivante.h>
int
main( int argc, char *argv[] )
{
int fd;
struct fb_fix_screeninfo finfo;
struct fb_var_screeninfo vinfo;
void *fb;
int w, h;
int i, j;
int size;
int ret;
EGLNativeDisplayType eglNativeDisplay = fbGetDisplayByIndex( 0 );
int Width = 0, Height = 0;
fbGetDisplayGeometry( eglNativeDisplay, &Width, &Height);
printf( "Width = %d \n Height = %d\n", Width, Height);
fb = fbCreateWindow( eglNativeDisplay, 0, 0, Width , Height );
w = Width;
h = Height;
printf( "w %d, h%d\n", w, h );
printf("MMSFBDev: var screen info ------------\n");
printf(" xres = %d\n", vinfo.xres);
printf(" yres = %d\n", vinfo.yres);
printf(" xres_virtual = %d\n", vinfo.xres_virtual);
printf(" yres_virtual = %d\n", vinfo.yres_virtual);
printf(" xoffset = %d\n", vinfo.xoffset);
printf(" yoffset = %d\n", vinfo.yoffset);
printf(" bits_per_pixel = %d\n", vinfo.bits_per_pixel);
printf(" grayscale = %d\n", vinfo.grayscale);
printf(" red = %d(offs=%d)\n", vinfo.red.length, vinfo.red.offset);
printf(" green = %d(offs=%d)\n", vinfo.green.length, vinfo.green.offset);
printf(" blue = %d(offs=%d)\n", vinfo.blue.length, vinfo.blue.offset);
printf(" transp = %d(offs=%d)\n", vinfo.transp.length, vinfo.transp.offset);
printf(" nonstd = %d\n", vinfo.nonstd);
printf(" activate = %d\n", vinfo.activate);
printf(" height = %d\n", vinfo.height);
printf(" width = %d\n", vinfo.width);
printf(" accel_flags = %d\n", vinfo.accel_flags);
printf(" pixclock = %d\n", vinfo.pixclock);
printf(" left_margin = %d\n", vinfo.left_margin);
printf(" right_margin = %d\n", vinfo.right_margin);
printf(" upper_margin = %d\n", vinfo.upper_margin);
printf(" lower_margin = %d\n", vinfo.lower_margin);
printf(" hsync_len = %d\n", vinfo.hsync_len);
printf(" vsync_len = %d\n", vinfo.vsync_len);
printf(" sync = %d\n", vinfo.sync);
printf(" vmode = %d\n", vinfo.vmode);
printf(" rotate = %d\n", vinfo.rotate);
printf(" accel_flags = %d\n", vinfo.accel_flags);
printf(" reserved[5] = %d, %d, %d, %d, %d\n", vinfo.reserved[0], vinfo.reserved[1], vinfo.reserved[2], vinfo.reserved[3], vinfo.reserved[4]);
printf("MMSFBDev: var screen info ------------\n");
int VFL = vinfo.lower_margin + vinfo.upper_margin + vinfo.vsync_len + vinfo.yres;
int HFL = vinfo.right_margin + vinfo.left_margin + vinfo.hsync_len + vinfo.xres;
printf(" HFL = %d\n", HFL);
printf(" VFL = %d\n", VFL);
if ( HFL > 0 && VFL > 0 && vinfo.pixclock > 0 )
{
float refresh_rate = (1000000.0F * ( 1000000.0F / vinfo.pixclock )) / ( HFL * VFL ) ;
printf(" Refresh Rate = %f\n", refresh_rate);
}
else
{
printf(" Refresh Rate = unknown\n");
}
if ( argc == 2 ) {
#define BUF_SIZE 1280
static unsigned int buf[BUF_SIZE];
for ( i = 0; i < BUF_SIZE; i++ ) {
buf[i] = 0x0000FF00 | (i & 0xFF);
}
for ( i = 0; i < 390; i++ ) {
size += write( fd, buf, BUF_SIZE );
lseek( fd, (2048 - 1280), SEEK_CUR );
lseek( fd, 2, SEEK_CUR ); // for test
}
printf( "write size %d\n", size );
} else if ( argc == 3 ) {
unsigned int *vram;
unsigned int *ip;
size = 2048 * 390 * 4;
// do not use shared
// fb = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)
;
fb = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
printf( "get frame buffer -> 0x%08X\n", fb );
if ( fb == (void * ) -1 ) {
printf( "fb mmap error %d (0x%X)\n", errno );
fflush( NULL );
goto err;
}
vram = (unsigned int *) fb;
for ( i = 0; i < 390; i++ ) {
ip = vram;
for ( j = 0; j < 1280; j++ ) {
*ip = 0x00FF0000 | ((i & 0xFF) << 8) | (j & 0xFF
);
ip++;
}
vram += 2048;
}
ret = munmap( fb, 0 );
if ( ret < 0 ) {
printf( "munmap failed %d\n", errno );
}
}
err:
close( fd );
return 0;
}
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-30 9:52 ` Abhijit Potnis
@ 2013-07-30 10:58 ` Thomas Senyk
2013-07-30 14:14 ` Rogerio Nunes
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Senyk @ 2013-07-30 10:58 UTC (permalink / raw)
To: Abhijit Potnis; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-30 10:58 ` Thomas Senyk
@ 2013-07-30 14:14 ` Rogerio Nunes
2013-07-30 14:38 ` Thomas Senyk
0 siblings, 1 reply; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-30 14:14 UTC (permalink / raw)
To: Thomas Senyk; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-30 14:14 ` Rogerio Nunes
@ 2013-07-30 14:38 ` Thomas Senyk
2013-07-30 17:26 ` Rogerio Nunes
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Senyk @ 2013-07-30 14:38 UTC (permalink / raw)
To: Rogerio Nunes; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-30 14:38 ` Thomas Senyk
@ 2013-07-30 17:26 ` Rogerio Nunes
2013-08-01 8:47 ` Abhijit Potnis
0 siblings, 1 reply; 20+ messages in thread
From: Rogerio Nunes @ 2013-07-30 17:26 UTC (permalink / raw)
To: Thomas Senyk; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-07-30 17:26 ` Rogerio Nunes
@ 2013-08-01 8:47 ` Abhijit Potnis
2013-08-01 12:50 ` Otavio Salvador
0 siblings, 1 reply; 20+ messages in thread
From: Abhijit Potnis @ 2013-08-01 8:47 UTC (permalink / raw)
To: Rogerio Nunes; +Cc: meta-freescale
[-- Attachment #1: Type: text/plain, Size: 5241 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 8488 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-08-01 8:47 ` Abhijit Potnis
@ 2013-08-01 12:50 ` Otavio Salvador
2013-08-01 13:05 ` Rogerio Nunes
0 siblings, 1 reply; 20+ messages in thread
From: Otavio Salvador @ 2013-08-01 12:50 UTC (permalink / raw)
To: Abhijit Potnis; +Cc: meta-freescale
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: RFC regarding glimagesink
2013-08-01 12:50 ` Otavio Salvador
@ 2013-08-01 13:05 ` Rogerio Nunes
0 siblings, 0 replies; 20+ messages in thread
From: Rogerio Nunes @ 2013-08-01 13:05 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 1459 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2013-08-01 13:05 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-28 23:44 RFC regarding glimagesink Eric Nelson
2013-07-29 14:35 ` Rogerio Nunes
2013-07-29 15:08 ` Eric Nelson
2013-07-29 19:29 ` Rogerio Nunes
2013-07-29 19:54 ` Eric Nelson
2013-07-29 20:06 ` Otavio Salvador
2013-07-29 20:11 ` Rogerio Nunes
2013-07-29 20:12 ` Eric Nelson
2013-07-29 20:24 ` Rogerio Nunes
2013-07-29 20:28 ` Rogerio Nunes
2013-07-29 20:06 ` Rogerio Nunes
2013-07-30 9:06 ` Thomas Senyk
2013-07-30 9:52 ` Abhijit Potnis
2013-07-30 10:58 ` Thomas Senyk
2013-07-30 14:14 ` Rogerio Nunes
2013-07-30 14:38 ` Thomas Senyk
2013-07-30 17:26 ` Rogerio Nunes
2013-08-01 8:47 ` Abhijit Potnis
2013-08-01 12:50 ` Otavio Salvador
2013-08-01 13:05 ` Rogerio Nunes
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.