Qt4, armv6, xserver-xorg changes

From: Simon Busch <[email protected]>

With b40b9c024be5e1ec81a31961158b3e6b529acfe0 some pkg-config fixups where removed from qt4.inc which breaks the pkg-config files for qt4-embedded. Without that the pkg-config files for qt4-x11-free are broken. So this patch puts the fixes into the qt4-x11-free.inc file to be used by qt4-x11-free and not qt4-embedded.

Quoted 7 lines · On Wednesday 12 October 2011 08:45:03 Martin Jansa wrote:

From: Simon Busch <[email protected]>

With b40b9c024be5e1ec81a31961158b3e6b529acfe0 some pkg-config fixups where removed from qt4.inc which breaks the pkg-config files for qt4-embedded. Without that the pkg-config files for qt4-x11-free are broken. So this patch puts the fixes into the qt4-x11-free.inc file to be used by qt4-x11-free and not qt4-embedded.

So why do we need these only in the X11 version? Surely they should be applicable to both embedded and X11, or not at all...?

Quoted 11 lines · Paul Eggleton

Quoted 7 lines · On Wednesday 12 October 2011 08:45:03 Martin Jansa wrote:

From: Simon Busch <[email protected]>

With b40b9c024be5e1ec81a31961158b3e6b529acfe0 some pkg-config fixups where removed from qt4.inc which breaks the pkg-config files for qt4-embedded. Without that the pkg-config files for qt4-x11-free are broken. So this patch puts the fixes into the qt4-x11-free.inc file to be used by qt4-x11-free and not qt4-embedded.

So why do we need these only in the X11 version? Surely they should be applicable to both embedded and X11, or not at all...?

With b40b9c024be5e1ec81a31961158b3e6b529acfe0 I removed this fixups from qt4.inc as I had problems with building agains qt4-embedded as cflags were incorrect in the created pkg-config files.

Now I switched my application to x11 and got other problems with the pkg-config files from qt4-x11-free which can be resolved with the fixups I removed before.

So you are right we need them for qt4-x11-free but not for qt4-embedded. I didn't investigated from where these differences are coming.

regards,
Simon

-TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"

This patch doesn't seem to do what it says in the subject line. It doesn't add an "armv6-novfp" tune, instead it removes vfp from the existing armv6 and armv6t tunes.

Quoted 3 lines

This patch doesn't seem to do what it says in the subject line. It doesn't add an "armv6-novfp" tune, instead it removes vfp from the existing armv6 and armv6t tunes.

yes that's what it does,but it also adds an armv6-vfp. The commit message is wrong, sorry.

by the way is the content ok? or should I re-do the content too(if so I would need some indications of what the right way is)?

This work was made by Victor Enriquez and then modified by Denis Carikli who was helped by Mark Hatle comments( who is fray on #yocto channel on Freenode ).

The changes are for adding support to armv6-novfp, forbuilding binaries for armv6 machines without vfp, for examplethe htcdream.

Signed-off-by Denis 'GNUtoo' Carikli<[email protected]>

Signed-off-by vquicksilver<[email protected]>

---
  meta/conf/machine/include/arm/arch-armv6.inc      |   31 +++++++++++++--------
  meta/conf/machine/include/arm/feature-arm-vfp.inc |    4 ++-
  2 files changed, 22 insertions(+), 13 deletions(-)

meta/conf/machine/include/arm/arch-armv6.inc +0 -0

index da8274e..3396c69 100644

meta/conf/machine/include/arm/arch-armv6.inc +18 -10

  require conf/machine/include/arm/arch-armv5-dsp.inc
 
  # Little Endian
-AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
+AVAILTUNES += "armv6-novfp armv6 armv6t armv6t-novfp armv6hf armv6thf"
+TUNE_FEATURES_tune-armv6-novfp ?= "armv6"
  TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
+TUNE_FEATURES_tune-armv6t-novfp ?= "armv6 thumb"
  TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"
  TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
  TUNE_FEATURES_tune-armv6thf ?= "${TUNE_FEATURES_tune-armv6t} callconvention-hard"
-PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp"
-PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp"
-PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp"
-PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6-novfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5e} armv6-novfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-novfp armv6"
+PACKAGE_EXTRA_ARCHS_tune-armv6t-novfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5e} armv6-novfp armv6t-novfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-novfp armv6t-novfp armv6-vfp armv6t"
+PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf"
+PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf"
 
  # Big Endian
-AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
+AVAILTUNES += "armv6b-novfp armv6b armv6tb-novfp armv6tb armv6hfb armv6thfb"
+TUNE_FEATURES_tune-armv6b-novfp ?= "${TUNE_FEATURES_tune-armv6-novfp} bigendian"
  TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
+TUNE_FEATURES_tune-armv6tb-novfp ?= "${TUNE_FEATURES_tune-armv6t-novfp} bigendian"
  TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
  TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
  TUNE_FEATURES_tune-armv6thfb ?= "${TUNE_FEATURES_tune-armv6tb} callconvention-hard"
-PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp} armv6b-vfp"
-PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp} armv6b-vfp armv6tb-vfp"
-PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp"
-PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6b-novfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5eb} armv6b-novfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp} armv6b"
+PACKAGE_EXTRA_ARCHS_tune-armv6tb-novfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5eb} armv6b-novfp armv6tb-novfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp} armv6b-novfp armv6tb-novfp armv6b-vfp armv6tb"
+PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb"
+PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb"
 

meta/conf/machine/include/arm/feature-arm-vfp.inc +3 -1

index 29a925c..78f453c 100644
@@ -1,5 +1,7 @@
  TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
-ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
+TUNE_ARM_VFP = "${@bb.utils.contains("ARMPKGARCH", "armv6", "", "vfp" ,d)}"
+TUNE_ARM_NOVFP = "${@bb.utils.contains("ARMPKGARCH", "armv6", "-novfp", "" ,d)}"
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "${TUNE_ARM_VFP}", "${TUNE_ARM_NOVFP}" ,d)}"
 
  TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"

This work was made by Victor Enriquez and then modified by Denis Carikli who was helped by Mark Hatle comments( who is fray on #yocto channel on Freenode ).

The changes are for adding support to armv6-novfp, forbuilding binaries for armv6 machines without vfp, for examplethe htcdream.

This work was made by Victor Enriquez and then modified by Denis Carikli who was helped by Mark Hatle comments( who is fray on #yocto channel on Freenode ).

The changes are for adding support to armv6-novfp, forbuilding binaries for armv6 machines without vfp, for examplethe htcdream.

Some typos on the commit log and missing spaces.

Signature · 8 lines

Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

This work was made by Victor Enriquez and then modified by Denis Carikli who was helped by Mark Hatle comments (who is fray on #yocto channel on Freenode).

The changes are for adding support to armv6-novfp, for building binaries for armv6 machines without vfp, for example the htc dream.

Signed-off-by Mark Hatle<[email protected]>

Signed-off-by Denis 'GNUtoo' Carikli<[email protected]>

Signed-off-by Víctor Enríquez<[email protected]>

---
  meta/conf/machine/include/arm/arch-armv6.inc      |   28 +++++++++++++-------
  meta/conf/machine/include/arm/feature-arm-vfp.inc |    4 ++-
  2 files changed, 21 insertions(+), 11 deletions(-)

meta/conf/machine/include/arm/arch-armv6.inc +3 -1

index da8274e..f9c112e 100644
@@ -10,24 +10,32 @@ MACHINEOVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "armv6", ":armv6", ""
  require conf/machine/include/arm/arch-armv5-dsp.inc
 
  # Little Endian
-AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
+AVAILTUNES += "armv6-novfp armv6 armv6t armv6t-novfp armv6hf armv6thf"
+TUNE_FEATURES_tune-armv6-novfp ?= "armv6"
  TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
+TUNE_FEATURES_tune-armv6t-novfp ?= "armv6 thumb"
  TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"

meta/conf/machine/include/arm/arch-armv6.inc +4 -1

+PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf"
+PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf"
 
  # Big Endian
-AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
+AVAILTUNES += "armv6b-novfp armv6b armv6tb-novfp armv6tb armv6hfb armv6thfb"
+TUNE_FEATURES_tune-armv6b-novfp ?= "${TUNE_FEATURES_tune-armv6-novfp} bigendian"
  TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"

meta/conf/machine/include/arm/feature-arm-vfp.inc +2 -0

+TUNE_ARM_NOVFP = "${@bb.utils.contains("ARMPKGARCH", "armv6", "-novfp", "" ,d)}"
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "${TUNE_ARM_VFP}", "${TUNE_ARM_NOVFP}" ,d)}"
 
  TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"

From: Simon Busch<[email protected]>

In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly.

Hi,

Quoted 7 lines · Martin Jansa

From: Simon Busch<[email protected]>

In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly.

When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?

Op 12 okt. 2011, om 10:02 heeft Eric Bénard het volgende geschreven:

Quoted 5 lines

Hi,

Quoted 2 lines · Martin Jansa

From: Simon Busch<[email protected]>

Quoted 6 lines

Quoted 5 lines

In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly.

When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?

We ran into this at work and like Eric, I'm curious how calibration (and e.g. dejitter) works in the linux-input world combined with qt/e.

Hi,

Quoted 10 lines · Martin Jansa

From: Simon Busch<[email protected]>

In most cases we don't need tslib in std. configuration as touchscreen access in most
devices today is done with linux input interface. If some specific machine has a need for
tslib support it should add the dependency in it's machine layer again and modify the
profile script accordingly.

When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?

Quoted 13 lines

Hi,

Quoted 10 lines · Martin Jansa

From: Simon Busch<[email protected]>

In most cases we don't need tslib in std. configuration as touchscreen access in most
devices today is done with linux input interface. If some specific machine has a need for
tslib support it should add the dependency in it's machine layer again and modify the
profile script accordingly.

Quoted 3 lines

When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?

Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing).

I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies.

If someone needs tslib for qt4-embedded for his machine layer he should include tslib support in the machine layer itself.

regards,
Simon

Signature · 6 lines

Simon Busch - http://mm.gravedo.de/blog/

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Op 12 okt. 2011 om 20:10 heeft Simon Busch <[email protected]> het volgende geschreven:

Quoted 23 lines · Eric Bénard

Quoted 13 lines

Hi,

Quoted 10 lines · Martin Jansa

From: Simon Busch<[email protected]>

In most cases we don't need tslib in std. configuration as touchscreen access in most
devices today is done with linux input interface. If some specific machine has a need for
tslib support it should add the dependency in it's machine layer again and modify the
profile script accordingly.

Quoted 3 lines

When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?

Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing).

Quoted 3 lines

I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies.

No, it should work in most cases, breaking qt:e like is not acceptable.

Quoted 27 lines

Op 12 okt. 2011 om 20:10 heeft Simon Busch <[email protected]> het volgende geschreven:

Quoted 23 lines · Eric Bénard

Quoted 13 lines

Hi,

Quoted 10 lines · Martin Jansa

From: Simon Busch<[email protected]>

In most cases we don't need tslib in std. configuration as touchscreen access in most
devices today is done with linux input interface. If some specific machine has a need for
tslib support it should add the dependency in it's machine layer again and modify the
profile script accordingly.

Quoted 3 lines

When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?

Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing).

Quoted 5 lines

Quoted 3 lines

I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies.

No, it should work in most cases, breaking qt:e like is not acceptable.

What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface).

Quoted 2 lines

What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface).

When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction.

Quoted 4 lines · Koen Kooi

Quoted 2 lines

What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface).

When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction.

You're talking here about one case where tslib is needed to get a working touchscreen. But there are even cases where tslib is not needed to get a working touchscreen.

qt:e does not strongly depends on tslib, it can work without. So if you need it you should add it to your machine layer as it is really machine specific if you need tslib or not.

Quoted 10 lines · Simon Busch

Quoted 4 lines · Koen Kooi

Quoted 2 lines

What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface).

When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction.

You're talking here about one case where tslib is needed to get a working touchscreen. But there are even cases where tslib is not needed to get a working touchscreen.

Quoted 3 lines

qt:e does not strongly depends on tslib, it can work without. So if you need it you should add it to your machine layer as it is really machine specific if you need tslib or not.

Eric brings it to the point, only resetting the qte.sh script to a default one which uses a linux input even node should be enough.

I will provide another patch in the following days which just makes qte.sh use of a std. linux input dev node instead of a tslib one if nobody has any objections against this.

Quoted 4 lines · Koen Kooi

Quoted 2 lines

What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface).

When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction.

You're talking here about one case where tslib is needed to get a working touchscreen. But there are even cases where tslib is not needed to get a working touchscreen.

Quoted 11 lines · Eric Bénard

Quoted 10 lines · Martin Jansa

From: Simon Busch<[email protected]>

In most cases we don't need tslib in std. configuration as touchscreen access in most
devices today is done with linux input interface. If some specific machine has a need for
tslib support it should add the dependency in it's machine layer again and modify the
profile script accordingly.

Quoted 3 lines

When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ?

Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing).

I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies.

If someone needs tslib for qt4-embedded for his machine layer he should include tslib support in the machine layer itself.