Patchwork [0/4] Fixes for xserver and omap* drivers

The following changes since commit 4bbe7a5067452b43bf3258b17e2a653a2273b476:

  Revert "kern-tools: report missing config fragments by name" (2012-11-22 08:58:56 +0000)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib jansa/xorg
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/xorg

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

 .../xorg-driver/xf86-video-omap_git.bb             |  28 +-
 ...a-large-CRTC-upper-limit-to-not-prune-lar.patch |  41 +++
 ...virtual-size-when-configuring-framebuffer.patch |  32 ++
 .../xf86-video-omapfb/0003-force-plain-mode.patch  |  31 ++
 .../xf86-video-omapfb/0004-blacklist-tv-out.patch  |  33 +++
 .../0005-Attempt-to-fix-VRFB.patch                 | 325 +++++++++++++++++++++
 ...0006-omapfb-port-to-new-xserver-video-API.patch | 272 +++++++++++++++++
 .../xorg-driver/xf86-video-omapfb_git.bb           |  33 +++
 .../recipes-graphics/xorg-xserver/xserver-xorg.inc |   4 +-
 9 files changed, 788 insertions(+), 11 deletions(-)
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omapfb/0001-Revert-Set-a-large-CRTC-upper-limit-to-not-prune-lar.patch
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omapfb/0002-Revert-Set-virtual-size-when-configuring-framebuffer.patch
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omapfb/0003-force-plain-mode.patch
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omapfb/0004-blacklist-tv-out.patch
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omapfb/0005-Attempt-to-fix-VRFB.patch
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omapfb/0006-omapfb-port-to-new-xserver-video-API.patch
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb

hi,

On Fri, Nov 23, 2012 at 1:47 AM, Martin Jansa <martin.jansa@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.
 - 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..
 - 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"

thx

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@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,

On 23 November 2012 10:18, Nicolas Dechesne <ndec13@gmail.com> wrote:
> 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.

Add a new DISTRO_FEATURE for DRI?

Ross