[Buildroot] [PATCH v8 21/28] xbmc: Add X.org/OpenGL support
Yann E. MORIN
yann.morin.1998 at free.fr
Tue May 20 16:49:24 UTC 2014
Arnout, All,
On 2014-05-20 18:33 +0200, Arnout Vandecappelle spake thusly:
> On 18/05/14 19:29, Yann E. MORIN wrote:
> > Bernd, All,
> >
> > On 2014-05-18 18:58 +0200, Bernd Kuhls spake thusly:
> >> "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote in
> >> news:20140518162900.GA3631 at free.fr:
> >>
> >>> Something like:
> >> [...]
> >>> should do the trick.
> >>
> >> Hi,
> >>
> >> for further comments I posted my current patch here:
> >> http://pastebin.com/zv7jueLB (expires in one week).
> >>
> >> Especially the last "depends on" block looks crude, but seems to work.
> >
> > Yep, it looks too dense. I think we can factor it into:
> >
> > depends on BR2_arm || BR2_i386 || BR2_x86_64
> > depends on HAS_LIBEGL && HAS_LIBGLES \
> > || (BR2_i386 || BR2_x86_64) && HAS_LIBGL
>
> I don't agree with you Yann that the () should be left out here. Not many
> people know enough about the Kconfig logic to be able to be sure about the
> precedence here.
Well, the precedence of the || and && operators is always the same in
virtually all languages: C, shell, java, you-name-it. kconfig does just
abide by the usual standards, here, and it's clearly stated in the
kconfig grammar.
Furthermore, leaving the () would falsely imply that || would have
precedence over &&, which is not the case.
> > So, it first ensures that it is only visible for ARM or x86 (the only
> > archs we currently support SBMC on.)
> >
> > Then, it is available only for EGL+GLES or x86+GL, since EGL+GLES is
> > posible on ARM and x86 alike, but full GL is only possible on x86.
>
> I think there's something more fundamentally inappropriate about the approach
> taken here. I think the way out could be to add auxiliary symbols to identify
> which provider is used. Something like:
>
> config BR2_PACKAGE_XBMC_EGL_GLES
> bool
> default y
> depends on BR2_PACKAGE_HAS_LIBEGL
> depends on BR2_PACKAGE_HAS_LIBGLES
> depends on !BR2_PACKAGE_XBMC_GL # prefer GL if available
>
> config BR2_PACKAGE_XBMC_GL
> bool
Missing 'default y' here too, I guess. ;-)
> depends on BR2_PACKAGE_XORG7
> depends on BR2_PACKAGE_HAS_LIBGL
And as Bernd said, full openGL support in XBMC is not possible on ARM,
so it is missing a dependency on !BR2_arm. But the basis are here,
granted.
> comment "xbmc requires an OpenGL-capable backend"
I think we want to differentiate the full-openGL vs. openGL EGL/GLES
cases, here, since ARM can only work with EGL/GLES, while x86 can use
either. So we'd need a comment for ARM (or any arch that requires
GL/GLES), and another comment for x86 (or any arch that supports both.)
> depends on BR2_USE_MMU
> depends on BR2_arm || BR2_i386 || BR2_x86_64
> depends on !BR2_PACKAGE_XBMC_EGL_GLES
> depends on !BR2_PACKAGE_XBMC_GL
>
> config BR2_PACKAGE_XBMC
> ...
> depends on BR2_PACKAGE_XBMC_EGL_GLES || BR2_PACKAGE_XBMC_GL
Yes, this seems more sound, indeed. I tried to come up with something
like that, but I failed to properly abstract the situation. Your
solution is pretty good, I like it. ;-)
> That also allows you to use these new symbols in the .mk file instead of the
> _HAS_LIBGL which IMHO is not sufficiently accurate and future-safe.
I disagree. _HAS_LIBGL is just that: we do have a libGL implementation
available.
Now, I never managed to grasp all those lib*GL* stuff. What about libGLX?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list