[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[Dagg Stompler]

add the X11 driver for odroid c2 boards.

Signed-off-by: Dagg Stompler <daggs@gmx.com>
---
 package/x11r7/Config.in                            |  1 +
 ...001-c2_mali_ddx-support-cross-compilation.patch | 40 ++++++++++++++++++++++
 .../x11r7/xdriver_xf86-video-odroidc2/Config.in    | 13 +++++++
 .../xdriver_xf86-video-odroidc2.hash               |  2 ++
 .../xdriver_xf86-video-odroidc2.mk                 | 24 +++++++++++++
 5 files changed, 80 insertions(+)
 create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
 create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/Config.in
 create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
 create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk

diff --git a/package/x11r7/Config.in b/package/x11r7/Config.in
index 40aa80c..1c5ff7e 100644
--- a/package/x11r7/Config.in
+++ b/package/x11r7/Config.in
@@ -174,6 +174,7 @@ if BR2_PACKAGE_XORG7
 		source package/x11r7/xdriver_xf86-video-neomagic/Config.in
 		source package/x11r7/xdriver_xf86-video-nouveau/Config.in
 		source package/x11r7/xdriver_xf86-video-nv/Config.in
+		source package/x11r7/xdriver_xf86-video-odroidc2/Config.in
 		source package/x11r7/xdriver_xf86-video-openchrome/Config.in
 		source package/x11r7/xdriver_xf86-video-qxl/Config.in
 		source package/x11r7/xdriver_xf86-video-r128/Config.in
diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch b/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
new file mode 100644
index 0000000..c85f38b
--- /dev/null
+++ b/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
@@ -0,0 +1,40 @@
+From 622c02622665c0cbb35433c8f9969d41b25e028a Mon Sep 17 00:00:00 2001
+From: Dagg Stompler <daggs@gmx.com>
+Date: Sat, 6 Aug 2016 09:19:08 +0300
+Subject: [PATCH] c2_mali_ddx: support cross compilation
+
+Signed-off-by: Dagg Stompler <daggs@gmx.com>
+---
+ src/Makefile.am | 2 +-
+ src/Makefile.in | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 7fec079..6b49a16 100755
+--- a/src/Makefile.am
++++ b/src/Makefile.am
+@@ -27,7 +27,7 @@ mali_drv_la_LDFLAGS = -module -avoid-version -L$(MALI_DDK)/lib -lMali -lUMP -lpt
+ mali_drv_ladir = @moduledir@/drivers
+ 
+ AM_CFLAGS = @XORG_CFLAGS@ \
+-	-I/usr/include/libdrm \
++	-I$(SYSROOT)/usr/include/libdrm \
+ 	-I$(MALI_DDK)/include \
+ 	-I$(MALI_DDK)/internal/include/khronos \
+ 	-I$(MALI_DDK)/src/ump/include \
+diff --git a/src/Makefile.in b/src/Makefile.in
+index b30194b..2952cdc 100755
+--- a/src/Makefile.in
++++ b/src/Makefile.in
+@@ -350,7 +350,7 @@ mali_drv_la_LTLIBRARIES = mali_drv.la
+ mali_drv_la_LDFLAGS = -module -avoid-version -L$(MALI_DDK)/lib -lMali -lUMP -lpthread
+ mali_drv_ladir = @moduledir@/drivers
+ AM_CFLAGS = @XORG_CFLAGS@ \
+-	-I/usr/include/libdrm \
++	-I/$(SYSROOT)/usr/include/libdrm \
+ 	-I$(MALI_DDK)/include \
+ 	-I$(MALI_DDK)/internal/include/khronos \
+ 	-I$(MALI_DDK)/src/ump/include \
+-- 
+2.9.2
+
diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/Config.in b/package/x11r7/xdriver_xf86-video-odroidc2/Config.in
new file mode 100644
index 0000000..b2088c8
--- /dev/null
+++ b/package/x11r7/xdriver_xf86-video-odroidc2/Config.in
@@ -0,0 +1,13 @@
+config BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2
+	bool "xf86-video-odroidc2"
+	depends on BR2_aarch64
+	select BR2_PACKAGE_XPROTO_FONTSPROTO
+	select BR2_PACKAGE_XPROTO_XPROTO
+	select BR2_PACKAGE_XPROTO_DRI2PROTO
+	select BR2_PACKAGE_MESA3D
+	select BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST
+	help
+	 odroid c2 mali 450 GPU ddx video driver
+
+comment "xf86-video-odroidc2 needs egl support from odroid-mali and ARM64 arch"
+	depends on !BR2_PACKAGE_ODROID_MALI || !BR2_aarch64
diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
new file mode 100644
index 0000000..37cd236
--- /dev/null
+++ b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
@@ -0,0 +1,2 @@
+# Computed Locally
+sha256 c442a06c1a528a64b444721ec91b903b84da36120a1b78b965196cc854c7acef  xdriver_xf86-video-odroidc2-2d8e1595da7231f152b78ef8a9b9583fb585883a.tar.gz
diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
new file mode 100644
index 0000000..cad2432
--- /dev/null
+++ b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
@@ -0,0 +1,24 @@
+################################################################################
+#
+# xdriver_xf86-video-odroidc2
+#
+################################################################################
+
+XDRIVER_XF86_VIDEO_ODROIDC2_VERSION = 2d8e1595da7231f152b78ef8a9b9583fb585883a
+XDRIVER_XF86_VIDEO_ODROIDC2_SITE = $(call github,mdrjr,c2_mali_ddx,$(XDRIVER_XF86_VIDEO_ODROIDC2_VERSION))
+XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE = ARM EULA
+XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
+XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
+	odroid-mali \
+	xproto_fontsproto \
+	xproto_xproto \
+	mesa3d \
+	xserver_xorg-server
+
+define XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
+        $(INSTALL) -m 0644 -D $(@D)/src/xorg.conf $(TARGET_DIR)/etc/X11/xorg.conf
+endef
+
+XDRIVER_XF86_VIDEO_ODROIDC2_POST_INSTALL_TARGET_HOOKS += XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
+
+$(eval $(autotools-package))
-- 
2.10.1

[Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver

[Dagg Stompler]

as the X11 odroidc2 driver requires special mali opengl	implmentation,
use the mentoned above mali version if driver is selected.

Signed-off-by: Dagg Stompler <daggs@gmx.com>
---
 package/odroid-mali/Config.in      |  2 ++
 package/odroid-mali/odroid-mali.mk | 19 +++++++++++++++++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/package/odroid-mali/Config.in b/package/odroid-mali/Config.in
index 2cd8e0d..edda615 100644
--- a/package/odroid-mali/Config.in
+++ b/package/odroid-mali/Config.in
@@ -5,6 +5,8 @@ config BR2_PACKAGE_ODROID_MALI
 	select BR2_PACKAGE_ODROID_SCRIPTS # runtime
 	depends on BR2_TOOLCHAIN_USES_GLIBC
 	depends on BR2_aarch64 || BR2_ARM_EABIHF
+	select BR2_PACKAGE_XLIB_LIBXDAMAGE if BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2
+	select BR2_PACKAGE_LIBDRM if BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2
 	help
 	  Install the ARM Mali drivers for odroidc2 based systems.
 
diff --git a/package/odroid-mali/odroid-mali.mk b/package/odroid-mali/odroid-mali.mk
index 7b8e511..3649bbc 100644
--- a/package/odroid-mali/odroid-mali.mk
+++ b/package/odroid-mali/odroid-mali.mk
@@ -12,21 +12,36 @@ ODROID_MALI_LICENSE_FILES = README.md
 ODROID_MALI_INSTALL_STAGING = YES
 ODROID_MALI_PROVIDES = libegl libgles
 
+ifeq ($(BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2),y)
+ODROID_MALI_INSTALL_FOLDER = x11
+ODROID_MALI_INSTALL_ARCH = mali_libs
+else
+ODROID_MALI_INSTALL_FOLDER = fbdev
 ifeq ($(BR2_aarch64),y)
 ODROID_MALI_INSTALL_ARCH = mali_libs
 else
 ODROID_MALI_INSTALL_ARCH = 32bit_libs
 endif
+endif
+
+ifeq ($(BR2_PACKAGE_LIBDRM),y)
+ODROID_MALI_DEPENDENCIES += libdrm
+endif
+
+ifeq ($(BR2_PACKAGE_XLIB_LIBXDAMAGE),y)
+ODROID_MALI_DEPENDENCIES += xlib_libXdamage
+endif
+
 
 define ODROID_MALI_INSTALL_LIBS
-	cp -dpfr $(@D)/fbdev/$(ODROID_MALI_INSTALL_ARCH)/lib* $(1)/usr/lib/
+	cp -dpfr $(@D)/$(ODROID_MALI_INSTALL_FOLDER)/$(ODROID_MALI_INSTALL_ARCH)/lib* $(1)/usr/lib/
 endef
 
 define ODROID_MALI_INSTALL_STAGING_CMDS
 	$(call ODROID_MALI_INSTALL_LIBS,$(STAGING_DIR))
 	mkdir -p $(STAGING_DIR)/usr/lib/pkgconfig
 	cp -dpfr $(@D)/pkgconfig/*.pc $(STAGING_DIR)/usr/lib/pkgconfig/
-	cp -dpfr $(@D)/fbdev/mali_headers/* $(STAGING_DIR)/usr/include
+	cp -dpfr $(@D)/$(ODROID_MALI_INSTALL_FOLDER)/mali_headers/* $(STAGING_DIR)/usr/include
 endef
 
 define ODROID_MALI_INSTALL_TARGET_CMDS
-- 
2.10.1

[Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver

[Arnout Vandecappelle]

 The Vivante driver has a similar issue as this one: there are different binary
blobs for X11 and for fbdev, and only one of them can be installed. For the
Vivante driver, we offer a choice to the user, and the x11-video driver depends
on the user making the right choice. I don't really like that option. However,
this one is not ideal either, because there is a two-way interdependence between
the odroid-mali and the xdriver-video package. In fact, the way it is now, the
two patches have to be squashed because the previoius one doesn't work without
this one.

 So here is my idea: introduce a blind symbol BR2_PACKAGE_ODROID_MALI_X11 in
this package, and let that option steer the choice between X11 or fbdev. It's
blind, it's not part of a choice, so it can be selected from the xdriver-video
package. So from the user's POV, they just have to select the xdriver-video
package and not worry about the rest. This way, you can first have this patch,
and then add the xdriver-video package in a second patch.


On 13-10-16 19:41, Dagg Stompler wrote:
> as the X11 odroidc2 driver requires special mali opengl	implmentation,
> use the mentoned above mali version if driver is selected.
> 
> Signed-off-by: Dagg Stompler <daggs@gmx.com>
> ---
>  package/odroid-mali/Config.in      |  2 ++
>  package/odroid-mali/odroid-mali.mk | 19 +++++++++++++++++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/package/odroid-mali/Config.in b/package/odroid-mali/Config.in
> index 2cd8e0d..edda615 100644
> --- a/package/odroid-mali/Config.in
> +++ b/package/odroid-mali/Config.in
> @@ -5,6 +5,8 @@ config BR2_PACKAGE_ODROID_MALI
>  	select BR2_PACKAGE_ODROID_SCRIPTS # runtime
>  	depends on BR2_TOOLCHAIN_USES_GLIBC
>  	depends on BR2_aarch64 || BR2_ARM_EABIHF
> +	select BR2_PACKAGE_XLIB_LIBXDAMAGE if BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2
> +	select BR2_PACKAGE_LIBDRM if BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2

 This requires some explanation (e.g. in a comment above it). Since the package
itself is just binaries and header files that get installed, it's weird that
other packages get selected.

 My guess is that the header files include stuff from these two packages, so I
do think that what you do is correct.

>  	help
>  	  Install the ARM Mali drivers for odroidc2 based systems.
>  
> diff --git a/package/odroid-mali/odroid-mali.mk b/package/odroid-mali/odroid-mali.mk
> index 7b8e511..3649bbc 100644
> --- a/package/odroid-mali/odroid-mali.mk
> +++ b/package/odroid-mali/odroid-mali.mk
> @@ -12,21 +12,36 @@ ODROID_MALI_LICENSE_FILES = README.md
>  ODROID_MALI_INSTALL_STAGING = YES
>  ODROID_MALI_PROVIDES = libegl libgles
>  
> +ifeq ($(BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2),y)
> +ODROID_MALI_INSTALL_FOLDER = x11

 INSTALL_FOLDER is not a great name, because it is not where it gets installed,
it's where we find it in the source. So SRC_FOLDER would be better. However, we
already have INSTALL_ARCH that suffers from the same problem, so let's keep it.

> +ODROID_MALI_INSTALL_ARCH = mali_libs

 This bit is incorrect. Except if the x11 binaries are only available in
mali_libs and not in 32bit_libs. In the latter case, however, I would make the
BR2_PACKAGE_ODROID_MALI_X11 depend on aarch64 in Config.in itself (and add a
comment why). Then the logic to choose between mali_libs and 32bit_libs that
exists below still applies.

> +else
> +ODROID_MALI_INSTALL_FOLDER = fbdev
>  ifeq ($(BR2_aarch64),y)
>  ODROID_MALI_INSTALL_ARCH = mali_libs
>  else
>  ODROID_MALI_INSTALL_ARCH = 32bit_libs
>  endif
> +endif
> +
> +ifeq ($(BR2_PACKAGE_LIBDRM),y)
> +ODROID_MALI_DEPENDENCIES += libdrm

 I guess the intention here is: if we install the X11 odroid-mali headers, they
include libdrm headers. So a package that depends on odroid-mali should also
depend on libdrm. Then, of course, the better approach is to encode that
dependency here.

 However, in that case, the way you do it here is not correct, because the
dependency only exists if the X11 stuff gets installed. So, this should be
merged in the condition above.


 Regards,
 Arnout

> +endif
> +
> +ifeq ($(BR2_PACKAGE_XLIB_LIBXDAMAGE),y)
> +ODROID_MALI_DEPENDENCIES += xlib_libXdamage
> +endif
> +
>  
>  define ODROID_MALI_INSTALL_LIBS
> -	cp -dpfr $(@D)/fbdev/$(ODROID_MALI_INSTALL_ARCH)/lib* $(1)/usr/lib/
> +	cp -dpfr $(@D)/$(ODROID_MALI_INSTALL_FOLDER)/$(ODROID_MALI_INSTALL_ARCH)/lib* $(1)/usr/lib/
>  endef
>  
>  define ODROID_MALI_INSTALL_STAGING_CMDS
>  	$(call ODROID_MALI_INSTALL_LIBS,$(STAGING_DIR))
>  	mkdir -p $(STAGING_DIR)/usr/lib/pkgconfig
>  	cp -dpfr $(@D)/pkgconfig/*.pc $(STAGING_DIR)/usr/lib/pkgconfig/
> -	cp -dpfr $(@D)/fbdev/mali_headers/* $(STAGING_DIR)/usr/include
> +	cp -dpfr $(@D)/$(ODROID_MALI_INSTALL_FOLDER)/mali_headers/* $(STAGING_DIR)/usr/include
>  endef
>  
>  define ODROID_MALI_INSTALL_TARGET_CMDS
> 

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[Arnout Vandecappelle]

 Hi Dagg,

 You subject line should be:

xdriver_xf86-video-odroidc2: new package

 I have a generic remark about this package and I'm not sure how to solve it.
This is actually the source that comes from ARM:

http://malideveloper.arm.com/downloads/drivers/DX910/r7p0-00rel0/DX910-SW-99003-r7p0-00rel0.tgz

which has been lightly patched in unfathomable ways. The igloo community has a
similar patches driver. There are probably others as well.

 The github repo is really a mess (well, the ARM tarball as well but slightly
less so). It is full of build artefacts, like the .deps directory... It has just
two commits. The changes w.r.t. the ARM tarball are not a separate commit.

 But I don't know what the options are here. We can have duplicates of this
package for each board that hacks it in a different way. Or we could have a
single xdriver_xf86-video-mali package based on the ARM tarball, but then a
different patch would probably have to be applied to it depending on the board.
Either by somehow detecting the board in the .mk file, or by putting the patch
in the global patch dir of the odroid boards. Oh, and there is no upstream we
can send this to (or do we expect ARM to be responsive to patches? Note that the
bugurl they specify in the package is freedesktop...).

 All of that sounds a bit too complicated, so let's keep this package for the
time being. I'd only like two major changes (+ comments below):

- rename the package to xdriver_xf86-video-mali-odroidc2

- in the help text refer to the real upstream, e.g.
http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers/
and explained that this is a hacked version of it.


On 13-10-16 19:41, Dagg Stompler wrote:
> add the X11 driver for odroid c2 boards.
> 
> Signed-off-by: Dagg Stompler <daggs@gmx.com>
> ---
>  package/x11r7/Config.in                            |  1 +
>  ...001-c2_mali_ddx-support-cross-compilation.patch | 40 ++++++++++++++++++++++
>  .../x11r7/xdriver_xf86-video-odroidc2/Config.in    | 13 +++++++
>  .../xdriver_xf86-video-odroidc2.hash               |  2 ++
>  .../xdriver_xf86-video-odroidc2.mk                 | 24 +++++++++++++
>  5 files changed, 80 insertions(+)
>  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
>  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/Config.in
>  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
>  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
> 
> diff --git a/package/x11r7/Config.in b/package/x11r7/Config.in
> index 40aa80c..1c5ff7e 100644
> --- a/package/x11r7/Config.in
> +++ b/package/x11r7/Config.in
> @@ -174,6 +174,7 @@ if BR2_PACKAGE_XORG7
>  		source package/x11r7/xdriver_xf86-video-neomagic/Config.in
>  		source package/x11r7/xdriver_xf86-video-nouveau/Config.in
>  		source package/x11r7/xdriver_xf86-video-nv/Config.in
> +		source package/x11r7/xdriver_xf86-video-odroidc2/Config.in
>  		source package/x11r7/xdriver_xf86-video-openchrome/Config.in
>  		source package/x11r7/xdriver_xf86-video-qxl/Config.in
>  		source package/x11r7/xdriver_xf86-video-r128/Config.in
> diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch b/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
> new file mode 100644
> index 0000000..c85f38b
> --- /dev/null
> +++ b/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
> @@ -0,0 +1,40 @@
> +From 622c02622665c0cbb35433c8f9969d41b25e028a Mon Sep 17 00:00:00 2001
> +From: Dagg Stompler <daggs@gmx.com>
> +Date: Sat, 6 Aug 2016 09:19:08 +0300
> +Subject: [PATCH] c2_mali_ddx: support cross compilation

 There are also scons scripts, do these work better?

 BTW explicitly mention that you patch both .am and .in to avoid autoreconf'ing.

> +
> +Signed-off-by: Dagg Stompler <daggs@gmx.com>
> +---
> + src/Makefile.am | 2 +-
> + src/Makefile.in | 2 +-
> + 2 files changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/src/Makefile.am b/src/Makefile.am
> +index 7fec079..6b49a16 100755
> +--- a/src/Makefile.am
> ++++ b/src/Makefile.am
> +@@ -27,7 +27,7 @@ mali_drv_la_LDFLAGS = -module -avoid-version -L$(MALI_DDK)/lib -lMali -lUMP -lpt
> + mali_drv_ladir = @moduledir@/drivers
> + 
> + AM_CFLAGS = @XORG_CFLAGS@ \
> +-	-I/usr/include/libdrm \
> ++	-I$(SYSROOT)/usr/include/libdrm \
> + 	-I$(MALI_DDK)/include \
> + 	-I$(MALI_DDK)/internal/include/khronos \
> + 	-I$(MALI_DDK)/src/ump/include \
> +diff --git a/src/Makefile.in b/src/Makefile.in
> +index b30194b..2952cdc 100755
> +--- a/src/Makefile.in
> ++++ b/src/Makefile.in
> +@@ -350,7 +350,7 @@ mali_drv_la_LTLIBRARIES = mali_drv.la
> + mali_drv_la_LDFLAGS = -module -avoid-version -L$(MALI_DDK)/lib -lMali -lUMP -lpthread
> + mali_drv_ladir = @moduledir@/drivers
> + AM_CFLAGS = @XORG_CFLAGS@ \
> +-	-I/usr/include/libdrm \
> ++	-I/$(SYSROOT)/usr/include/libdrm \
> + 	-I$(MALI_DDK)/include \
> + 	-I$(MALI_DDK)/internal/include/khronos \
> + 	-I$(MALI_DDK)/src/ump/include \
> +-- 
> +2.9.2
> +
> diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/Config.in b/package/x11r7/xdriver_xf86-video-odroidc2/Config.in
> new file mode 100644
> index 0000000..b2088c8
> --- /dev/null
> +++ b/package/x11r7/xdriver_xf86-video-odroidc2/Config.in
> @@ -0,0 +1,13 @@
> +config BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2
> +	bool "xf86-video-odroidc2"
> +	depends on BR2_aarch64

 There is nothing in this package directly that limits it to aarch64. So this
dependency isn't appropriate.

 You forgot to select or depend on ODROID_MALI. I think the appropriate approach
is to select it in this case. Then of course you do have to add the reverse
dependencies:
	depends on BR2_aarch64 || BR2_ARM_EABIHF # odroid-mali
	depends on BR2_TOOLCHAIN_USES_GLIBC # odroid-mali

 And you're missing the reverse dependencies of mesa3d:
	depends on BR2_TOOLCHAIN_HAS_SYNC_1 # mesa3d
	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # mesa3d
(the other ones are already covered by xserver).


> +	select BR2_PACKAGE_XPROTO_FONTSPROTO
> +	select BR2_PACKAGE_XPROTO_XPROTO
> +	select BR2_PACKAGE_XPROTO_DRI2PROTO
> +	select BR2_PACKAGE_MESA3D
> +	select BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST

 Why is SWRAST needed?

 Please keep the selects alphabetically ordered.

> +	help
> +	 odroid c2 mali 450 GPU ddx video driver

 As I said, please add here a reference to the ARM upstream.

> +
> +comment "xf86-video-odroidc2 needs egl support from odroid-mali and ARM64 arch"
> +	depends on !BR2_PACKAGE_ODROID_MALI || !BR2_aarch64

 This should become a glibc + NPTL threads comment instead.

> diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
> new file mode 100644
> index 0000000..37cd236
> --- /dev/null
> +++ b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
> @@ -0,0 +1,2 @@
> +# Computed Locally
> +sha256 c442a06c1a528a64b444721ec91b903b84da36120a1b78b965196cc854c7acef  xdriver_xf86-video-odroidc2-2d8e1595da7231f152b78ef8a9b9583fb585883a.tar.gz
> diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
> new file mode 100644
> index 0000000..cad2432
> --- /dev/null
> +++ b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
> @@ -0,0 +1,24 @@
> +################################################################################
> +#
> +# xdriver_xf86-video-odroidc2
> +#
> +################################################################################
> +
> +XDRIVER_XF86_VIDEO_ODROIDC2_VERSION = 2d8e1595da7231f152b78ef8a9b9583fb585883a
> +XDRIVER_XF86_VIDEO_ODROIDC2_SITE = $(call github,mdrjr,c2_mali_ddx,$(XDRIVER_XF86_VIDEO_ODROIDC2_VERSION))
> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE = ARM EULA

 Where did you get this? I only see MIT license in README.txt...

> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
> +	odroid-mali \
> +	xproto_fontsproto \
> +	xproto_xproto \

 You also select dri2proto, is that not needed? But actually, I don't see any
inclusion of either of these three proto packages, only of xserver stuff (and a
few that I can't place, like ump.h)

> +	mesa3d \
> +	xserver_xorg-server
> +
> +define XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
> +        $(INSTALL) -m 0644 -D $(@D)/src/xorg.conf $(TARGET_DIR)/etc/X11/xorg.conf

 Hm, not sure about this one. If all packages do that we get conflicts. For e.g.
the Vivante X11 driver, we put in the help text what you have to add to
xorg.conf to make it work.

> +endef
> +
> +XDRIVER_XF86_VIDEO_ODROIDC2_POST_INSTALL_TARGET_HOOKS += XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
> +
> +$(eval $(autotools-package))
> 

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver

[daggs]

Greetings Arnout, 
>  The Vivante driver has a similar issue as this one: there are different binary
> blobs for X11 and for fbdev, and only one of them can be installed. For the
> Vivante driver, we offer a choice to the user, and the x11-video driver depends
> on the user making the right choice. I don't really like that option. However,
> this one is not ideal either, because there is a two-way interdependence between
> the odroid-mali and the xdriver-video package. In fact, the way it is now, the
> two patches have to be squashed because the previoius one doesn't work without
> this one.
> 
>  So here is my idea: introduce a blind symbol BR2_PACKAGE_ODROID_MALI_X11 in
> this package, and let that option steer the choice between X11 or fbdev. It's
> blind, it's not part of a choice, so it can be selected from the xdriver-video
> package. So from the user's POV, they just have to select the xdriver-video
> package and not worry about the rest. This way, you can first have this patch,
> and then add the xdriver-video package in a second patch.
> 
>
thanks for the feedback, this driver has some limitations, the X11 opengl libs supports only arm64. there is no implementation for arm.
I want to see if I got the idea correct, as said, add the symbol mentioned above:
1) arm: show only the fbdev as an option, the current implementation stays the same. the X11 driver is hidden.
2) arm54: show fbdev and X11 option (if xorg + drivers is set), if fbdev is selected use the current implementation. if the X11 driver is selected, use the implementation in the patch.

am I correct?

Dagg.

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[daggs]

Greetings Arnout,
>  Hi Dagg,
> 
>  You subject line should be:
> 
> xdriver_xf86-video-odroidc2: new package
>
noted, thanks.
 
>  I have a generic remark about this package and I'm not sure how to solve it.
> This is actually the source that comes from ARM:
> 
> http://malideveloper.arm.com/downloads/drivers/DX910/r7p0-00rel0/DX910-SW-99003-r7p0-00rel0.tgz
> 
> which has been lightly patched in unfathomable ways. The igloo community has a
> similar patches driver. There are probably others as well.
> 
>  The github repo is really a mess (well, the ARM tarball as well but slightly
> less so). It is full of build artefacts, like the .deps directory... It has just
> two commits. The changes w.r.t. the ARM tarball are not a separate commit.
> 
>  But I don't know what the options are here. We can have duplicates of this
> package for each board that hacks it in a different way. Or we could have a
> single xdriver_xf86-video-mali package based on the ARM tarball, but then a
> different patch would probably have to be applied to it depending on the board.
> Either by somehow detecting the board in the .mk file, or by putting the patch
> in the global patch dir of the odroid boards.
imho this idea has aome problems.
maintaining a patchset for each driver is a lot of work, each time someone commits a patch to the repo, the maintainer needs to know of that, extract the patch and add it to the patchset.
lets assume there is a repo with 1000 commits, there can be 1000 patches in that are in the buildroot tree, there is a possibility to banch it to 1 patch but it will be a huge file that us needed to be maintained.
imho to fix this, under the assumption that all drivers derive from the same file, there is a need to add support for buildroot that extract all the commits of a repo minus the the initial commit which must be the original drive and apply them to the original source.
with these repos (as messy as there are), the maintainer takes care of it.

> Oh, and there is no upstream we
> can send this to (or do we expect ARM to be responsive to patches? Note that the
> bugurl they specify in the package is freedesktop...).
> 
there is, I'm in contact with the maintainer of the c2 repos, I've submitted patches which were merged to other repos before.
according to him, we can semd patches via mail, github merge request and by sending him the patches via the odroid forums.

>  All of that sounds a bit too complicated, so let's keep this package for the
> time being. I'd only like two major changes (+ comments below):
> 
> - rename the package to xdriver_xf86-video-mali-odroidc2
> 
> - in the help text refer to the real upstream, e.g.
> http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers/
> and explained that this is a hacked version of it.
> 
> 
will update and resend.
thanks for the feedback.

Dagg.

[Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver

[Arnout Vandecappelle]

 I'm CC'ing Gary here because the same issues exist for Vivante, which uses a
slightly different approach. Gary, can you comment if you think this is a good
approach?

On 15-10-16 07:57, daggs wrote:
> 
> Greetings Arnout, 
>>  The Vivante driver has a similar issue as this one: there are different binary
>> blobs for X11 and for fbdev, and only one of them can be installed. For the
>> Vivante driver, we offer a choice to the user, and the x11-video driver depends
>> on the user making the right choice. I don't really like that option. However,
>> this one is not ideal either, because there is a two-way interdependence between
>> the odroid-mali and the xdriver-video package. In fact, the way it is now, the
>> two patches have to be squashed because the previoius one doesn't work without
>> this one.
>>
>>  So here is my idea: introduce a blind symbol BR2_PACKAGE_ODROID_MALI_X11 in
>> this package, and let that option steer the choice between X11 or fbdev. It's
>> blind, it's not part of a choice, so it can be selected from the xdriver-video
>> package. So from the user's POV, they just have to select the xdriver-video
>> package and not worry about the rest. This way, you can first have this patch,
>> and then add the xdriver-video package in a second patch.
>>
>>
> thanks for the feedback, this driver has some limitations, the X11 opengl libs supports only arm64. there is no implementation for arm.
> I want to see if I got the idea correct, as said, add the symbol mentioned above:
> 1) arm: show only the fbdev as an option, the current implementation stays the same. the X11 driver is hidden.

 The X11 option would always be hidden. So:

config BR2_PACKAGE_ODROID_MALI_X11
	bool
	depends on BR2_aarch64 # No 32 bit version available

and in the xvideo package:

	depends on BR2_aarch64 # odroid-mali X11
	select BR2_PACKAGE_ODROID_MALI
	select BR2_PACKAGE_ODROID_MALI_X11

> 2) arm54: show fbdev and X11 option (if xorg + drivers is set), if fbdev is selected use the current implementation. if the X11 driver is selected, use the implementation in the patch.

 Yes, except that it wouldn't be a user-visible option.

 I don't think it makes sense to make the option user visible, because you
anyway need another package to make use of it, and it's very unlikely that that
will be a custom package for X11. So whatever package makes use of it can select
the symbol.

 There should be some help text in odroid-mali to explain that the X11 version
of the blob will be used if the xvideo driver is selected.

 Regards,
 Arnout


> am I correct?
> 
> Dagg.
> 

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[Arnout Vandecappelle]

On 15-10-16 08:27, daggs wrote:
> Greetings Arnout,
>>  Hi Dagg,
>>
>>  You subject line should be:
>>
>> xdriver_xf86-video-odroidc2: new package
>>
> noted, thanks.
>  
>>  I have a generic remark about this package and I'm not sure how to solve it.
>> This is actually the source that comes from ARM:
>>
>> http://malideveloper.arm.com/downloads/drivers/DX910/r7p0-00rel0/DX910-SW-99003-r7p0-00rel0.tgz
>>
>> which has been lightly patched in unfathomable ways. The igloo community has a
>> similar patches driver. There are probably others as well.
>>
>>  The github repo is really a mess (well, the ARM tarball as well but slightly
>> less so). It is full of build artefacts, like the .deps directory... It has just
>> two commits. The changes w.r.t. the ARM tarball are not a separate commit.
>>
>>  But I don't know what the options are here. We can have duplicates of this
>> package for each board that hacks it in a different way. Or we could have a
>> single xdriver_xf86-video-mali package based on the ARM tarball, but then a
>> different patch would probably have to be applied to it depending on the board.
>> Either by somehow detecting the board in the .mk file, or by putting the patch
>> in the global patch dir of the odroid boards.
> imho this idea has aome problems.
> maintaining a patchset for each driver is a lot of work, each time someone commits a patch to the repo, the maintainer needs to know of that, extract the patch and add it to the patchset.
> lets assume there is a repo with 1000 commits, there can be 1000 patches in that are in the buildroot tree, there is a possibility to banch it to 1 patch but it will be a huge file that us needed to be maintained.

 I completely agree with this. The problem really is that the ARM tarball still
has to be hacked on. That is just wrong, it should support any SoC or board
using the mali without modification.


> imho to fix this, under the assumption that all drivers derive from the same file, there is a need to add support for buildroot that extract all the commits of a repo minus the the initial commit which must be the original drive and apply them to the original source.
> with these repos (as messy as there are), the maintainer takes care of it.
> 
>> Oh, and there is no upstream we
>> can send this to (or do we expect ARM to be responsive to patches? Note that the
>> bugurl they specify in the package is freedesktop...).
>>
> there is, I'm in contact with the maintainer of the c2 repos, I've submitted patches which were merged to other repos before.
> according to him, we can semd patches via mail, github merge request and by sending him the patches via the odroid forums.

 No, what i meant is sending patches to ARM so they can update the common
mali-x11 driver so that there is no need to make board-specific derivatives.


 Note BTW that there is also a true open source xf86-video-armsoc driver. It
doesn't even seem to depend on the mali blob so I'm not sure what it's doing.


 Regards,
 Arnout

> 
>>  All of that sounds a bit too complicated, so let's keep this package for the
>> time being. I'd only like two major changes (+ comments below):
>>
>> - rename the package to xdriver_xf86-video-mali-odroidc2
>>
>> - in the help text refer to the real upstream, e.g.
>> http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers/
>> and explained that this is a hacked version of it.
>>
>>
> will update and resend.
> thanks for the feedback.
> 
> Dagg.
> 

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver

[Gary Bisson]

Arnout, All,

On Sat, Oct 15, 2016 at 10:28 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>  I'm CC'ing Gary here because the same issues exist for Vivante, which uses a
> slightly different approach. Gary, can you comment if you think this is a good
> approach?
>
> On 15-10-16 07:57, daggs wrote:
>>
>> Greetings Arnout,
>>>  The Vivante driver has a similar issue as this one: there are different binary
>>> blobs for X11 and for fbdev, and only one of them can be installed. For the
>>> Vivante driver, we offer a choice to the user, and the x11-video driver depends
>>> on the user making the right choice. I don't really like that option. However,
>>> this one is not ideal either, because there is a two-way interdependence between
>>> the odroid-mali and the xdriver-video package. In fact, the way it is now, the
>>> two patches have to be squashed because the previoius one doesn't work without
>>> this one.
>>>
>>>  So here is my idea: introduce a blind symbol BR2_PACKAGE_ODROID_MALI_X11 in
>>> this package, and let that option steer the choice between X11 or fbdev. It's
>>> blind, it's not part of a choice, so it can be selected from the xdriver-video
>>> package. So from the user's POV, they just have to select the xdriver-video
>>> package and not worry about the rest. This way, you can first have this patch,
>>> and then add the xdriver-video package in a second patch.
>>>
>>>
>> thanks for the feedback, this driver has some limitations, the X11 opengl libs supports only arm64. there is no implementation for arm.
>> I want to see if I got the idea correct, as said, add the symbol mentioned above:
>> 1) arm: show only the fbdev as an option, the current implementation stays the same. the X11 driver is hidden.
>
>  The X11 option would always be hidden. So:
>
> config BR2_PACKAGE_ODROID_MALI_X11
>         bool
>         depends on BR2_aarch64 # No 32 bit version available
>
> and in the xvideo package:
>
>         depends on BR2_aarch64 # odroid-mali X11
>         select BR2_PACKAGE_ODROID_MALI
>         select BR2_PACKAGE_ODROID_MALI_X11

I like this approach, I wish we could do the same for Vivante. In
Vivante's case it is not possible since the package depends on the SoC
version (BR2_PACKAGE_FREESCALE_IMX_PLATFORM) which cannot be selected.

>> 2) arm54: show fbdev and X11 option (if xorg + drivers is set), if fbdev is selected use the current implementation. if the X11 driver is selected, use the implementation in the patch.
>
>  Yes, except that it wouldn't be a user-visible option.

This will therefore avoid any confusion about which library to use and
ease support questions. My opinion is to go for it if you can.

Regards,
Gary

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[daggs]

Greetings Arnout,
I've somehow missed the rest of this mail:

>  Hi Dagg,
> 
>  You subject line should be:
> 
> xdriver_xf86-video-odroidc2: new package
> 
>  I have a generic remark about this package and I'm not sure how to solve it.
> This is actually the source that comes from ARM:
> 
> http://malideveloper.arm.com/downloads/drivers/DX910/r7p0-00rel0/DX910-SW-99003-r7p0-00rel0.tgz
> 
> which has been lightly patched in unfathomable ways. The igloo community has a
> similar patches driver. There are probably others as well.
> 
>  The github repo is really a mess (well, the ARM tarball as well but slightly
> less so). It is full of build artefacts, like the .deps directory... It has just
> two commits. The changes w.r.t. the ARM tarball are not a separate commit.
> 
>  But I don't know what the options are here. We can have duplicates of this
> package for each board that hacks it in a different way. Or we could have a
> single xdriver_xf86-video-mali package based on the ARM tarball, but then a
> different patch would probably have to be applied to it depending on the board.
> Either by somehow detecting the board in the .mk file, or by putting the patch
> in the global patch dir of the odroid boards. Oh, and there is no upstream we
> can send this to (or do we expect ARM to be responsive to patches? Note that the
> bugurl they specify in the package is freedesktop...).
> 
>  All of that sounds a bit too complicated, so let's keep this package for the
> time being. I'd only like two major changes (+ comments below):
> 
> - rename the package to xdriver_xf86-video-mali-odroidc2
> 
> - in the help text refer to the real upstream, e.g.
> http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers/
> and explained that this is a hacked version of it.
> 
> 
> On 13-10-16 19:41, Dagg Stompler wrote:
> > add the X11 driver for odroid c2 boards.
> > 
> > Signed-off-by: Dagg Stompler <daggs@gmx.com>
> > ---
> >  package/x11r7/Config.in                            |  1 +
> >  ...001-c2_mali_ddx-support-cross-compilation.patch | 40 ++++++++++++++++++++++
> >  .../x11r7/xdriver_xf86-video-odroidc2/Config.in    | 13 +++++++
> >  .../xdriver_xf86-video-odroidc2.hash               |  2 ++
> >  .../xdriver_xf86-video-odroidc2.mk                 | 24 +++++++++++++
> >  5 files changed, 80 insertions(+)
> >  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
> >  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/Config.in
> >  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
> >  create mode 100644 package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
> > 
> > diff --git a/package/x11r7/Config.in b/package/x11r7/Config.in
> > index 40aa80c..1c5ff7e 100644
> > --- a/package/x11r7/Config.in
> > +++ b/package/x11r7/Config.in
> > @@ -174,6 +174,7 @@ if BR2_PACKAGE_XORG7
> >  		source package/x11r7/xdriver_xf86-video-neomagic/Config.in
> >  		source package/x11r7/xdriver_xf86-video-nouveau/Config.in
> >  		source package/x11r7/xdriver_xf86-video-nv/Config.in
> > +		source package/x11r7/xdriver_xf86-video-odroidc2/Config.in
> >  		source package/x11r7/xdriver_xf86-video-openchrome/Config.in
> >  		source package/x11r7/xdriver_xf86-video-qxl/Config.in
> >  		source package/x11r7/xdriver_xf86-video-r128/Config.in
> > diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch b/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
> > new file mode 100644
> > index 0000000..c85f38b
> > --- /dev/null
> > +++ b/package/x11r7/xdriver_xf86-video-odroidc2/0001-c2_mali_ddx-support-cross-compilation.patch
> > @@ -0,0 +1,40 @@
> > +From 622c02622665c0cbb35433c8f9969d41b25e028a Mon Sep 17 00:00:00 2001
> > +From: Dagg Stompler <daggs@gmx.com>
> > +Date: Sat, 6 Aug 2016 09:19:08 +0300
> > +Subject: [PATCH] c2_mali_ddx: support cross compilation
> 
>  There are also scons scripts, do these work better?
never tried them, if automake works, does it matters if scons works?

> 
>  BTW explicitly mention that you patch both .am and .in to avoid autoreconf'ing.
will do.

> 
> > +
> > +Signed-off-by: Dagg Stompler <daggs@gmx.com>
> > +---
> > + src/Makefile.am | 2 +-
> > + src/Makefile.in | 2 +-
> > + 2 files changed, 2 insertions(+), 2 deletions(-)
> > +
> > +diff --git a/src/Makefile.am b/src/Makefile.am
> > +index 7fec079..6b49a16 100755
> > +--- a/src/Makefile.am
> > ++++ b/src/Makefile.am
> > +@@ -27,7 +27,7 @@ mali_drv_la_LDFLAGS = -module -avoid-version -L$(MALI_DDK)/lib -lMali -lUMP -lpt
> > + mali_drv_ladir = @moduledir@/drivers
> > + 
> > + AM_CFLAGS = @XORG_CFLAGS@ \
> > +-	-I/usr/include/libdrm \
> > ++	-I$(SYSROOT)/usr/include/libdrm \
> > + 	-I$(MALI_DDK)/include \
> > + 	-I$(MALI_DDK)/internal/include/khronos \
> > + 	-I$(MALI_DDK)/src/ump/include \
> > +diff --git a/src/Makefile.in b/src/Makefile.in
> > +index b30194b..2952cdc 100755
> > +--- a/src/Makefile.in
> > ++++ b/src/Makefile.in
> > +@@ -350,7 +350,7 @@ mali_drv_la_LTLIBRARIES = mali_drv.la
> > + mali_drv_la_LDFLAGS = -module -avoid-version -L$(MALI_DDK)/lib -lMali -lUMP -lpthread
> > + mali_drv_ladir = @moduledir@/drivers
> > + AM_CFLAGS = @XORG_CFLAGS@ \
> > +-	-I/usr/include/libdrm \
> > ++	-I/$(SYSROOT)/usr/include/libdrm \
> > + 	-I$(MALI_DDK)/include \
> > + 	-I$(MALI_DDK)/internal/include/khronos \
> > + 	-I$(MALI_DDK)/src/ump/include \
> > +-- 
> > +2.9.2
> > +
> > diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/Config.in b/package/x11r7/xdriver_xf86-video-odroidc2/Config.in
> > new file mode 100644
> > index 0000000..b2088c8
> > --- /dev/null
> > +++ b/package/x11r7/xdriver_xf86-video-odroidc2/Config.in
> > @@ -0,0 +1,13 @@
> > +config BR2_PACKAGE_XDRIVER_XF86_VIDEO_ODROIDC2
> > +	bool "xf86-video-odroidc2"
> > +	depends on BR2_aarch64
> 
>  There is nothing in this package directly that limits it to aarch64. So this
> dependency isn't appropriate.
that is correct but it won't compile on a arm system because of the X11 opengl limitation.

> 
>  You forgot to select or depend on ODROID_MALI. I think the appropriate approach
> is to select it in this case. Then of course you do have to add the reverse
> dependencies:
> 	depends on BR2_aarch64 || BR2_ARM_EABIHF # odroid-mali
> 	depends on BR2_TOOLCHAIN_USES_GLIBC # odroid-mali
will do.

> 
>  And you're missing the reverse dependencies of mesa3d:
> 	depends on BR2_TOOLCHAIN_HAS_SYNC_1 # mesa3d
> 	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # mesa3d
> (the other ones are already covered by xserver).
same here.

> 
> 
> > +	select BR2_PACKAGE_XPROTO_FONTSPROTO
> > +	select BR2_PACKAGE_XPROTO_XPROTO
> > +	select BR2_PACKAGE_XPROTO_DRI2PROTO
> > +	select BR2_PACKAGE_MESA3D
> > +	select BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST
> 
>  Why is SWRAST needed?
from what I've understood from the devs, there is no 3D egl implementation. even the official ubuntu images use mesa swrast.

> 
>  Please keep the selects alphabetically ordered.
will do.

> 
> > +	help
> > +	 odroid c2 mali 450 GPU ddx video driver
> 
>  As I said, please add here a reference to the ARM upstream.
> 
> > +
> > +comment "xf86-video-odroidc2 needs egl support from odroid-mali and ARM64 arch"
> > +	depends on !BR2_PACKAGE_ODROID_MALI || !BR2_aarch64
> 
>  This should become a glibc + NPTL threads comment instead.
why? are we sure this won't work for uclibc or musl?

> 
> > diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
> > new file mode 100644
> > index 0000000..37cd236
> > --- /dev/null
> > +++ b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.hash
> > @@ -0,0 +1,2 @@
> > +# Computed Locally
> > +sha256 c442a06c1a528a64b444721ec91b903b84da36120a1b78b965196cc854c7acef  xdriver_xf86-video-odroidc2-2d8e1595da7231f152b78ef8a9b9583fb585883a.tar.gz
> > diff --git a/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
> > new file mode 100644
> > index 0000000..cad2432
> > --- /dev/null
> > +++ b/package/x11r7/xdriver_xf86-video-odroidc2/xdriver_xf86-video-odroidc2.mk
> > @@ -0,0 +1,24 @@
> > +################################################################################
> > +#
> > +# xdriver_xf86-video-odroidc2
> > +#
> > +################################################################################
> > +
> > +XDRIVER_XF86_VIDEO_ODROIDC2_VERSION = 2d8e1595da7231f152b78ef8a9b9583fb585883a
> > +XDRIVER_XF86_VIDEO_ODROIDC2_SITE = $(call github,mdrjr,c2_mali_ddx,$(XDRIVER_XF86_VIDEO_ODROIDC2_VERSION))
> > +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE = ARM EULA
> 
>  Where did you get this? I only see MIT license in README.txt...
not sure, I don't remember, will change.

> 
> > +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
> > +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
> > +	odroid-mali \
> > +	xproto_fontsproto \
> > +	xproto_xproto \
> 
>  You also select dri2proto, is that not needed? But actually, I don't see any
> inclusion of either of these three proto packages, only of xserver stuff (and a
> few that I can't place, like ump.h)
ump.h is part of the x11 egl pkg.
I've added the above deps based on compilation errors I've got.

> 
> > +	mesa3d \
> > +	xserver_xorg-server
> > +
> > +define XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
> > +        $(INSTALL) -m 0644 -D $(@D)/src/xorg.conf $(TARGET_DIR)/etc/X11/xorg.conf
> 
>  Hm, not sure about this one. If all packages do that we get conflicts. For e.g.
> the Vivante X11 driver, we put in the help text what you have to add to
> xorg.conf to make it work.
alternatively one can us the turbofb X11 driver to X to work do I based the pkg on that. 
can I see the expected result in the Vivante X11 driver?

> 
> > +endef
> > +
> > +XDRIVER_XF86_VIDEO_ODROIDC2_POST_INSTALL_TARGET_HOOKS += XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
> > +
> > +$(eval $(autotools-package))
> > 

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[Arnout Vandecappelle]

On 17-10-16 23:11, daggs wrote:

[snip]
>>  You forgot to select or depend on ODROID_MALI. I think the appropriate approach
>> is to select it in this case. Then of course you do have to add the reverse
>> dependencies:
>> 	depends on BR2_aarch64 || BR2_ARM_EABIHF # odroid-mali
>> 	depends on BR2_TOOLCHAIN_USES_GLIBC # odroid-mali
> will do.
> 
[snip]
>>> +comment "xf86-video-odroidc2 needs egl support from odroid-mali and ARM64 arch"
>>> +	depends on !BR2_PACKAGE_ODROID_MALI || !BR2_aarch64
>>
>>  This should become a glibc + NPTL threads comment instead.
> why? are we sure this won't work for uclibc or musl?

 Because of the 'select BR2_PACKAGE_ODROID_MALI' you have a dependency on glibc.

 Oh, and we don't mention arch dependencies in the comment, so it should be
	depend on BR2_aarch64
	depends on !BR2_TOOLCHAIN_USES_GLIBC

[snip]
>>> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
>>> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
>>> +	odroid-mali \
>>> +	xproto_fontsproto \
>>> +	xproto_xproto \
>>
>>  You also select dri2proto, is that not needed? But actually, I don't see any
>> inclusion of either of these three proto packages, only of xserver stuff (and a
>> few that I can't place, like ump.h)
> ump.h is part of the x11 egl pkg.
> I've added the above deps based on compilation errors I've got.

 I suspect that it actually comes from the headers of odroid-mali. If that is
the case, it would be better to put the dependency in odroid-mali itself
(conditional on using the X11 version, of course).

>>
>>> +	mesa3d \
>>> +	xserver_xorg-server
>>> +
>>> +define XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
>>> +        $(INSTALL) -m 0644 -D $(@D)/src/xorg.conf $(TARGET_DIR)/etc/X11/xorg.conf
>>
>>  Hm, not sure about this one. If all packages do that we get conflicts. For e.g.
>> the Vivante X11 driver, we put in the help text what you have to add to
>> xorg.conf to make it work.
> alternatively one can us the turbofb X11 driver to X to work do I based the pkg on that. 
> can I see the expected result in the Vivante X11 driver?

 Well, you picked the _only_ driver that installs a xorg.conf... We just haven't
noticed when Scott Fann contributed that driver.

 Regards,
 Arnout

> 
>>
>>> +endef
>>> +
>>> +XDRIVER_XF86_VIDEO_ODROIDC2_POST_INSTALL_TARGET_HOOKS += XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
>>> +
>>> +$(eval $(autotools-package))
>>>

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[daggs]

Greetings Arnout,

> On 17-10-16 23:11, daggs wrote:
> 
> [snip]
> >>  You forgot to select or depend on ODROID_MALI. I think the appropriate approach
> >> is to select it in this case. Then of course you do have to add the reverse
> >> dependencies:
> >> 	depends on BR2_aarch64 || BR2_ARM_EABIHF # odroid-mali
> >> 	depends on BR2_TOOLCHAIN_USES_GLIBC # odroid-mali
> > will do.
> > 
> [snip]
> >>> +comment "xf86-video-odroidc2 needs egl support from odroid-mali and ARM64 arch"
> >>> +	depends on !BR2_PACKAGE_ODROID_MALI || !BR2_aarch64
> >>
> >>  This should become a glibc + NPTL threads comment instead.
> > why? are we sure this won't work for uclibc or musl?
> 
>  Because of the 'select BR2_PACKAGE_ODROID_MALI' you have a dependency on glibc.
you are correct, will fix.

> 
>  Oh, and we don't mention arch dependencies in the comment, so it should be
> 	depend on BR2_aarch64
> 	depends on !BR2_TOOLCHAIN_USES_GLIBC
will fix.

> 
> [snip]
> >>> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
> >>> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
> >>> +	odroid-mali \
> >>> +	xproto_fontsproto \
> >>> +	xproto_xproto \
> >>
> >>  You also select dri2proto, is that not needed? But actually, I don't see any
> >> inclusion of either of these three proto packages, only of xserver stuff (and a
> >> few that I can't place, like ump.h)
> > ump.h is part of the x11 egl pkg.
> > I've added the above deps based on compilation errors I've got.
> 
>  I suspect that it actually comes from the headers of odroid-mali. If that is
> the case, it would be better to put the dependency in odroid-mali itself
> (conditional on using the X11 version, of course).
I don't understand one thing, the existence of dri2proto does affects odroid-mali, why should I depend odroid-mali dri2proto it when there is no logic to do so?

> 
> >>
> >>> +	mesa3d \
> >>> +	xserver_xorg-server
> >>> +
> >>> +define XDRIVER_XF86_VIDEO_ODROIDC2_INSTALL_CONF_FILE
> >>> +        $(INSTALL) -m 0644 -D $(@D)/src/xorg.conf $(TARGET_DIR)/etc/X11/xorg.conf
> >>
> >>  Hm, not sure about this one. If all packages do that we get conflicts. For e.g.
> >> the Vivante X11 driver, we put in the help text what you have to add to
> >> xorg.conf to make it work.
> > alternatively one can us the turbofb X11 driver to X to work do I based the pkg on that. 
> > can I see the expected result in the Vivante X11 driver?
> 
>  Well, you picked the _only_ driver that installs a xorg.conf... We just haven't
> noticed when Scott Fann contributed that driver.
so the correct driver to base the package on is the Vivante X11 driver?

Dagg.

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[Arnout Vandecappelle]

On 18-10-16 10:02, daggs wrote:
> Greetings Arnout,
> 
>> On 17-10-16 23:11, daggs wrote:
>>

>> [snip]
>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
>>>>> +	odroid-mali \
>>>>> +	xproto_fontsproto \
>>>>> +	xproto_xproto \
>>>>
>>>>  You also select dri2proto, is that not needed? But actually, I don't see any
>>>> inclusion of either of these three proto packages, only of xserver stuff (and a
>>>> few that I can't place, like ump.h)
>>> ump.h is part of the x11 egl pkg.
>>> I've added the above deps based on compilation errors I've got.
>>
>>  I suspect that it actually comes from the headers of odroid-mali. If that is
>> the case, it would be better to put the dependency in odroid-mali itself
>> (conditional on using the X11 version, of course).
> I don't understand one thing, the existence of dri2proto does affects odroid-mali, why should I depend odroid-mali dri2proto it when there is no logic to do so?

 I'm sorry but I couldn't parse your sentence. So I'll just re-explain.

 I suspect that xproto_fontsproto and xproto_xproto are not included by the
video driver itself, but are included by odroid-mali headers. So I checked and
indeed, the odroid-mali headers include X11/Xlib.h and X11/Xutil.h. So, in
odroid-mali.mk you should add something like

ifeq ($(BR2_PACKAGE_ODROID_MALI_X11),y)
# The X11 version of the headers include X11/Xlib.h and X11/Xutil.h
ODROID_MALI_DEPENDENCIES += xlib_libX11
endif

and in Config.in:
	select BR2_PACKAGE_XLIB_LIBX11 if BR2_PACKAGE_ODROID_MALI_X11


 For the video driver, the required packages seem to be:

xserver_xorg-server (for damage.h, dri2.h, exa.h, micmap.h, ...)
libdrm (for xf86drm.h)

 But I haven't actually tried building it so I'm not sure.



 Regards,
 Arnout

[snip]

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[daggs]

Greetings Arnout,

> On 18-10-16 10:02, daggs wrote:
> > Greetings Arnout,
> > 
> >> On 17-10-16 23:11, daggs wrote:
> >>
> 
> >> [snip]
> >>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
> >>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
> >>>>> +	odroid-mali \
> >>>>> +	xproto_fontsproto \
> >>>>> +	xproto_xproto \
> >>>>
> >>>>  You also select dri2proto, is that not needed? But actually, I don't see any
> >>>> inclusion of either of these three proto packages, only of xserver stuff (and a
> >>>> few that I can't place, like ump.h)
> >>> ump.h is part of the x11 egl pkg.
> >>> I've added the above deps based on compilation errors I've got.
> >>
> >>  I suspect that it actually comes from the headers of odroid-mali. If that is
> >> the case, it would be better to put the dependency in odroid-mali itself
> >> (conditional on using the X11 version, of course).
> > I don't understand one thing, the existence of dri2proto does affects odroid-mali, why should I depend odroid-mali dri2proto it when there is no logic to do so?
> 
>  I'm sorry but I couldn't parse your sentence. So I'll just re-explain.
> 
>  I suspect that xproto_fontsproto and xproto_xproto are not included by the
> video driver itself, but are included by odroid-mali headers. So I checked and
> indeed, the odroid-mali headers include X11/Xlib.h and X11/Xutil.h. So, in
> odroid-mali.mk you should add something like
> 
> ifeq ($(BR2_PACKAGE_ODROID_MALI_X11),y)
> # The X11 version of the headers include X11/Xlib.h and X11/Xutil.h
> ODROID_MALI_DEPENDENCIES += xlib_libX11
> endif
won't this means that xlib_libX11 will be built? if so, the headers mentioned above won't be deleted by xlib_libX11?

> 
> and in Config.in:
> 	select BR2_PACKAGE_XLIB_LIBX11 if BR2_PACKAGE_ODROID_MALI_X11
> 
ok, I understand this.

> 
>  For the video driver, the required packages seem to be:
> 
> xserver_xorg-server (for damage.h, dri2.h, exa.h, micmap.h, ...)
> libdrm (for xf86drm.h)
> 
>  But I haven't actually tried building it so I'm not sure.
it needs testing, will do after I'll finish understanding all the rejects.

what about the xorg.conf? I'm pretty sure that it won't work without the xorg.conf.
what is the right way to address it?

Thanks,

Dagg.

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[Arnout Vandecappelle]

On 20-10-16 19:41, daggs wrote:
> Greetings Arnout,
> 
>> On 18-10-16 10:02, daggs wrote:
>>> Greetings Arnout,
>>>
>>>> On 17-10-16 23:11, daggs wrote:
>>>>
>>
>>>> [snip]
>>>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
>>>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
>>>>>>> +	odroid-mali \
>>>>>>> +	xproto_fontsproto \
>>>>>>> +	xproto_xproto \
>>>>>>
>>>>>>  You also select dri2proto, is that not needed? But actually, I don't see any
>>>>>> inclusion of either of these three proto packages, only of xserver stuff (and a
>>>>>> few that I can't place, like ump.h)
>>>>> ump.h is part of the x11 egl pkg.
>>>>> I've added the above deps based on compilation errors I've got.
>>>>
>>>>  I suspect that it actually comes from the headers of odroid-mali. If that is
>>>> the case, it would be better to put the dependency in odroid-mali itself
>>>> (conditional on using the X11 version, of course).
>>> I don't understand one thing, the existence of dri2proto does affects odroid-mali, why should I depend odroid-mali dri2proto it when there is no logic to do so?
>>
>>  I'm sorry but I couldn't parse your sentence. So I'll just re-explain.
>>
>>  I suspect that xproto_fontsproto and xproto_xproto are not included by the
>> video driver itself, but are included by odroid-mali headers. So I checked and
>> indeed, the odroid-mali headers include X11/Xlib.h and X11/Xutil.h. So, in
>> odroid-mali.mk you should add something like
>>
>> ifeq ($(BR2_PACKAGE_ODROID_MALI_X11),y)
>> # The X11 version of the headers include X11/Xlib.h and X11/Xutil.h
>> ODROID_MALI_DEPENDENCIES += xlib_libX11
>> endif
> won't this means that xlib_libX11 will be built? if so, the headers mentioned above won't be deleted by xlib_libX11?

 Yes, xlib_libX11 will be built, so Xlib.h and Xutil.h get installed to staging,
which is exactly what we want, no?

> 
>>
>> and in Config.in:
>> 	select BR2_PACKAGE_XLIB_LIBX11 if BR2_PACKAGE_ODROID_MALI_X11
>>
> ok, I understand this.
> 
>>
>>  For the video driver, the required packages seem to be:
>>
>> xserver_xorg-server (for damage.h, dri2.h, exa.h, micmap.h, ...)
>> libdrm (for xf86drm.h)
>>
>>  But I haven't actually tried building it so I'm not sure.
> it needs testing, will do after I'll finish understanding all the rejects.
> 
> what about the xorg.conf? I'm pretty sure that it won't work without the xorg.conf.
> what is the right way to address it?

 Of course it won't work without xorg.conf adaptations. But many drivers need or
may need xorg.conf adaptations. So what you should do is to add an explanation
to the help text in Config.in. Look at xdriver_xf86-video-imx-viv as an example.

 Regards,
 Arnout

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[daggs]

Greetings Arnout,

> On 20-10-16 19:41, daggs wrote:
> > Greetings Arnout,
> > 
> >> On 18-10-16 10:02, daggs wrote:
> >>> Greetings Arnout,
> >>>
> >>>> On 17-10-16 23:11, daggs wrote:
> >>>>
> >>
> >>>> [snip]
> >>>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
> >>>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
> >>>>>>> +	odroid-mali \
> >>>>>>> +	xproto_fontsproto \
> >>>>>>> +	xproto_xproto \
> >>>>>>
> >>>>>>  You also select dri2proto, is that not needed? But actually, I don't see any
> >>>>>> inclusion of either of these three proto packages, only of xserver stuff (and a
> >>>>>> few that I can't place, like ump.h)
> >>>>> ump.h is part of the x11 egl pkg.
> >>>>> I've added the above deps based on compilation errors I've got.
> >>>>
> >>>>  I suspect that it actually comes from the headers of odroid-mali. If that is
> >>>> the case, it would be better to put the dependency in odroid-mali itself
> >>>> (conditional on using the X11 version, of course).
> >>> I don't understand one thing, the existence of dri2proto does affects odroid-mali, why should I depend odroid-mali dri2proto it when there is no logic to do so?
> >>
> >>  I'm sorry but I couldn't parse your sentence. So I'll just re-explain.
> >>
> >>  I suspect that xproto_fontsproto and xproto_xproto are not included by the
> >> video driver itself, but are included by odroid-mali headers. So I checked and
> >> indeed, the odroid-mali headers include X11/Xlib.h and X11/Xutil.h. So, in
> >> odroid-mali.mk you should add something like
> >>
> >> ifeq ($(BR2_PACKAGE_ODROID_MALI_X11),y)
> >> # The X11 version of the headers include X11/Xlib.h and X11/Xutil.h
> >> ODROID_MALI_DEPENDENCIES += xlib_libX11
> >> endif
> > won't this means that xlib_libX11 will be built? if so, the headers mentioned above won't be deleted by xlib_libX11?
> 
>  Yes, xlib_libX11 will be built, so Xlib.h and Xutil.h get installed to staging,
> which is exactly what we want, no?
indeed, thought of that a few hours after I send this mail.

> 
> > 
> >>
> >> and in Config.in:
> >> 	select BR2_PACKAGE_XLIB_LIBX11 if BR2_PACKAGE_ODROID_MALI_X11
> >>
> > ok, I understand this.
> > 
> >>
> >>  For the video driver, the required packages seem to be:
> >>
> >> xserver_xorg-server (for damage.h, dri2.h, exa.h, micmap.h, ...)
> >> libdrm (for xf86drm.h)
> >>
> >>  But I haven't actually tried building it so I'm not sure.
> > it needs testing, will do after I'll finish understanding all the rejects.
> > 
> > what about the xorg.conf? I'm pretty sure that it won't work without the xorg.conf.
> > what is the right way to address it?
> 
>  Of course it won't work without xorg.conf adaptations. But many drivers need or
> may need xorg.conf adaptations. So what you should do is to add an explanation
> to the help text in Config.in. Look at xdriver_xf86-video-imx-viv as an example.
imho the one in xdriver_xf86-video-imx-viv isn't good for this driver. the xdriver_xf86-video-imx-viv has a generic explanation.
this driver needs specific xorg.conf, imho pasting the entire file to the help is not a good idea.
so I have an alternative suggestion, instead of installing it to /etc/X11/xorg.conf, it will be installed to /usr/share/X11/xorg.conf.odroidc2.
in addition, a entry to the help screen pointing to the location of the file is added.
thus the user can easily copy the file to the right location and there is not possible collision upon build.
this can be done to the trubofb driver.
thoughts?

Dagg.

[Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package.

[daggs]

Greetings Arnout,

> On 20-10-16 19:41, daggs wrote:
> > Greetings Arnout,
> > 
> >> On 18-10-16 10:02, daggs wrote:
> >>> Greetings Arnout,
> >>>
> >>>> On 17-10-16 23:11, daggs wrote:
> >>>>
> >>
> >>>> [snip]
> >>>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_LICENSE_FILES = README.txt 
> >>>>>>> +XDRIVER_XF86_VIDEO_ODROIDC2_DEPENDENCIES = \
> >>>>>>> +	odroid-mali \
> >>>>>>> +	xproto_fontsproto \
> >>>>>>> +	xproto_xproto \
> >>>>>>
> >>>>>>  You also select dri2proto, is that not needed? But actually, I don't see any
> >>>>>> inclusion of either of these three proto packages, only of xserver stuff (and a
> >>>>>> few that I can't place, like ump.h)
> >>>>> ump.h is part of the x11 egl pkg.
> >>>>> I've added the above deps based on compilation errors I've got.
> >>>>
> >>>>  I suspect that it actually comes from the headers of odroid-mali. If that is
> >>>> the case, it would be better to put the dependency in odroid-mali itself
> >>>> (conditional on using the X11 version, of course).
> >>> I don't understand one thing, the existence of dri2proto does affects odroid-mali, why should I depend odroid-mali dri2proto it when there is no logic to do so?
> >>
> >>  I'm sorry but I couldn't parse your sentence. So I'll just re-explain.
> >>
> >>  I suspect that xproto_fontsproto and xproto_xproto are not included by the
> >> video driver itself, but are included by odroid-mali headers. So I checked and
> >> indeed, the odroid-mali headers include X11/Xlib.h and X11/Xutil.h. So, in
> >> odroid-mali.mk you should add something like
> >>
> >> ifeq ($(BR2_PACKAGE_ODROID_MALI_X11),y)
> >> # The X11 version of the headers include X11/Xlib.h and X11/Xutil.h
> >> ODROID_MALI_DEPENDENCIES += xlib_libX11
> >> endif
> > won't this means that xlib_libX11 will be built? if so, the headers mentioned above won't be deleted by xlib_libX11?
> 
>  Yes, xlib_libX11 will be built, so Xlib.h and Xutil.h get installed to staging,
> which is exactly what we want, no?
indeed, thought of that a few hours after I send this mail.

> 
> > 
> >>
> >> and in Config.in:
> >> 	select BR2_PACKAGE_XLIB_LIBX11 if BR2_PACKAGE_ODROID_MALI_X11
> >>
> > ok, I understand this.
> > 
> >>
> >>  For the video driver, the required packages seem to be:
> >>
> >> xserver_xorg-server (for damage.h, dri2.h, exa.h, micmap.h, ...)
> >> libdrm (for xf86drm.h)
> >>
> >>  But I haven't actually tried building it so I'm not sure.
> > it needs testing, will do after I'll finish understanding all the rejects.
> > 
> > what about the xorg.conf? I'm pretty sure that it won't work without the xorg.conf.
> > what is the right way to address it?
> 
>  Of course it won't work without xorg.conf adaptations. But many drivers need or
> may need xorg.conf adaptations. So what you should do is to add an explanation
> to the help text in Config.in. Look at xdriver_xf86-video-imx-viv as an example.
imho the one in xdriver_xf86-video-imx-viv isn't good for this driver. the xdriver_xf86-video-imx-viv has a generic explanation.
this driver needs specific xorg.conf, imho pasting the entire file to the help is not a good idea.
so I have an alternative suggestion, instead of installing it to /etc/X11/xorg.conf, it will be installed to /usr/share/X11/xorg.conf.odroidc2.
in addition, a entry to the help screen pointing to the location of the file is added.
thus the user can easily copy the file to the right location and there is not possible collision upon build.
this can be done to the trubofb driver.
thoughts?

Dagg.