<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2"> </HEAD> <BODY> On Sun, 2011-11-13 at 16:09 +0200, Martin-Éric Racine wrote: <BLOCKQUOTE TYPE=CITE> <PRE> 2011/11/13 Mart Raudsepp <<A HREF="mailto:leio@gentoo.org">leio@gentoo.org</A>>: > 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 </PRE> </BLOCKQUOTE> I was going to propose that next. Even if it "can be built", it does not "have to be built". So --enable-z4l (or ztv if more descriptive) would be added on the command line for system builders who do wish to have this feature. Based on your comments, it looks like it would be disabled by default. And we should always guard against build break by detecting if kernel support is available. <BLOCKQUOTE TYPE=CITE> <PRE> > 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. </PRE> </BLOCKQUOTE> Unrelated here, just my opinion. Having done a bit of googling, it looks like there are more OS or linux flavors where Geode is used. I saw this board used in the industry as an embedded PC. I noticed Gentoo builds on Geode. More users is always good. That means writing more portable code and revisiting some assumptions. <BLOCKQUOTE TYPE=CITE> <PRE> Martin-Éric </PRE> </BLOCKQUOTE> </BODY> </HTML>