Re: Video4Linux header files

On Sat, May 19, 2007 at 05:30:06PM +0200, Hans Petter Selasky wrote:
> Hi,
> 
> The Video4Linux header files are dual BSD/GNU licensed! How nice! I want to 
> put these into the kernel source tree. For example under /usr/src/sys/sys .
> 
> The reason is that I want to implement a slightly modified version of the V4L 
> so that I can have a well known Linux USB Webcam driver working on my FreeBSD 
> using my new USB stack.
> 
> Does anyone here have any comments on this ?

the short answer is that in the short term you better rely on a port
e.g. v4lcompat

The long answer is this:
There was a long discussion back in january about importing the
headers, and in the end the discussion somewhat stalled due to far
too many intertwined issues and the existence of a partial workaround
in ports/v4lcompat.

As i recall/see it the problems were the following:
- licensing (at the time it was unclear; now this is solved);
- many v4l*-related programs are broken in various ways, typically
  assuming that the existence of the v4l2 headers guarantees that the
  OS supports the v4l2 api, so the program doesn't even try to check/use
  v4l1 or something else at runtime.
  At the moment, several of these ports get away with the problem by
  ignoring it or removing v4l* support. Adding the headers in the base
  system (which by itself is a desirable goal) requires working with
  the maintainers to fix the build on the various os versions
  (being ports not versioned, this could be slightly tricky).
- having v4l2 support makes no good to anyone now, since there is
  no v4l2 driver available, and many linux v4l2 drivers use USB2-isochronous
  transfers which are not supported on the current usb stack;
- i don't know how problematic is this, but v4l2 headers seem to use
  unnamed unions which, last time i tried, conflict with the compiler
  setting used to build the kernel. While this is possibly an orthogonal
  problem which we may have to address at some point (as unnamed unions
  seem to be a common paradigm in linux headers), it is yet another hurdle.

I suppose a suitable plan would be the following, but i have not had
the time to work on it:

1. add a v4lcompat build-dependency on the ports potentially affected,
   making sure they still build correctly using v4l1
2. add v4l1 headers in the base system (possibly changing the v4lcompat
   port to not install the headers if they are already in the base system);
3. modify the vl4compat port to add the v4l2 headers, again fixing
   any breakage in the builds
4. as in step 2, add the v4l2 headers to the system, changing v4lcompat
   as needed where the v4l* headers are in the base OS
   

cheers
luigi