From: "Benoît Thébaudeau" <benoit@wsystem.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] gst1-plugins-bad: add support for opengl
Date: Thu, 28 May 2015 16:45:18 +0200 [thread overview]
Message-ID: <556729FE.9040603@wsystem.com> (raw)
In-Reply-To: <87k2w67vg7.fsf@dell.be.48ers.dk>
Dear Peter Korsgaard,
On 2015/05/17 23:20, Peter Korsgaard wrote:
>>>>>> "Beno?t" == Beno?t Th?baudeau <benoit@wsystem.com> writes:
>
> > Commit 83e29f2656a237e2c300d523776868837d3bc646 "gst1-plugins-bad: bump
> > version" (from 1.2.4 to 1.4.1) removed the configuration option for the
> > eglglessink plugin as a consequence of its removal in 1.3.1. However,
> > that commit did not add support for glimagesink, the plugin element to
> > be used as a replacement, which broke support for the EGL/GLES video
> > sink feature in Buildroot.
>
> > This new commit adds support for the OpenGL library and the
> > corresponding gl plugin, including the glimagesink element among others.
>
> > The plugin needs the library, but the library can also be used
> > separately in order to link custom plugins or applications against it.
>
> > The library needs at least one OpenGL API, one OpenGL platform and one
> > compatible window system. The implementations of these requirements that
> > Buildroot can currently provide are:
> > - APIs: OpenGL, OpenGL ES 2.X,
> > - platforms: GLX, EGL,
> > - window systems: X11, Wayland, Dispmanx.
>
> > The wayland configure feature switch is shared between the corresponding
> > OpenGL library window system and the waylandsink plugin.
>
> > This has been tested with videotestsrc/omxmpeg4videodec/omxh264dec and
> > glimagesink on the Raspberry Pi, using OpenGL ES 2.X, EGL and Dispmanx.
>
> First of all, thanks! Sorry, I haven't had time to review and test this
> completely, but here's a bit of feedback already.
You're welcome. Don't worry. Sorry for the late reply.
> > +comment "libraries with external dependencies"
> > +
> > +menu "OpenGL"
>
> Perhaps this should depend on BR2_PACKAGE_HAS_LIBGL ||
> BR2_PACKAGE_HAS_LIBGLES to not clutter the screen when it cannot do
> anything anyway?
Yes, changed in v2.
> Perhaps it should be a menuconfig instead so that there's a
> corresponding kconfig symbol to easily enable/disable it?
Yes, changed in v2.
>> +
> > +config BR2_PACKAGE_GST1_PLUGINS_BAD_HAS_LIB_OPENGL
> > + def_bool BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_HAS_WINDOW
> > +
> > +menu "APIs"
>
> There is a lot of cascading menus which makes it hard to get an
> overview. Perhaps they should be replaced by comments instead
> (E.G. comment "APIs")?
Yes, changed in v2. In order to keep the overview idea, I've also added comments
for hidden options rather than hiding all platforms / window systems under a
single comment if unavailable. This is also more helpful for users to know what
is doable with this library.
>> +
> > +config BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_HAS_API
> > + bool
> > +
> > +config BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_OPENGL
> > + bool "opengl"
> > + depends on BR2_PACKAGE_HAS_LIBGL
> > + select BR2_PACKAGE_LIBGLU
> > + select BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_HAS_API
> > +
> > +config BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_GLES2
> > + bool "gles2"
> > + depends on BR2_PACKAGE_HAS_LIBGLES
> > + select BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_HAS_API
>
> Probably these should be default y so they get enabled if the
> dependencies are present, as that is most likely what the user wants.
>
> Same comments for platforms and window systems.
Yes, changed in v2. For consistency of the OpenGL options, I've also changed
wayland into a dependency for the window system, rather than selecting it.
Otherwise, this would have been confusing, and making it "default y" would have
been too much.
> > +config BR2_PACKAGE_GST1_PLUGINS_BAD_PLUGIN_GL
> > + bool "gl"
> > + depends on BR2_PACKAGE_GST1_PLUGINS_BAD_HAS_LIB_OPENGL
>
> Likewise this should probably be default y.
Yes, changed in v2.
> > +ifeq ($(BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_OPENGL),y)
> > +GST1_PLUGINS_BAD_CONF_OPTS += --enable-opengl
> > +GST1_PLUGINS_BAD_DEPENDENCIES += libgl
>
> I think you are missing libglu here.
Yes, changed in v2.
>> +ifeq ($(BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_GLX),y)
> > +GST1_PLUGINS_BAD_CONF_OPTS += --enable-glx
> > +GST1_PLUGINS_BAD_DEPENDENCIES += xproto_glproto xlib_libX11 xlib_libXrender \
> > + xlib_libXext libeet
>
> libeet? What does that have to do with opengl?
Nothing, removed in v2. It was a leftover of a copy from libevas.
>> +ifeq ($(BR2_PACKAGE_GST1_PLUGINS_BAD_LIB_OPENGL_X11),y)
> > +GST1_PLUGINS_BAD_CONF_OPTS += --enable-x11
> > +GST1_PLUGINS_BAD_DEPENDENCIES += xproto_glproto xlib_libX11 xlib_libXrender \
> > + xlib_libXext libeet
>
> As GLX implies X11 and the dependencies are the same, perhaps we should
> just handle them together? (E.G. move the enable-x11 / disable-x11 up
> to the glx option).
I've reworked the GLX/X11 options and dependencies in v2. The dependencies for
X11 are now lighter, and GLX selects X11.
Note that I have not tested the X11 and Wayland paths other than in menuconfig
(i.e. not built, not run). I didn't know how the sub-packages of X.org are
organized, so I've tried to figure out the requirements from the
gst1-plugins-bad configure script and other packages using X11 with OpenGL. I've
not found real-world defconfigs to test these cases, but if you give me
pointers, I can launch some builds.
Best regards,
Beno?t
next prev parent reply other threads:[~2015-05-28 14:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 14:58 [Buildroot] [PATCH 1/2] gst1-plugins-bad: remove obsolete make rules Benoît Thébaudeau
2015-05-07 14:58 ` [Buildroot] [PATCH 2/2] gst1-plugins-bad: add support for opengl Benoît Thébaudeau
2015-05-17 21:20 ` Peter Korsgaard
2015-05-28 14:45 ` Benoît Thébaudeau [this message]
2015-05-17 21:05 ` [Buildroot] [PATCH 1/2] gst1-plugins-bad: remove obsolete make rules Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=556729FE.9040603@wsystem.com \
--to=benoit@wsystem.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.