All of 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 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.