[Xorg-driver-geode] FreeBSD patch for xf86-video-geode 2.11.12

[Martin-Éric Racine]

2011/11/13 Mart Raudsepp <leio at gentoo.org>:
> I don't have any particular idea about the FreeBSD side of things (does
> BSD really not have separate 64bit largefile offset handling routines?).

Apparently not. 64-bit variants of everything seem to be defined via
sys/types.h, but neither lseek or off_t seem to have any defined.

> But seeing as all this patch really does, is disable z4l code if host is
> bsd, then we could very easily go one step further and provide a
> AC_ARG_ENABLE or AC_ARG_WITH (whichever is more appropriate here) option
> for everyone, whereas bsd can just hide it completely and always disable
> with some simple configure.ac foo. Not many hardware actually has it, so
> some people may want to disable it. All it seems to really mean though
> is just the .so driver for z4l stuff doesn't get built and embedded
> systems can already just choose to not provide it in the production
> image.

Gaetan suggested that an OS-neutral approach could simply be to:

    AC_CHECK_HEADERS([linux/videodev2.h],[videodev2=yes])
    AM_CONDITIONAL(BUILD_ZTV, [test "x$videodev2" = xyes])

... which would define the following in config.h:

    #define HAVE_LINUX_VIDEODEV2_H

At least some BSD variants used to provide "linux/videodev.h" to bind
into their own video API, but I haven't found any who provides
something V4L2-compatible yet. However, the above would at least stop
making assumptions about what any given OS provides; just as long as
the binding exists, we can build and leave it up to each OS to decide
on how to implement their version of V4L2 support.

> Of course this also reminds me of the year old question - what does z4l
> actually do, why do we need that code and what actual hardware can make
> use of it.

IIRC, it makes use of the video capture feature that the Geode LX
offers on some hardware platforms and presents it as a V4L2 device
that can be fed to e.g. Gstreamer.

Martin-Éric