Love wrote:

>Klaus Heinz <k.heinz.maer.drei@onlinehome.de> writes:
>
>>Last november Love Hörnquist Åstrand reported he had the pwc driver in
>>a working state (with his PCVC730K). I think it's not available in
>>the CVS tree, yet.
>>
>>See http://mail-index.netbsd.org/tech-kern/2002/11/25/0000.html.
>>
>
>Its not in the tree since I've never finished the video for linux 2
>interface since I had hard time finding applications using it, I got other
>things to do and forgot the about the whole thing.
>
>Sure, it would be good to have it in the tree, but I would like to have a
>better access to the data then yet-another-cdev with private api.
>
>Have anyone any experience with the v4l/v4l2 interface, is it anything we
>want, will how v4l does dma/mmap work for us ?
>
>Love
>
Hi,

I found your code, tried to compile a kernel wich included it, but the 
compiler
refused... can't remember what reason, but I decided then that it would 
be more
effort to find and fix the problem than it would be to write a new 
driver from
scratch (given the ugen interface). How wrong I probably was...
I'll give it another try. Are you tracking current? any other hints?

I don't have any hands on experience with the v4l/v4l2 interface, but I 
would
definitely agree that having a comon interface to video devices would 
greatly
enhance their usability. Right now I've got a bktr878, a quad camera frame
grabber of my own design  and a couple of ancient ISA bus framegrabbers
(which I don't use any more) lying around, all with different api's, 
which is a
shame. My idea is that if more devices supporting a common interface are
available, more applications will become available that use this 
interface....

Wheter this interface is the v4l/v4l2 OR the matrox/meteor interface OR a
new v4BSD interface is a different question.

I've got a good idea what *I* would expect from a video device driver, and
(cursorily) reading the v4l2 specs it looks like a good step in the right
direction, though there are some things I would add (external software 
codecs,
transparent software replacements for missing hardware (i.e. software gamma
when no hardware gamma control is available)), or leave out (audio ..? ).

One thing speaking strongly in favor of implementing the v4l2 interface is
(imho) that it at least has a reasonable amount of documentation.

If and how dma/mmap works for NetBSD I don't know, but frankly I would
be pretty happy with classic read()-ability (for most USB camera's this
should be sufficient; it's "only" 1.2 Mbyte/second to transfer 320x240 
24 bit
RGB frames at 5 frames per second)

*After* I get my camera to work (@#*!) I'll have a thorough look at the v4l2
specs, and if and when time allows, will gladly discuss things and help 
imple-
ment a proper interface for it.

Theo