Re: GSoC - USB Video Class (UVC) webcam driver

[Hans Petter Selasky <hselasky%c2i.net@localhost>]

Hi,

Regarding video for linux, I have done some work in this area on FreeBSD:

http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/usb/src/sys/sys/videodev.h
http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/usb/src/sys/sys/videokern.h

--HPS

On Wednesday 07 May 2008, Matthias Drochner wrote:
> pat%polycrystal.org@localhost said:
> > Hi, I'm Patrick Mahoney and my Summer of Code project has been
> > accepted.
>
> Congrats...
>
> > After plugging in the device, a USB interface of class 0xE
> > indicates a UVC device (there should typically be at least
> > two such interfaces: one is the Control interface and the
> > other the Streaming interface).
>
> The clean and modern way to identify the interfaces belonging
> to a UVC device is the "IAD" (Interface Association Descriptor).
> I've posted some patches which implement this a while ago.
> Unfortunately I've found that the approach I've chosen (to
> use an intermediate device node for multi-interface devices)
> makes it hard to implement parts of the "ugen" semantics
> without evil hacks. (And it requires ~all kernel config files
> to be adapted.) So it seems I'll have to rearrange things;
> I hope I get it done before the 5.0 release cycle, but I can't
> promise.
>
> Anyway, it would be good if you put the code which identifies
> the interfaces to deal with somehow seperate, so that it
> can be easily changed. (uaudio is actually an example how
> it should _not_ be done.)
>
> > Jared suggested exporting a
> > NetBSD/UVC specific API while providing a compatibility
> > layer to translate the Video4Linux (or Video4Linux2) API as
> > is done with the OSS audio driver
>
> I'd still prefer a kernel interface which is not UVC specific, and
> preferrably even v4l2 source compatible. Some reasons:
> -If we want other kernel drivers to be accessed by v4l2 user
>  programs (eg some firewire camera support, or even bt848),
>  we'd have to add a new case to the userlevel translation
>  library. This library would have to use some heuristics to
>  find out the kernel API to use for some device it knows
>  only the path of. That's hard to maintain.
> -These translation libraries catch all ioctl() calls in
>  the program. Filtering is done by the "request" argument.
>  This means a runtime penalty for all ioctl() calls of
>  the program. And it depends on all ioctl requests to be
>  globally unique (instead of just per-filedescriptor). While
>  there were no appearent problems in the oss case so far, there
>  is nothing coordinating the ioctl request namespace, so
>  the risk of collisions inreases with every new driver.
> -If Opensolaris can implement a v4l2 compatible interface,
>  why can't we. Just assuming that v4l2 is somewhat mature,
>  and to avoid complexity.
>
> Of course I see that a generic interface for the driver means
> more work, and that this might not fit into the timeframe
> for a gsoc project. Imo your project could be called
> successful even without a final v4l2 compatibible API.
> Nice to have of course to get some client programs running,
> but I wouldn't make it "official".
>
> best regards
> Matthias
>
>
>
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
>
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
> Dr. Sebastian M. Schmidt
> -------------------------------------------------------------------
> -------------------------------------------------------------------