On 28 Feb 2003, Ronald Bultje wrote: > Hey John, > > On Fri, 2003-02-28 at 00:16, PlasmaJohn wrote: > > Yipe! What's the point of the API frameworks if nobody wants to use them? > > They'll have to anyway. Who would accept this into the standard kernel > if it wasn't v4l2/v4l1'ified? Interesting question. At the moment, we compile fine outside the kernel. Although inclusion is a goal, if it never happens, well I suppose I won't lose too much sleep ;) Don't get me wrong. I'm a big believer of standard interfaces. Look at i2c: every Windows driver for a card with i2c devices pretty much has to write support for every chip from scratch. OTOH, under Linux we get to borrow code from many projects and share our improvements. Everybody gains. When deciding which version of V4L to use, it quickly became apparent that we'd need V4L2 because we just don't fit under V4L1. An aside: We're at the point where we need to do things like change inputs and channels. To that end, we've started coding up some ioctl support using the V4L/V4L2 ioctls. This is low-hanging fruit. Real integration will require a bit more effort, so that's deferred until the driver stabilizes a bit more. Is there a CONFIG_ directive for V4L2 so that we don't require people to patch their kernel until absolutely necessary? > You can extend v4l2 (with an extra struct or so for MPEG specific things), On the TODO/wishlist. If I can come up with something, I'll send a design doc to the list. If anything, it'll take advantage of the work Gert Vervoort did about a month ago: http://marc.theaimsgroup.com/?l=linux-video&m=104465485308649&w=2 > but you'll want v4l2 after all if the thing can show video input, even if it > was just so that the Xv/v4l module and/or xawtv would work with it. Well, the current driver only emits an MPEG[2] stream. I think I know how to get a non-compressed stream out of it, but that's not my current focus. Not sure what use that would be to Xv or XawTV as I don't think either handle compressed streams. John
