Looking at darwin? (was: Re: BSD video capture emulation question)

[Mike Porter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 15 July 2003 03:54 pm, John-Mark Gurney wrote:
> Mike Porter wrote this message on Tue, Jul 15, 2003 at 15:02 -0600:
>
> Yes, it does, but it does on a seperate scale than FreeBSD.  Also, do you
> trust any code to twiddle the PCI bus?  yes, we are doing this with
> XFree86, but this is more of a topic for -arch, than this framework.
>
That's basically my point in saying we don't want to import the whole thing, 
not every device needs userland access, for example, the PCI bus <(}:

> Too many people are thinking physical instead of logical.  We already
> have the physical side of things, the driver talking to the hardware to
> control it. 

Depending, of course, on the device in question.  My little webcam, for 
example, isn't on the list <)}: No big deal, although it was a gift, and the 
person who got it for me expects me to use it....

 What we don't have is the logical glue to glue the parts of
> the driver together into one easy piece.  This is what the code I would
> like to see do.

I think what people (me at least) are latching on to it the idea that with the 
"logical glue", writing the hardware side is much easier, which should result 
in many more devices becoming supported.

>
> > It occurs to me that better model to follow (if I correctly understood
> > the goals) would be to look at the newpcm stuff, which provides a common
> > interface for sound cards, rather than a unique all-encompassing device
> > driver that provides the entire device's necessary support.
>
> Hmmm.. did you ever read my VideoBSD document?  I never mentioned an
> all in one device kit, just the logical glue.  You might of mistaken
> the idea of userland device drivers and providing it, but that is not
> what it was suppose to do.
>

You misunderstood my point (perhaps I didn't make it clearly enough).  This is 
exactly what I am saying!  Rather than one monolithic driver that supports 
all of the functions of the device (as is necessary with most device 
drivers), all you need to do is interface to a basic framework, much like the 
newpcm drivers, rather than implementing specific individual drivers, 
implemented a kernel framework providing certain basic functions, prototypes 
if you will, which the hardware side interfaces to, and then on the other 
side, provide the "normal" devices like /dev/dsp that programs using sound 
expect to see.  This frees the developer from having to worry about which 
device files to support, and so on.

If I understand correctly, what you are suggesting goes another level beyond 
even that, but certainly it is worth looking at.  How much of it will 
actually prove useful, translationg from Audio to Video device support, is 
certainly beyond me, and perhaps you are to the point in your project where 
you are beyond needing that level of idea--clearly this is something that you 
have been working on, at least itellectually, for some time--but an 
understanding of how newpcm works as a bit of logical glue between the 
hardware and the kernel, might prove instructive, as well as looking at what 
went into newpcm from the kernel side. 


> Say you have a webcam.  It will use the existing ugen interface to
> talk with the hardware, but then it will make various library calls to
> VideoBSD to say, hey! I provide a video capture device, tell me where
> you want me to put the data in which format.
>
It seems to me that as a logical consequence, you will have to redesign the 
current driver interface (at the very least, you will have to design 
something to make the library calls), and this puts it very much in the realm 
of what newpcm does on the audio side.  newpcm, itself, doesn't really care 
if you are talking via PCI or USB, or if your device supports 44khz or 48khz 
sampling.  "All" (OK, so it's more work than I can do) your driver has to do 
is figure out a way to bridge the gap between the hardware and newpcm, rather 
than having to figure out how to tell applications whether or not it supports 
full duplex.  While this may not be exactly what you had in mind, I think you 
have to have it, in order to get the driver support that you seem to expect.  
In other words, if you expect the people writing device drivers to throw in 
the necessary calls to talk to your framework, you probably need to provide 
some benefit to the author.   Of course, you aren't going to write device 
drivers for everything under the sun, I don't think anyone is seriously 
asking that.  But by providing a common framework, you not only make your job 
easier at the receiving end, you encourage others to sit down and write 
drivers for their devices, which increases the overall device support of 
freebsd.

> VideoBSD has no plans on recreating the hardware side of things.  If you
> have a hammer, everything looks like a nail.

OK, I'll go sit back down in the quiet corner again.

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/FPzOY30jZzkECLcRAtdnAJ0dy/V7VhmEHZKY9xIJKuIMT/a3OACgkt41
z9TimfeJQI+7v3K6cM1gcIE=
=ICnv
-----END PGP SIGNATURE-----