Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox