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.nel...@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 > _______________________________________________ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale