[Buildroot] [PATCH 0/0] Updating directfb and divine

[Buildroot] [PATCH 0/0] Updating directfb and divine

[Carsten Schoenert]

Hello,

as I wrote I want to experementing a little bit with ilixi from the
directfb people.
To do this the directfb files must be upgraded. I bumped the directfb
and divine version to 1.6.3.
Also I made some expanding to the helper strings inside the directfb
package an fixed up some little typos to the directfb variables.
Until now no error happen because the variable was misspelled in all
ivolved files. Correcting this just for clearness.

Thanks to Thomas for helping fighting some autotool related package
stuff inside the divine package.

Regards
Carsten

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Carsten Schoenert]

From: Carsten Schoenert <c.schoenert@gmail.com>

Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com>
---
 package/directfb/directfb.mk |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/directfb/directfb.mk b/package/directfb/directfb.mk
index 4f05ed2..8c701db 100644
--- a/package/directfb/directfb.mk
+++ b/package/directfb/directfb.mk
@@ -3,8 +3,8 @@
 # directfb
 #
 #############################################################
-DIRECTFB_VERSION_MAJOR = 1.4
-DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).17
+DIRECTFB_VERSION_MAJOR = 1.6
+DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).3
 DIRECTFB_SITE = http://www.directfb.org/downloads/Core/DirectFB-$(DIRECTFB_VERSION_MAJOR)
 DIRECTFB_SOURCE = DirectFB-$(DIRECTFB_VERSION).tar.gz
 DIRECTFB_LICENSE = LGPLv2.1+
-- 
1.7.10.4

[Buildroot] [PATCH 2/4] divine: bumping version to 1.6.3

[Carsten Schoenert]

From: Carsten Schoenert <c.schoenert@gmail.com>

To be identical to the version of directfb switching also to version
1.6.3. The divine package needs at minimum directfb 1.6.0 as
dependencie.
Adding the license information to the package divine.
Also switch to Git for getting the package source because the tar.gz
for version 1.6.3 on directfb.org is broken because of a missed header
file inside.

Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com>
---
 package/divine/divine.mk |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/package/divine/divine.mk b/package/divine/divine.mk
index b949601..df59a18 100644
--- a/package/divine/divine.mk
+++ b/package/divine/divine.mk
@@ -4,11 +4,16 @@
 #
 #############################################################
 
-DIVINE_VERSION = 0.4.0
-DIVINE_SITE = http://www.directfb.org/downloads/Extras
-DIVINE_SOURCE = DiVine-$(DIVINE_VERSION).tar.gz
+# tagged version 1.6.3
+DIVINE_VERSION = 83cafc257a42b9465cd9d6185bf66b8c1b7ed704
+DIVINE_SITE = git://git.directfb.org/git/directfb/extras/DiVine.git
+DIVINE_LICENSE = LGPLv2.1+
+DIVINE_LICENSE_FILE = COPYING
 DIVINE_INSTALL_STAGING = YES
 DIVINE_DEPENDENCIES = directfb
 DIVINE_CONFIG_SCRIPTS = divine-config
 
+# package has no configure script so we have generate it
+DIVINE_AUTORECONF = YES
+
 $(eval $(autotools-package))
-- 
1.7.10.4

[Buildroot] [PATCH 3/4] directfb: expanding the help strings

[Carsten Schoenert]

From: Carsten Schoenert <c.schoenert@gmail.com>

Adding a helper string for the PXA3xx and graphics driver from Marvell
and the EP9x graphics driver from Cirrus Logic.

Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com>
---
 package/directfb/Config.in |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/package/directfb/Config.in b/package/directfb/Config.in
index a184568..3d22e15 100644
--- a/package/directfb/Config.in
+++ b/package/directfb/Config.in
@@ -49,10 +49,27 @@ config BR2_PACKAGE_DIRECTFB_MATROX
 config BR2_PACKAGE_DIRECTFB_PXA3XX
 	bool "compile pxa3xx graphics driver"
 	depends on BR2_arm
+    help
+      The Marvell PXA3xx Processor Family is a system-on-chip based
+      on XScale? microarchitecture. The PXA3xx processor provide
+      high-performance multimedia, low-power capabilities, and rich
+      peripheral integration. The PXA3xx Processor Family provide
+      enhanced features compared to the PXA27x Processor Family, and
+      are the first Marvell applications processors to integrate a
+      hardware video accelerator unit.
+
+      http://www.marvell.com/application-processors/pxa-family/
 
 config BR2_PACKAGE_DIRECTFB_EP9X
 	bool "compile ep9x graphics driver"
 	depends on BR2_arm
+    help
+      The EP93xx ARMv9 based processors from Cirrus Logic are highly
+      integrated systems-on-a-chip that pave the way for a multitude
+      of next-generation consumer and industrial electronic products.
+
+      http://cirrus.com/en/products/arm9.html
+
 
 config BR2_PACKAGE_DIRECTFB_UNICHROME
 	bool "compile unichrome graphics driver"
-- 
1.7.10.4

[Buildroot] [PATCH 4/4] directfb: fixing typo in variables

[Carsten Schoenert]

From: Carsten Schoenert <c.schoenert@gmail.com>

Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com>
---
 package/directfb/Config.in   |    4 ++--
 package/directfb/directfb.mk |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/directfb/Config.in b/package/directfb/Config.in
index 3d22e15..f5759db 100644
--- a/package/directfb/Config.in
+++ b/package/directfb/Config.in
@@ -115,13 +115,13 @@ config BR2_PACKAGE_DIRECTFB_PNG
 	default y
 	select BR2_PACKAGE_LIBPNG
 
-config BR2_PACKAGE_DIRECTB_DITHER_RGB16
+config BR2_PACKAGE_DIRECTFB_DITHER_RGB16
 	bool "enable advanced dithering of RGB16 surfaces"
 	help
 	  Enable dithering when loading images to RGB16 surfaces.
 	  This increases the data section by 64 KBytes.
 
-config BR2_PACKAGE_DIRECTB_TESTS
+config BR2_PACKAGE_DIRECTFB_TESTS
 	bool "build directfb tests"
 
 endif # BR2_PACKAGE_DIRECTFB
diff --git a/package/directfb/directfb.mk b/package/directfb/directfb.mk
index 8c701db..5ead084 100644
--- a/package/directfb/directfb.mk
+++ b/package/directfb/directfb.mk
@@ -108,13 +108,13 @@ else
 DIRECTFB_CONF_OPT += --disable-jpeg
 endif
 
-ifeq ($(BR2_PACKAGE_DIRECTB_DITHER_RGB16),y)
+ifeq ($(BR2_PACKAGE_DIRECTFB_DITHER_RGB16),y)
 DIRECTFB_CONF_OPT += --with-dither-rgb16=advanced
 else
 DIRECTFB_CONF_OPT += --with-dither-rgb16=none
 endif
 
-ifeq ($(BR2_PACKAGE_DIRECTB_TESTS),y)
+ifeq ($(BR2_PACKAGE_DIRECTFB_TESTS),y)
 DIRECTFB_CONF_OPT += --with-tests
 endif
 
-- 
1.7.10.4

[Buildroot] [PATCH 4/4] directfb: fixing typo in variables

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Sun, 10 Mar 2013 10:47:38 +0100, Carsten Schoenert wrote:
> From: Carsten Schoenert <c.schoenert@gmail.com>
> 
> Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com>
> ---
>  package/directfb/Config.in   |    4 ++--
>  package/directfb/directfb.mk |    4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/package/directfb/Config.in b/package/directfb/Config.in
> index 3d22e15..f5759db 100644
> --- a/package/directfb/Config.in
> +++ b/package/directfb/Config.in
> @@ -115,13 +115,13 @@ config BR2_PACKAGE_DIRECTFB_PNG
>  	default y
>  	select BR2_PACKAGE_LIBPNG
>  
> -config BR2_PACKAGE_DIRECTB_DITHER_RGB16
> +config BR2_PACKAGE_DIRECTFB_DITHER_RGB16
>  	bool "enable advanced dithering of RGB16 surfaces"
>  	help
>  	  Enable dithering when loading images to RGB16 surfaces.
>  	  This increases the data section by 64 KBytes.


This is good, but since you're renaming configuration options, you
should add something to the main Config.in.legacy:

config BR2_PACKAGE_DIRECTB_DITHER_RGB16
	bool "DirectFB RGB16 dithering option has been renamed"
	select BR2_PACKAGE_DIRECTFB_DITHER_RGB16
	select BR2_LEGACY

This way, users who will upgrade will be automatically notified of the
option rename.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] directfb: expanding the help strings

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Sun, 10 Mar 2013 10:47:37 +0100, Carsten Schoenert wrote:
> From: Carsten Schoenert <c.schoenert@gmail.com>
> 
> Adding a helper string for the PXA3xx and graphics driver from Marvell
> and the EP9x graphics driver from Cirrus Logic.
> 
> Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com>
> ---
>  package/directfb/Config.in |   17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/package/directfb/Config.in b/package/directfb/Config.in
> index a184568..3d22e15 100644
> --- a/package/directfb/Config.in
> +++ b/package/directfb/Config.in
> @@ -49,10 +49,27 @@ config BR2_PACKAGE_DIRECTFB_MATROX
>  config BR2_PACKAGE_DIRECTFB_PXA3XX
>  	bool "compile pxa3xx graphics driver"
>  	depends on BR2_arm
> +    help
> +      The Marvell PXA3xx Processor Family is a system-on-chip based
> +      on XScale? microarchitecture. The PXA3xx processor provide
> +      high-performance multimedia, low-power capabilities, and rich
> +      peripheral integration. The PXA3xx Processor Family provide
> +      enhanced features compared to the PXA27x Processor Family, and
> +      are the first Marvell applications processors to integrate a
> +      hardware video accelerator unit.
> +
> +      http://www.marvell.com/application-processors/pxa-family/

Indentation is wrong. It should be one tab for "help" and one tab + two
spaces for the help text.

In addition to that, I'm not sure the wording of the help text is so
useful. Something like "This option enables a graphics driver specific
to the graphics hardware of the Marvell PXA3xx processor family", would
be a bit more useful.

>  config BR2_PACKAGE_DIRECTFB_EP9X
>  	bool "compile ep9x graphics driver"
>  	depends on BR2_arm
> +    help
> +      The EP93xx ARMv9 based processors from Cirrus Logic are highly
> +      integrated systems-on-a-chip that pave the way for a multitude
> +      of next-generation consumer and industrial electronic products.
> +
> +      http://cirrus.com/en/products/arm9.html

Same comments.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Sun, 10 Mar 2013 10:47:35 +0100, Carsten Schoenert wrote:

> -DIRECTFB_VERSION_MAJOR = 1.4
> -DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).17
> +DIRECTFB_VERSION_MAJOR = 1.6
> +DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).3
>  DIRECTFB_SITE = http://www.directfb.org/downloads/Core/DirectFB-$(DIRECTFB_VERSION_MAJOR)
>  DIRECTFB_SOURCE = DirectFB-$(DIRECTFB_VERSION).tar.gz
>  DIRECTFB_LICENSE = LGPLv2.1+

This looks good. However, we have a number of packages that depend or
can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2,
links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you
test if those still build after this DirectFB bump? I have no idea if
the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API
breakage) or a minor bump. Depending on that, some testing of the
packages using DirectFB would be needed, or not.

Note that we don't necessarily require all those packages to continue
to build with DirectFB 1.6.x: if those packages haven't adapted to the
new DirectFB versions, then it's an upstream problem. However, if some
of those packages don't build, it would be good to update their
Config.in to ensure that the DirectFB variant is no longer offered/used.

Also, do just a reasonable amount of testing: our autobuilders will
anyway do a global testing of many combinations. But it's good to at
least check a few packages. If they work fine with the DirectFB bump,
then it's a good indication that the DirectFB bump probably didn't
introduce too much API breakage.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 3/4] directfb: expanding the help strings

[Carsten Schoenert]

Hello Thomas,

Am 10.03.2013 11:27, schrieb Thomas Petazzoni:
>> +    help
>> +      The Marvell PXA3xx Processor Family is a system-on-chip based
>> +      on XScale? microarchitecture. The PXA3xx processor provide
>> +      high-performance multimedia, low-power capabilities, and rich
>> +      peripheral integration. The PXA3xx Processor Family provide
>> +      enhanced features compared to the PXA27x Processor Family, and
>> +      are the first Marvell applications processors to integrate a
>> +      hardware video accelerator unit.
>> +
>> +      http://www.marvell.com/application-processors/pxa-family/
> 
> Indentation is wrong. It should be one tab for "help" and one tab + two
> spaces for the help text.

Hmm, I have to check my vim settings, sorry.
What about modlines in thees files? This would be helpful and it's just
a one-liner on top of this files.

> In addition to that, I'm not sure the wording of the help text is so
> useful. Something like "This option enables a graphics driver specific
> to the graphics hardware of the Marvell PXA3xx processor family", would
> be a bit more useful.

It have take some times for me to find out what this option is for and
what kind of devices are supported by this option, so at least directfb
is something for the frame buffer the most people know the options are
of course depending on this frame buffer and graphic output related things.
So I think it's worth to explain a little bit more than just 'it's for
the Marvel PXA family foo ...'. But yes, we can discuss about the word
and formulation. ;)
I will rethink about that.

Regards
Carsten

[Buildroot] [PATCH 4/4] directfb: fixing typo in variables

[Carsten Schoenert]

Hello Thomas,

Am 10.03.2013 11:25, schrieb Thomas Petazzoni:
> This is good, but since you're renaming configuration options, you
> should add something to the main Config.in.legacy:
> 
> config BR2_PACKAGE_DIRECTB_DITHER_RGB16
> 	bool "DirectFB RGB16 dithering option has been renamed"
> 	select BR2_PACKAGE_DIRECTFB_DITHER_RGB16
> 	select BR2_LEGACY
> 
> This way, users who will upgrade will be automatically notified of the
> option rename.

Ahh, o.k. Don't know about this file, thanks for pointing at it. I take
a look at it and rework it.

Regards
Carsten

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Carsten Schoenert]

Hello Thomas,

Am 10.03.2013 11:32, schrieb Thomas Petazzoni:
> This looks good. However, we have a number of packages that depend or
> can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2,
> links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you
> test if those still build after this DirectFB bump? I have no idea if
> the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API
> breakage) or a minor bump. Depending on that, some testing of the
> packages using DirectFB would be needed, or not.

Ah yes, good point! I'll pick up some of these packages an will do some
tests.
But I have to look once again to the config of directfb itself, I think
there will have changed some configure options between this different
versions of directfb. This point comes right now in mind.

> Note that we don't necessarily require all those packages to continue
> to build with DirectFB 1.6.x: if those packages haven't adapted to the
> new DirectFB versions, then it's an upstream problem. However, if some
> of those packages don't build, it would be good to update their
> Config.in to ensure that the DirectFB variant is no longer offered/used.

Indeed, there will hopefully be not to much packages affected. It
depends a little bit on the test locally or done by the autobuilders.

> Also, do just a reasonable amount of testing: our autobuilders will
> anyway do a global testing of many combinations. But it's good to at
> least check a few packages. If they work fine with the DirectFB bump,
> then it's a good indication that the DirectFB bump probably didn't
> introduce too much API breakage.

That's good, I can here just check the build with my arm toolchain. ;)

O.k. now I need some time to readjust the patchset, thanks for your
suggestions!

Regards
Carsten

[Buildroot] [PATCH 3/4] directfb: expanding the help strings

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Sun, 10 Mar 2013 13:21:06 +0100, Carsten Schoenert wrote:

> > Indentation is wrong. It should be one tab for "help" and one tab + two
> > spaces for the help text.
> 
> Hmm, I have to check my vim settings, sorry.
> What about modlines in thees files? This would be helpful and it's just
> a one-liner on top of this files.

I don't have a very strong opinion about this, but vim would require
one modeline, Emacs would require another one, some other $editor would
require yet a different one.

I guess it's rather up to your editor to understand that Config.in
should be treated with such or such mode.

> > In addition to that, I'm not sure the wording of the help text is so
> > useful. Something like "This option enables a graphics driver specific
> > to the graphics hardware of the Marvell PXA3xx processor family", would
> > be a bit more useful.
> 
> It have take some times for me to find out what this option is for and
> what kind of devices are supported by this option, so at least directfb
> is something for the frame buffer the most people know the options are
> of course depending on this frame buffer and graphic output related things.
> So I think it's worth to explain a little bit more than just 'it's for
> the Marvel PXA family foo ...'. But yes, we can discuss about the word
> and formulation. ;)
> I will rethink about that.

My only problem with your wording is that it was just the copy/paste
describing what the processor is. The reader may not necessarily see
the relation with the configuration option. So just keep your text, but
at the beginning at a sentence like "This option enables a graphics
driver blablabla".

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Carsten Schoenert]

Hello Thomas,

Am 10.03.2013 11:32, schrieb Thomas Petazzoni:
> This looks good. However, we have a number of packages that depend or
> can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2,
> links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you
> test if those still build after this DirectFB bump? I have no idea if
> the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API
> breakage) or a minor bump. Depending on that, some testing of the
> packages using DirectFB would be needed, or not.

I have greped which packages depending direct on the directfb package,
this aren't much, I was a little bit surprised and suspected more packages.

> $ git grep -n "depends on BR2_PACKAGE_DIRECTFB"
> package/directfb-examples/Config.in:3:  depends on BR2_PACKAGE_DIRECTFB
> ... # more hits on directfb-exables

I tested the directfb-examples, this package has to be bumped. This I
have successful tested and prepared three patches here.

> package/divine/Config.in:3:       depends on BR2_PACKAGE_DIRECTFB

Already done in one of my previous patches.

> package/efl/libecore/Config.in:15:      depends on BR2_PACKAGE_DIRECTFB

Successful builded.

> package/efl/libevas/Config.in:56:       depends on BR2_PACKAGE_DIRECTFB

Successful builded with most of the options (expect OpenGL related stuff).

> package/lite/Config.in:3:       depends on BR2_PACKAGE_DIRECTFB

Works perfect, the version is still the current version.

> package/qt/Config.gfx.in:23:    depends on BR2_PACKAGE_DIRECTFB

This I will not test, to big the QT beast. :)

> package/sawman/Config.in:3:     depends on BR2_PACKAGE_DIRECTFB

Sawan must also bumped to the current version, locally successful done
and builded. Also prepared a patch.

> package/sdl/Config.in:18:       depends on BR2_PACKAGE_DIRECTFB

SDL works successful with the new directfb version.

In summary it looks good.
So hopefully I will post later a new patch series.

Regards
Carsten

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Sun, 10 Mar 2013 17:50:37 +0100, Carsten Schoenert wrote:

> In summary it looks good.
> So hopefully I will post later a new patch series.

Excellent, thanks a lot for all this testing effort!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Carsten Schoenert]

Hello Thomas, all,

Am 10.03.2013 13:34, schrieb Carsten Schoenert:
> Hello Thomas,
> 
> Am 10.03.2013 11:32, schrieb Thomas Petazzoni:
>> This looks good. However, we have a number of packages that depend or
>> can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2,
>> links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you
>> test if those still build after this DirectFB bump? I have no idea if
>> the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API
>> breakage) or a minor bump. Depending on that, some testing of the
>> packages using DirectFB would be needed, or not.
> 
> Ah yes, good point! I'll pick up some of these packages an will do some
> tests.
> But I have to look once again to the config of directfb itself, I think
> there will have changed some configure options between this different
> versions of directfb. This point comes right now in mind.

I have diffed the output from 'configure --help' of the directfb package
from the old version (1.4.17) to the new version (1.6.3).

There are one option removed and a few new are appended.

This option is now not living anymore.
> --enable-sysfs          build with sysfs support [default=auto]

The following options ([auto])are new.
> --enable-sysfs          build with sysfs support [default=auto]
> --enable-mesa           build with Mesa support [default=auto]

And thees options are [default=yes].
> --enable-dynload        enable dynload support [default=yes]                                                           
> --enable-multicore      enable multicore support [default=yes]
> --enable-mng            build MNG image provider [default=yes]
> --enable-imlib2         build Imlib2 image provider [default=yes]
> --enable-pnm            build PNM (PBM/PGM/PPM) image provider [default=yes]
> --enable-svg            build SVG image provider [default=yes]
> --enable-mpeg2          build MPEG2 image provider [default=yes]
> --enable-bmp            build BMP image provider [default=yes]
> --enable-jpeg2000       build JPEG2000 image provider [default=yes]

And at last one option with [default=no].
> --enable-gstreamer      build gstreamer video provider [default=no]

I'm not already getting the logic inside the directfb.mk so how to
handle thees different options in the future? I mean, what's the point
to implement a configure option or not? I know some options are platform
specific and for me it is particularly implemented.

For example, there are configure options for jpeg, gif and png support
but not for freetype (all this configure options are [default=yes]) and
freetype is also explicitly set per default in the DIRECTFB_CONF_OPT
with '--enable-freetype'.

Why are the options for the gfxdrivers and inputlist are not complete
filled in the Config.in and directfb.mk file?
In the directfb.mk file is a check for BR2_PACKAGE_DIRECTFB_CYBER5K but
the Config.in file has no option for this. Forgotten?

I can try to rework this two files, but to save unneeded work any help
is appreciated. Can someone point me to the right direction?

Regards
Carsten

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Arnout Vandecappelle]

On 17/03/13 14:59, Carsten Schoenert wrote:
> Hello Thomas, all,
>
> Am 10.03.2013 13:34, schrieb Carsten Schoenert:
[snip]
> This option is now not living anymore.
>> --enable-sysfs          build with sysfs support [default=auto]
>
> The following options ([auto])are new.
>> --enable-sysfs          build with sysfs support [default=auto]

  Er, I guess you made a mistake here? sysfs support is still an option?

>> --enable-mesa           build with Mesa support [default=auto]
>
> And thees options are [default=yes].
>> --enable-dynload        enable dynload support [default=yes]
>> --enable-multicore      enable multicore support [default=yes]
>> --enable-mng            build MNG image provider [default=yes]
>> --enable-imlib2         build Imlib2 image provider [default=yes]
>> --enable-pnm            build PNM (PBM/PGM/PPM) image provider [default=yes]
>> --enable-svg            build SVG image provider [default=yes]
>> --enable-mpeg2          build MPEG2 image provider [default=yes]
>> --enable-bmp            build BMP image provider [default=yes]
>> --enable-jpeg2000       build JPEG2000 image provider [default=yes]
>
> And at last one option with [default=no].
>> --enable-gstreamer      build gstreamer video provider [default=no]
>
> I'm not already getting the logic inside the directfb.mk so how to
> handle thees different options in the future? I mean, what's the point
> to implement a configure option or not? I know some options are platform
> specific and for me it is particularly implemented.
>
> For example, there are configure options for jpeg, gif and png support
> but not for freetype (all this configure options are [default=yes]) and
> freetype is also explicitly set per default in the DIRECTFB_CONF_OPT
> with '--enable-freetype'.
>
> Why are the options for the gfxdrivers and inputlist are not complete
> filled in the Config.in and directfb.mk file?
> In the directfb.mk file is a check for BR2_PACKAGE_DIRECTFB_CYBER5K but
> the Config.in file has no option for this. Forgotten?
>
> I can try to rework this two files, but to save unneeded work any help
> is appreciated. Can someone point me to the right direction?

  How it _should_ be is that as many configure options as possible are 
specified explicitly in the .mk file. In particular, any configure option 
that is set to the non-default value in the .mk file, should also be set 
explicitly to the default value.

  But of course, a lot of that is not the case now, because the rule is 
not strictly enforced. Anything you fix during the version bump is nice 
to have, but you're not obliged to fix it if you don't know how to (and 
we expect you to have tested the change, so that means trying out a 
number of different configurations...).

  Regarding the cyber5k thing: that's indeed an oversight from when the 
gfxdrivers options were added. Since nobody has complained about it, I 
guess you can just remove the option. Or you can add it to Config.in, 
whatever you like.

  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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Carsten Schoenert]

Hello Arnout, hello Thomas,

Am 21.03.2013 07:56, schrieb Arnout Vandecappelle:
>> This option is now not living anymore.
>>> --enable-sysfs          build with sysfs support [default=auto]
>>
>> The following options ([auto])are new.
>>> --enable-sysfs          build with sysfs support [default=auto]
> 
>   Er, I guess you made a mistake here? sysfs support is still an option?

Yes and no. :)
Yes, I made a copy & paste error, and No, the '-sysfs' option isn't
there in version 1.6.3.

>> I can try to rework this two files, but to save unneeded work any help
>> is appreciated. Can someone point me to the right direction?
> 
>   How it _should_ be is that as many configure options as possible are 
> specified explicitly in the .mk file. In particular, any configure option 
> that is set to the non-default value in the .mk file, should also be set 
> explicitly to the default value.

You mean for example
  --enable-svg            build SVG image provider [default=yes]
should be set by default to 'yes' and so on for the other 'default=yes'
options?
The options with default=auto should will be automaticly detected by
configure and mostly it isn't useful to explicitly deactivating them
because that breaks the binarys so leaving them.

>   But of course, a lot of that is not the case now, because the rule is 
> not strictly enforced. Anything you fix during the version bump is nice 
> to have, but you're not obliged to fix it if you don't know how to (and 
> we expect you to have tested the change, so that means trying out a 
> number of different configurations...).

Yes I can't test all variations so thats why I ask here how to do it
best. I'm working with a toolchain for a ARMv6 platform on a settopbox
there we need directfb so I test mostly of my work on this settopbox.

>   Regarding the cyber5k thing: that's indeed an oversight from when the 
> gfxdrivers options were added. Since nobody has complained about it, I 
> guess you can just remove the option. Or you can add it to Config.in, 
> whatever you like.

O.k. now it is a bit clearly to me. Hopefully I find some time on the
weekend to get into it. Thanks for your suggestions.

Regards
Carsten

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Thomas Petazzoni]

Dear Carsten Schoenert,

On Thu, 21 Mar 2013 19:06:13 +0100, Carsten Schoenert wrote:

> >   How it _should_ be is that as many configure options as possible are 
> > specified explicitly in the .mk file. In particular, any configure option 
> > that is set to the non-default value in the .mk file, should also be set 
> > explicitly to the default value.
> 
> You mean for example
>   --enable-svg            build SVG image provider [default=yes]
> should be set by default to 'yes' and so on for the other 'default=yes'
> options?
> The options with default=auto should will be automaticly detected by
> configure and mostly it isn't useful to explicitly deactivating them
> because that breaks the binarys so leaving them.

No, I think Arnout means that we should leave as few options
"automatically" detected as possible.

For example, we really like to have:

ifeq ($(BR2_PACKAGE_FOO_FEATURE_BAR),y)
FOO_CONF_OPT += --enable-bar
else
FOO_CONF_OPT += --disable-bar
endif

and for all options that are not explicitly --enable-<bleh> somewhere,
have a global:

FOO_CONF_OPT += \
	--disable-<bleh> \
	--disable-<blah>

this avoids the configure script from automatically detecting things on
the host machine that we don't want it to detect.

> >   But of course, a lot of that is not the case now, because the rule is 
> > not strictly enforced. Anything you fix during the version bump is nice 
> > to have, but you're not obliged to fix it if you don't know how to (and 
> > we expect you to have tested the change, so that means trying out a 
> > number of different configurations...).
> 
> Yes I can't test all variations so thats why I ask here how to do it
> best. I'm working with a toolchain for a ARMv6 platform on a settopbox
> there we need directfb so I test mostly of my work on this settopbox.

We have autobuilders that test a big number of random configurations,
so you definitely don't have to test all combinations.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3

[Carsten Schoenert]

Hello Thomas, Hello Arnout,

Am 21.03.2013 20:13, schrieb Thomas Petazzoni:
> No, I think Arnout means that we should leave as few options
> "automatically" detected as possible.
> 
> For example, we really like to have:
> 
> ifeq ($(BR2_PACKAGE_FOO_FEATURE_BAR),y)
> FOO_CONF_OPT += --enable-bar
> else
> FOO_CONF_OPT += --disable-bar
> endif
> 
> and for all options that are not explicitly --enable-<bleh> somewhere,
> have a global:
> 
> FOO_CONF_OPT += \
> 	--disable-<bleh> \
> 	--disable-<blah>
> 
> this avoids the configure script from automatically detecting things on
> the host machine that we don't want it to detect.

some little status info on that.
The last days I worked on the "new" Config.in and the directfb.mk
Makefile with your suggestions. Until now I would say the most options
are implemented and I can also build the most of them.
But I found some issues inside the directfb archive (missing headers :)
and some code errors). I found one patch to fix the code errors and cook
one other to fix a configure problem, but the missing headers are just
to fix if the package would switch to a git checkout.

I wrote up to upstream to fix the header and the code error. I will wait
for response and in the between time I will more clean up my current
work. Some of the new options have new dependencies like libsvg-cairo,
linotyp, mng or jasper for jpeg2000. The libsvg-cairo package I will try
to implement if I find some free time for it, the other dependencies
have to find some other person. ;)

Regards
Carsten