[OE-core] [PATCH 0/4] Fixes for xserver and omap* drivers

[Martin Jansa]

On Fri, Nov 23, 2012 at 11:18:50AM +0100, Nicolas Dechesne wrote:
> hi,
> 
> On Fri, Nov 23, 2012 at 1:47 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
> > Martin Jansa (4):
> >   xf86-video-omap: add xf86driproto dependency, drop --enable-neon and
> >     improve DESCRIPTION
> >   xserver-xorg: disable dri2 too when building without glx
> >     PACKAGECONFIG
> >   xf86-video-omapfb: revive driver which actually works and is tested
> >     on real devices
> >   xf86-video-omap: drop RPROVIDES/RREPLACES/RCONFLICTS
> 
> so, I have tested this serie on pandaboard, using meta-ti layer for
> the BSP and poky (i used master-next branch which has these patches).
> I have tested with a couple of patches that I sent to meta-ti to
> revert the xf86-video-omap that we had in meta-ti. For the reference,
> i tested with this:
> https://github.com/ndechesne/meta-ti/commits/test_new_xf-v-o (my new
> patches aren't merged yet in master).
> 
> i tested with xf86-video-omap, not -omapfb, and with a v3.4 kernel
> which I know has a working omapdrm driver.
> 
> it all looks good, the driver is loaded, and I tested resolution
> change, as well as rotation , both with xrandr command (i tested
> core-image-x11 image).
> 
> many thanks for sorting this out...
> 
> i have some questions... xf86-video-omap now clearly depends on opengl
> DISTRO_FEATURE (since dri cannot be disabled) for the xserver build.
> So if i build oe-core + meta-ti, it won't build as the xserver is
> built without dri/glx support there, and then xf86-video-omap won't
> build.

True, unfortunately without 2/4 it did build in some cases, but that
should be sorted now and fail in deterministic way. I think that without
configure.patch in xf86-video-omap it would fail in do_configure already
not in do_compile.

Maybe configure.patch should be reworked to only change AC_CHECK_FILE to
"test -f" instead of changing configure.ac so much, but I'll keep that
for Ross and upstream to decide.

>  - how should we handle that? it doesn't sound quite right to enfore a
> DISTRO feature in a recipe... but is it possible to have a check for
> opengl in the recipe? that would avoid a more cryptic build error..

I think that python fragment with SkipPackage when opengl is not in 
DISTRO_FEATURE could improve that, but that's not 100% correct too as
distro can change xserver PACKAGECONFIG (add glx) even without opengl in
DISTRO_FEATURES).

Maybe add PACKAGECONFIG[glx] to xf86-video-omap with initial value set
by opengl DISTRO_FEATURE (like xserver) does and then SkipPackage when
it's not enabled.

>  - how can I make an oe-core+meta-ti to build for Panda with this
> video driver? e.g. where should I set this DISTRO_FEATURE in meta-ti,
> outside of 'poky' distro, e.g. in a BSP layer?. I recall that we have
> this in the xserver recipe:
> 
> PACKAGECONFIG ??= "udev ${@base_contains('DISTRO_FEATURES', 'opengl',
> 'glx', '', d)}"
> PACKAGECONFIG[udev] = "--enable-config-udev,--disable-config-udev,udev"
> PACKAGECONFIG[glx] = "--enable-dri --enable-dri2 --enable-glx --enable-glx-tls,\
>                       --disable-dri --disable-dri2 --disable-glx,\
>                       xf86driproto dri2proto mesa-dri"

Changing DISTRO_FEATURE in bsp layer is bad idea, proper error message
should be enough to notify distro maintainer that something is missing
in DISTRO_FEATURES/PACKAGECONFIG.

Cheers,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121123/62bbd72b/attachment-0002.sig>