[Buildroot] [PATCH v8 21/28] xbmc: Add X.org/OpenGL support
Arnout Vandecappelle
arnout at mind.be
Tue May 20 16:33:10 UTC 2014
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.
>
> 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
depends on BR2_PACKAGE_XORG7
depends on BR2_PACKAGE_HAS_LIBGL
comment "xbmc requires an OpenGL-capable backend"
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
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.
BTW, I don't understand this comment:
# mesa3d provides libgl only with dri drivers which depend on xorg
If that is the case, then it's up to mesa3d to add the required dependencies, no?
Regards,
Arnout
>
> I think it is much cleaner to separate the architectures dependencies
> from the GL dependencies.
>
> Of course, this would probably not scale if we were to support it on
> other archs (eg. PPC), but it will be time to revisit this if/when we
> happen to add that support.
>
> Regards,
> Yann E. MORIN.
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
More information about the buildroot
mailing list