* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. @ 2016-10-13 17:41 Dagg Stompler 2016-10-13 17:41 ` [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver Dagg Stompler 2016-10-14 21:58 ` [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Arnout Vandecappelle 0 siblings, 2 replies; 17+ messages in thread From: Dagg Stompler @ 2016-10-13 17:41 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver 2016-10-13 17:41 [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Dagg Stompler @ 2016-10-13 17:41 ` Dagg Stompler 2016-10-14 21:58 ` Arnout Vandecappelle 2016-10-14 21:58 ` [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Arnout Vandecappelle 1 sibling, 1 reply; 17+ messages in thread From: Dagg Stompler @ 2016-10-13 17:41 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver 2016-10-13 17:41 ` [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver Dagg Stompler @ 2016-10-14 21:58 ` Arnout Vandecappelle 2016-10-15 5:57 ` daggs 0 siblings, 1 reply; 17+ messages in thread From: Arnout Vandecappelle @ 2016-10-14 21:58 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver 2016-10-14 21:58 ` Arnout Vandecappelle @ 2016-10-15 5:57 ` daggs 2016-10-15 8:28 ` Arnout Vandecappelle 0 siblings, 1 reply; 17+ messages in thread From: daggs @ 2016-10-15 5:57 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver 2016-10-15 5:57 ` daggs @ 2016-10-15 8:28 ` Arnout Vandecappelle 2016-10-15 9:55 ` Gary Bisson 0 siblings, 1 reply; 17+ messages in thread From: Arnout Vandecappelle @ 2016-10-15 8:28 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver 2016-10-15 8:28 ` Arnout Vandecappelle @ 2016-10-15 9:55 ` Gary Bisson 0 siblings, 0 replies; 17+ messages in thread From: Gary Bisson @ 2016-10-15 9:55 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-13 17:41 [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Dagg Stompler 2016-10-13 17:41 ` [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver Dagg Stompler @ 2016-10-14 21:58 ` Arnout Vandecappelle 2016-10-15 6:27 ` daggs 2016-10-17 21:11 ` daggs 1 sibling, 2 replies; 17+ messages in thread From: Arnout Vandecappelle @ 2016-10-14 21:58 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-14 21:58 ` [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Arnout Vandecappelle @ 2016-10-15 6:27 ` daggs 2016-10-15 8:35 ` Arnout Vandecappelle 2016-10-17 21:11 ` daggs 1 sibling, 1 reply; 17+ messages in thread From: daggs @ 2016-10-15 6:27 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-15 6:27 ` daggs @ 2016-10-15 8:35 ` Arnout Vandecappelle 0 siblings, 0 replies; 17+ messages in thread From: Arnout Vandecappelle @ 2016-10-15 8:35 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-14 21:58 ` [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Arnout Vandecappelle 2016-10-15 6:27 ` daggs @ 2016-10-17 21:11 ` daggs 2016-10-17 22:37 ` Arnout Vandecappelle 1 sibling, 1 reply; 17+ messages in thread From: daggs @ 2016-10-17 21:11 UTC (permalink / raw) To: buildroot 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)) > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-17 21:11 ` daggs @ 2016-10-17 22:37 ` Arnout Vandecappelle 2016-10-18 8:02 ` daggs 0 siblings, 1 reply; 17+ messages in thread From: Arnout Vandecappelle @ 2016-10-17 22:37 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-17 22:37 ` Arnout Vandecappelle @ 2016-10-18 8:02 ` daggs 2016-10-18 19:53 ` Arnout Vandecappelle 0 siblings, 1 reply; 17+ messages in thread From: daggs @ 2016-10-18 8:02 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-18 8:02 ` daggs @ 2016-10-18 19:53 ` Arnout Vandecappelle 2016-10-20 17:41 ` daggs 0 siblings, 1 reply; 17+ messages in thread From: Arnout Vandecappelle @ 2016-10-18 19:53 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-18 19:53 ` Arnout Vandecappelle @ 2016-10-20 17:41 ` daggs 2016-10-21 19:33 ` Arnout Vandecappelle 0 siblings, 1 reply; 17+ messages in thread From: daggs @ 2016-10-20 17:41 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-20 17:41 ` daggs @ 2016-10-21 19:33 ` Arnout Vandecappelle 2016-10-22 9:40 ` daggs 2016-10-23 4:40 ` daggs 0 siblings, 2 replies; 17+ messages in thread From: Arnout Vandecappelle @ 2016-10-21 19:33 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-21 19:33 ` Arnout Vandecappelle @ 2016-10-22 9:40 ` daggs 2016-10-23 4:40 ` daggs 1 sibling, 0 replies; 17+ messages in thread From: daggs @ 2016-10-22 9:40 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package. 2016-10-21 19:33 ` Arnout Vandecappelle 2016-10-22 9:40 ` daggs @ 2016-10-23 4:40 ` daggs 1 sibling, 0 replies; 17+ messages in thread From: daggs @ 2016-10-23 4:40 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-10-23 4:40 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-13 17:41 [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Dagg Stompler 2016-10-13 17:41 ` [Buildroot] [PATCH 2/2] odroid-mali: add support for X11 driver Dagg Stompler 2016-10-14 21:58 ` Arnout Vandecappelle 2016-10-15 5:57 ` daggs 2016-10-15 8:28 ` Arnout Vandecappelle 2016-10-15 9:55 ` Gary Bisson 2016-10-14 21:58 ` [Buildroot] [PATCH 1/2] X11/odroidc2-driver: New Package Arnout Vandecappelle 2016-10-15 6:27 ` daggs 2016-10-15 8:35 ` Arnout Vandecappelle 2016-10-17 21:11 ` daggs 2016-10-17 22:37 ` Arnout Vandecappelle 2016-10-18 8:02 ` daggs 2016-10-18 19:53 ` Arnout Vandecappelle 2016-10-20 17:41 ` daggs 2016-10-21 19:33 ` Arnout Vandecappelle 2016-10-22 9:40 ` daggs 2016-10-23 4:40 ` daggs
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.