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

[Matthias Drochner <M.Drochner%fz-juelich.de@localhost>]

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
-------------------------------------------------------------------
-------------------------------------------------------------------