From owner-freebsd-current@FreeBSD.ORG Sat May 19 19:35:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1311D16A46B for ; Sat, 19 May 2007 19:35:40 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id DA68E13C4CA for ; Sat, 19 May 2007 19:35:39 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l4JJEIhs038177; Sat, 19 May 2007 12:14:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l4JJEIAF038176; Sat, 19 May 2007 12:14:18 -0700 (PDT) (envelope-from rizzo) Date: Sat, 19 May 2007 12:14:17 -0700 From: Luigi Rizzo To: Hans Petter Selasky Message-ID: <20070519121417.A37468@xorpc.icir.org> References: <200705191730.06964.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200705191730.06964.hselasky@c2i.net>; from hselasky@c2i.net on Sat, May 19, 2007 at 05:30:06PM +0200 Cc: freebsd-current@freebsd.org Subject: Re: Video4Linux header files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2007 19:35:40 -0000 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