From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/6] libdrm: bump and add experimental ARM framebuffer support
Date: Tue, 27 Aug 2013 09:38:33 +0200 [thread overview]
Message-ID: <20130827093833.603e00a5@skate> (raw)
In-Reply-To: <1377373321-29732-2-git-send-email-spenser@gillilanding.com>
Dear Spenser Gilliland,
On Sat, 24 Aug 2013 14:41:56 -0500, Spenser Gilliland wrote:
> The newer versions of libdrm have substantially fewer dependencies as drm is
> moving to be a subsystem for both wayland and Xorg.
>
> Signed-off-by: Spenser Gilliland <spenser@gillilanding.com>
> ---
> package/libdrm/Config.in | 14 +++-----------
> package/libdrm/libdrm.mk | 24 +++++++++---------------
> 2 files changed, 12 insertions(+), 26 deletions(-)
>
> diff --git a/package/libdrm/Config.in b/package/libdrm/Config.in
> index 8bf676b..f976ef1 100644
> --- a/package/libdrm/Config.in
> +++ b/package/libdrm/Config.in
> @@ -1,18 +1,10 @@
> config BR2_PACKAGE_LIBDRM
> bool "libdrm"
> + select BR2_PACKAGE_XLIB_LIBPTHREAD_STUBS
> + select BR2_PACKAGE_LIBATOMIC_OPS
libatomic_ops is not available on all architectures. In the prevous
libdrm code, it was only selected on i386 and x86-64, so it was ok, but
if libatomic_ops is now needed in all cases for libdrm, then you need
to propagate the libatomic_ops dependencies into libdrm, i.e:
depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_sparc || BR2_powerpc || BR2_x86_64
> + select BR2_PACKAGE_XLIB_LIBPCIACCESS if BR2_i386 || BR2_x86_64
> depends on BR2_PACKAGE_XORG7
If libdrm is needed by Wayland, then it sounds strange to require
enabling BR2_PACKAGE_XORG7. When I did the Wayland packaging, there are
a few X.org packages that I moved out of the BR2_PACKAGE_XORG7
condition, maybe we should do the same for libpciaccess and
libpthread-stubs. But ok, this is probably something we can tackle at a
later point, I don't want to require you to solve all problems right
now :)
> depends on BR2_LARGEFILE
> - select BR2_PACKAGE_XPROTO_GLPROTO
> - select BR2_PACKAGE_XPROTO_XF86VIDMODEPROTO
> - select BR2_PACKAGE_XLIB_LIBXXF86VM
> - select BR2_PACKAGE_XLIB_LIBXMU
> - select BR2_PACKAGE_XLIB_LIBPCIACCESS
> - select BR2_PACKAGE_XPROTO_DRI2PROTO
> - select BR2_PACKAGE_XLIB_LIBPTHREAD_STUBS
> - # libatomic_ops is only available on a subset of the supported
> - # architectures, and we make the assumption that the intel
> - # driver can only be used on x86 and x86_64 machines.
> - select BR2_PACKAGE_LIBATOMIC_OPS if (BR2_PACKAGE_XDRIVER_XF86_VIDEO_INTEL && (BR2_i386 || BR2_x86_64))
> help
> Direct Rendering Manager
>
> diff --git a/package/libdrm/libdrm.mk b/package/libdrm/libdrm.mk
> index d3d2b2d..8388e68 100644
> --- a/package/libdrm/libdrm.mk
> +++ b/package/libdrm/libdrm.mk
> @@ -4,7 +4,7 @@
> #
> ################################################################################
>
> -LIBDRM_VERSION = 2.4.38
> +LIBDRM_VERSION = 2.4.46
> LIBDRM_SOURCE = libdrm-$(LIBDRM_VERSION).tar.bz2
> LIBDRM_SITE = http://dri.freedesktop.org/libdrm/
> LIBDRM_LICENSE = MIT
> @@ -12,24 +12,18 @@ LIBDRM_LICENSE = MIT
> LIBDRM_INSTALL_STAGING = YES
>
> LIBDRM_DEPENDENCIES = \
> - xproto_glproto \
> - xproto_xf86vidmodeproto \
> - xlib_libXxf86vm \
> - xlib_libXmu \
> - xlib_libpciaccess \
> - xproto_dri2proto \
> xlib_libpthread-stubs \
> host-pkgconf
>
> -ifeq ($(BR2_PACKAGE_XDRIVER_XF86_VIDEO_INTEL),y)
> -LIBDRM_CONF_OPT += --enable-intel
> -LIBDRM_DEPENDENCIES += libatomic_ops
> -else
> -LIBDRM_CONF_OPT += --disable-intel
> -endif
> +LIBDRM_CONF_OPT = \
> + --disable-cairo-tests \
> + --disable-manpages
>
> -ifneq ($(BR2_PACKAGE_XDRIVER_XF86_VIDEO_ATI),y)
> -LIBDRM_CONF_OPT += --disable-radeon
So those --enable-intel / --disable-radeon things are no longer needed?
> +ifeq ($(BR2_arm),y)
> +LIBDRM_CONF_OPT += \
> + --enable-omap-experimental-api \
> + --enable-exynos-experimental-api \
> + --enable-freedreno-experimental-api
> endif
It seems strange to me to enable those options as soon as we're on ARM.
I think we probably need Config.in sub-options for these.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-08-27 7:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-24 19:41 [Buildroot] [PATCH 0/6] Sunxi fixes, improve Mesa3d Support, and add glmark2 benchmark application Spenser Gilliland
2013-08-24 19:41 ` [Buildroot] [PATCH 1/6] libdrm: bump and add experimental ARM framebuffer support Spenser Gilliland
2013-08-26 17:33 ` Arnout Vandecappelle
2013-08-27 7:38 ` Thomas Petazzoni [this message]
2013-08-27 19:24 ` Spenser Gilliland
2013-08-27 20:42 ` Thomas Petazzoni
2013-08-24 19:41 ` [Buildroot] [PATCH 2/6] sunxi-mali: bug fixes for pc and init script Spenser Gilliland
2013-08-27 7:39 ` Thomas Petazzoni
2013-08-28 11:44 ` Peter Korsgaard
2013-08-24 19:41 ` [Buildroot] [PATCH 3/6] sunxi-cedarx: bump to newer version, use armel2 binaries, add demo Spenser Gilliland
2013-08-24 19:41 ` [Buildroot] [PATCH 4/6] mesa3d: reorganize, modularize, and bump to version 9.1.6 Spenser Gilliland
2013-08-25 6:45 ` Thomas De Schampheleire
2013-08-26 17:27 ` Arnout Vandecappelle
2013-08-27 18:56 ` Spenser Gilliland
2013-08-24 19:42 ` [Buildroot] [PATCH 5/6] libpng12: new package Spenser Gilliland
2013-08-26 17:21 ` Arnout Vandecappelle
2013-08-27 18:58 ` Spenser Gilliland
2013-08-24 19:42 ` [Buildroot] [PATCH 6/6] glmark2: " Spenser Gilliland
2013-08-26 17:43 ` Arnout Vandecappelle
2013-08-27 19:01 ` Spenser Gilliland
2013-08-29 5:35 ` Arnout Vandecappelle
2013-08-29 18:24 ` Spenser Gilliland
2013-08-27 20:48 ` Thomas Petazzoni
2013-09-06 16:35 ` Spenser Gilliland
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=20130827093833.603e00a5@skate \
--to=thomas.petazzoni@free-electrons.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.