Looking at darwin? (was: Re: BSD video capture emulation
mupi at mknet.org
Wed Jul 16 00:21:16 PDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
-----END PGP SIGNATURE-----
More information about the freebsd-multimedia