Patchwork [v3,12/12] xf86-video-omap: add new recipe to follow the maintained repo

login
register
mail settings
Submitter Laurentiu Palcu
Date Nov. 14, 2012, 1:21 p.m.
Message ID <7f73d8a0aee08a41e949ec7a1297f5edbf12ed57.1352898505.git.laurentiu.palcu@intel.com>
Download mbox | patch
Permalink /patch/39029/
State Accepted
Commit 0ed7c53de9eb44f1f6105361e3639f6ddbeecdc5
Headers show

Comments

Laurentiu Palcu - Nov. 14, 2012, 1:21 p.m.
This new recipe is needed because the old driver is unmaintained. This
new recipe will follow the new repo.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 .../xorg-driver/xf86-video-omap_git.bb             |   31 ++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
Martin Jansa - Nov. 21, 2012, 4:20 p.m.
On Wed, Nov 14, 2012 at 03:21:10PM +0200, Laurentiu Palcu wrote:
> This new recipe is needed because the old driver is unmaintained. This
> new recipe will follow the new repo.

On which MACHINE did you test this? Here it fails in do_configure with:
| configure:18796: result: yes
| configure:18808: checking whether to include DRI support
| configure:18812: checking for /usr/include/xorg/dri.h
| configure:18818: error: cannot check for file existence when cross compiling

So I'm wondering if it was tested at all.

With xf86-video-omapfb not ported to xserver-1.13 video API it makes new
default xserver from oe-core unusable on many armv7a machines..

Cheers,

> 
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>  .../xorg-driver/xf86-video-omap_git.bb             |   31 ++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>  create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
> 
> diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb b/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
> new file mode 100644
> index 0000000..b3177eb
> --- /dev/null
> +++ b/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
> @@ -0,0 +1,31 @@
> +require xorg-driver-video.inc
> +
> +SUMMARY = "X.Org X server -- Texas Instruments OMAP framebuffer driver"
> +
> +DESCRIPTION = "omap driver supports the basic Texas Instruments OMAP \
> +framebuffer."
> +
> +LICENSE = "GPLv2+"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=10ce5de3b111315ea652a5f74ec0c602"
> +DEPENDS += "virtual/libx11 libdrm"
> +
> +RPROVIDES = "xf86-video-omapfb"
> +RCONFLICTS = "xf86-video-omapfb"
> +RREPLACES = "xf86-video-omapfb"
> +
> +SRCREV = "ae0394e687f1a77e966cf72f895da91840dffb8f"
> +PR = "${INC_PR}.0"
> +PV = "0.4.2+gitr${SRCPV}"
> +
> +SRC_URI = "git://anongit.freedesktop.org/xorg/driver/xf86-video-omap;protocol=git \
> +"
> +
> +S = "${WORKDIR}/git"
> +
> +EXTRA_OECONF_armv7a = " --enable-neon "
> +CFLAGS += " -I${STAGING_INCDIR}/xorg "
> +
> +# Use overlay 2 on omap3 to enable other apps to use overlay 1 (e.g. dmai or omapfbplay)
> +do_compile_prepend_armv7a () {
> +        sed -i -e s:fb1:fb2:g ${S}/src/omap_xv.c
> +}
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - Nov. 21, 2012, 5:12 p.m.
On Wed, 2012-11-21 at 17:20 +0100, Martin Jansa wrote:
> On Wed, Nov 14, 2012 at 03:21:10PM +0200, Laurentiu Palcu wrote:
> > This new recipe is needed because the old driver is unmaintained. This
> > new recipe will follow the new repo.
> 
> On which MACHINE did you test this? Here it fails in do_configure with:
> | configure:18796: result: yes
> | configure:18808: checking whether to include DRI support
> | configure:18812: checking for /usr/include/xorg/dri.h
> | configure:18818: error: cannot check for file existence when cross compiling
> 
> So I'm wondering if it was tested at all.
> 
> With xf86-video-omapfb not ported to xserver-1.13 video API it makes new
> default xserver from oe-core unusable on many armv7a machines..

/usr/include/xorg/dri.h probably existed on the machine it was tested
on. I appreciate this needs to get fixed but I know it was tested.

Cheers,

Richard
Martin Jansa - Nov. 21, 2012, 5:21 p.m.
On Wed, Nov 21, 2012 at 05:12:31PM +0000, Richard Purdie wrote:
> On Wed, 2012-11-21 at 17:20 +0100, Martin Jansa wrote:
> > On Wed, Nov 14, 2012 at 03:21:10PM +0200, Laurentiu Palcu wrote:
> > > This new recipe is needed because the old driver is unmaintained. This
> > > new recipe will follow the new repo.
> > 
> > On which MACHINE did you test this? Here it fails in do_configure with:
> > | configure:18796: result: yes
> > | configure:18808: checking whether to include DRI support
> > | configure:18812: checking for /usr/include/xorg/dri.h
> > | configure:18818: error: cannot check for file existence when cross compiling
> > 
> > So I'm wondering if it was tested at all.
> > 
> > With xf86-video-omapfb not ported to xserver-1.13 video API it makes new
> > default xserver from oe-core unusable on many armv7a machines..
> 
> /usr/include/xorg/dri.h probably existed on the machine it was tested
> on. I appreciate this needs to get fixed but I know it was tested.

Doesn't AC_CHECK_FILE macro fail the same when it does exist?

Cheers,
Ross Burton - Nov. 21, 2012, 8:04 p.m.
On 21 November 2012 17:21, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > So I'm wondering if it was tested at all.
>> >
>> > With xf86-video-omapfb not ported to xserver-1.13 video API it makes new
>> > default xserver from oe-core unusable on many armv7a machines..
>>
>> /usr/include/xorg/dri.h probably existed on the machine it was tested
>> on. I appreciate this needs to get fixed but I know it was tested.
>
> Doesn't AC_CHECK_FILE macro fail the same when it does exist?

AC_CHECK_FILE always fails when cross-compiling. Any instances of it
should be replaced with something more useful - especially header
checks that should be using pkgconfig. I recommend patching the build
to use pkgconfig and sending the patch upstream.

Ross
Laurentiu Palcu - Nov. 22, 2012, 8:31 a.m.
On 11/21/2012 06:20 PM, Martin Jansa wrote:
> On Wed, Nov 14, 2012 at 03:21:10PM +0200, Laurentiu Palcu wrote:
>> > This new recipe is needed because the old driver is unmaintained. This
>> > new recipe will follow the new repo.
> On which MACHINE did you test this? Here it fails in do_configure with:
> | configure:18796: result: yes
> | configure:18808: checking whether to include DRI support
> | configure:18812: checking for /usr/include/xorg/dri.h
> | configure:18818: error: cannot check for file existence when cross compiling
> 
> So I'm wondering if it was tested at all.
> 
Martin,

I remember that I clearly mentioned, in the cover letter, the commit
upon which I applied the patches before compiling the nightlies for all
architectures. Here it is:

"The yocto autobuilder nightlies (x86/x86_64/ppc/arm/mips) compiled
successfully. Compilations were done on top of the following commit:
78983e939ab17f02f8911c8b0d0e326b419856b9."

At the moment I was working on the xorg upgrades this was the last
commit... Did you try the patches on top of this commit? Does the
compilation fail?

Thanks,
Laurentiu
Martin Jansa - Nov. 22, 2012, 8:37 a.m.
On Thu, Nov 22, 2012 at 10:31:51AM +0200, Laurentiu Palcu wrote:
> 
> 
> On 11/21/2012 06:20 PM, Martin Jansa wrote:
> > On Wed, Nov 14, 2012 at 03:21:10PM +0200, Laurentiu Palcu wrote:
> >> > This new recipe is needed because the old driver is unmaintained. This
> >> > new recipe will follow the new repo.
> > On which MACHINE did you test this? Here it fails in do_configure with:
> > | configure:18796: result: yes
> > | configure:18808: checking whether to include DRI support
> > | configure:18812: checking for /usr/include/xorg/dri.h
> > | configure:18818: error: cannot check for file existence when cross compiling
> > 
> > So I'm wondering if it was tested at all.
> > 
> Martin,
> 
> I remember that I clearly mentioned, in the cover letter, the commit
> upon which I applied the patches before compiling the nightlies for all
> architectures. Here it is:
> 
> "The yocto autobuilder nightlies (x86/x86_64/ppc/arm/mips) compiled
> successfully. Compilations were done on top of the following commit:
> 78983e939ab17f02f8911c8b0d0e326b419856b9."

Does qemuarm include this driver? I guess not. I don't know what exactly
is "autobuilder nightlies" but did it include xf86-video-omap explicitly
or just some generic image?

Also I cannot find this commit in oe-core as well as poky (I'm using
oe-core).

> At the moment I was working on the xorg upgrades this was the last
> commit... Did you try the patches on top of this commit? Does the
> compilation fail?

No I try to use master.

Cheers,
Laurentiu Palcu - Nov. 22, 2012, 8:59 a.m.
> 
> Does qemuarm include this driver? I guess not. I don't know what exactly
> is "autobuilder nightlies" but did it include xf86-video-omap explicitly
> or just some generic image?
The autobuilder nightly for arm (for example) does, among other things,
the following:
* Builds core-image-sato, core-image-sato-dev, core-image-sato-sdk,
core-image-minimal, core-image-minimal-dev for qemuarm
* Builds core-image-sato, core-image-sato-sdk, core-image-minimal for
beagleboard
* Builds the meta-toolchain-gmae

Here's a link to one of the latest arm nightly builds. You can see that,
for beagleboard, it includes xf86-video-omap driver:

http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/727

This is the production autobuilder. The autobuilder server I used to
test the patches is internal and cannot be accessed from outside.
> 
> Also I cannot find this commit in oe-core as well as poky (I'm using
> oe-core).
Here's the link:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=78983e939ab17f02f8911c8b0d0e326b419856b9

Thanks,
Laurentiu
Nicolas Dechesne - Nov. 22, 2012, 12:34 p.m.
On Thu, Nov 22, 2012 at 9:59 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>
> The autobuilder nightly for arm (for example) does, among other things,
> the following:
> * Builds core-image-sato, core-image-sato-dev, core-image-sato-sdk,
> core-image-minimal, core-image-minimal-dev for qemuarm
> * Builds core-image-sato, core-image-sato-sdk, core-image-minimal for
> beagleboard
> * Builds the meta-toolchain-gmae
>
> Here's a link to one of the latest arm nightly builds. You can see that,
> for beagleboard, it includes xf86-video-omap driver:
>
> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/727
>
> This is the production autobuilder. The autobuilder server I used to
> test the patches is internal and cannot be accessed from outside.


and we can see that the build failed with

| checking for ANSI C header files... (cached) yes
| checking whether to include DRI support... checking for
/usr/include/xorg/dri.h... configure: error: cannot check for file
existence when cross compiling
| Configure failed. The contents of all config.log files follows to
aid debugging
| /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-arm/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xf86-video-omap/2_0.4.2+gitr1+ae0394e687f1a77e966cf72f895da91840dffb8f-r20.0/git/config.log
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.
|
| It was created by xf86-video-omap configure 0.4.2, which was
| generated by GNU Autoconf 2.69.  Invocation command line was

from http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/727/steps/shell_55/logs/stdio

I am looking at Ross patch, as our configure.ac file is clearly wrong
here in xf86-video-omap (in fact most of the testing for this X11
driver was done in ubuntu, so using native compilation...). will make
sure to get that fixed upstream asap.
Martin Jansa - Nov. 22, 2012, 12:43 p.m.
On Thu, Nov 22, 2012 at 1:34 PM, Nicolas Dechesne <ndec13@gmail.com> wrote:
> On Thu, Nov 22, 2012 at 9:59 AM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>>
>> The autobuilder nightly for arm (for example) does, among other things,
>> the following:
>> * Builds core-image-sato, core-image-sato-dev, core-image-sato-sdk,
>> core-image-minimal, core-image-minimal-dev for qemuarm
>> * Builds core-image-sato, core-image-sato-sdk, core-image-minimal for
>> beagleboard
>> * Builds the meta-toolchain-gmae
>>
>> Here's a link to one of the latest arm nightly builds. You can see that,
>> for beagleboard, it includes xf86-video-omap driver:
>>
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/727
>>
>> This is the production autobuilder. The autobuilder server I used to
>> test the patches is internal and cannot be accessed from outside.
>
>
> and we can see that the build failed with
>
> | checking for ANSI C header files... (cached) yes
> | checking whether to include DRI support... checking for
> /usr/include/xorg/dri.h... configure: error: cannot check for file
> existence when cross compiling
> | Configure failed. The contents of all config.log files follows to
> aid debugging
> | /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-arm/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xf86-video-omap/2_0.4.2+gitr1+ae0394e687f1a77e966cf72f895da91840dffb8f-r20.0/git/config.log
> | This file contains any messages produced by compilers while
> | running configure, to aid debugging if configure makes a mistake.
> |
> | It was created by xf86-video-omap configure 0.4.2, which was
> | generated by GNU Autoconf 2.69.  Invocation command line was
>
> from http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/727/steps/shell_55/logs/stdio
>
> I am looking at Ross patch, as our configure.ac file is clearly wrong
> here in xf86-video-omap (in fact most of the testing for this X11
> driver was done in ubuntu, so using native compilation...). will make
> sure to get that fixed upstream asap.

Ross's patch fixes the build issue, but then xf86-video-omap does not
work in runtime (at least on nokia900)

[   275.922] (II) Module omap: vendor="X.Org Foundation"
[   275.922]    compiled for 1.13.0, module version = 0.83.0
[   275.922]    Module class: X.Org Video Driver
[   275.922]    ABI class: X.Org Video Driver, version 13.0
[   275.924] (II) OMAP: Driver for TI OMAP: OMAP3430 with PowerVR SGX530,
        OMAP3630 with PowerVR SGX530, OMAP4430 with PowerVR SGX540,
        OMAP4460 with PowerVR SGX540, OMAP5430 with PowerVR SGX544 MP,
        OMAP5432 with PowerVR SGX544 MP
[   275.925] (--) using VT number 2

[   275.944] (WW) Falling back to old probe method for omap
[   276.469] (EE) No devices detected.

Well that's probably the same issue GNUtoo reported on xf86-video-omap
patch, before it was merged and xf86-video-omapfb removed..

Pity that bits of red in autobuilder logs are the most important
quality indicator for some people...

Cheers,
Ross Burton - Nov. 22, 2012, 2:05 p.m.
On 22 November 2012 12:43, Martin Jansa <martin.jansa@gmail.com> wrote:
> Well that's probably the same issue GNUtoo reported on xf86-video-omap
> patch, before it was merged and xf86-video-omapfb removed..
>
> Pity that bits of red in autobuilder logs are the most important
> quality indicator for some people...

Bits of red that nobody is willing to fix?  If you've the hardware to
test it on, and the need for it to work, the backporting the
compat-api changes (which have been made to every other video driver)
isn't *that* difficult.

Ross
Martin Jansa - Nov. 22, 2012, 2:09 p.m.
On Thu, Nov 22, 2012 at 02:05:21PM +0000, Burton, Ross wrote:
> On 22 November 2012 12:43, Martin Jansa <martin.jansa@gmail.com> wrote:
> > Well that's probably the same issue GNUtoo reported on xf86-video-omap
> > patch, before it was merged and xf86-video-omapfb removed..
> >
> > Pity that bits of red in autobuilder logs are the most important
> > quality indicator for some people...
> 
> Bits of red that nobody is willing to fix?  If you've the hardware to
> test it on, and the need for it to work, the backporting the
> compat-api changes (which have been made to every other video driver)
> isn't *that* difficult.

As said in other thread I did that already for xf86-video-glamo in
meta-oe, so I agree that it's not *that* difficult.

But I'm not sending xf86-video-glamo change before it's tested not only
to build, but also to work in runtime.

And I cannot work on xf86-video-omapfb now, because builder is still
rebuilding armv7a after last layout changes.

Cheers,
Nicolas Dechesne - Nov. 22, 2012, 2:26 p.m.
On Thu, Nov 22, 2012 at 3:09 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> As said in other thread I did that already for xf86-video-glamo in
> meta-oe, so I agree that it's not *that* difficult.
>
> But I'm not sending xf86-video-glamo change before it's tested not only
> to build, but also to work in runtime.
>
> And I cannot work on xf86-video-omapfb now, because builder is still
> rebuilding armv7a after last layout changes.

xf86-video-omap was largely developped and tested on OMAP4 and OMAP5
(Panda). it was tested at some point on OMAP3 (beagle), but not
intensively.

when i introduced it in our meta-ti layer, we took care of using it
for Panda only, see:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=410dc026f2ee24a2346e7563a83f0181c79809cf
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=95e12712ddffcc7ec0789a8700137afe2e449445

what I would suggest given the current situation is to fallback to
fbdev until either someone properly tests this new driver on OMAP3, or
someone ports omapfb on new X11. I would not recommend to remove
xf86-video-omap as we are using it for Panda.

Also note that as mentioned here, video-omap needs omapdrm driver
(from staging) as well as CMA support. these bits need to make it in
the kernel before video-omap can be safely used on OMAP3.

Patch

diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb b/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
new file mode 100644
index 0000000..b3177eb
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
@@ -0,0 +1,31 @@ 
+require xorg-driver-video.inc
+
+SUMMARY = "X.Org X server -- Texas Instruments OMAP framebuffer driver"
+
+DESCRIPTION = "omap driver supports the basic Texas Instruments OMAP \
+framebuffer."
+
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=10ce5de3b111315ea652a5f74ec0c602"
+DEPENDS += "virtual/libx11 libdrm"
+
+RPROVIDES = "xf86-video-omapfb"
+RCONFLICTS = "xf86-video-omapfb"
+RREPLACES = "xf86-video-omapfb"
+
+SRCREV = "ae0394e687f1a77e966cf72f895da91840dffb8f"
+PR = "${INC_PR}.0"
+PV = "0.4.2+gitr${SRCPV}"
+
+SRC_URI = "git://anongit.freedesktop.org/xorg/driver/xf86-video-omap;protocol=git \
+"
+
+S = "${WORKDIR}/git"
+
+EXTRA_OECONF_armv7a = " --enable-neon "
+CFLAGS += " -I${STAGING_INCDIR}/xorg "
+
+# Use overlay 2 on omap3 to enable other apps to use overlay 1 (e.g. dmai or omapfbplay)
+do_compile_prepend_armv7a () {
+        sed -i -e s:fb1:fb2:g ${S}/src/omap_xv.c
+}