Date: Wed, 16 Jul 2003 01:20:41 -0600 From: Mike Porter <mupi@mknet.org> To: John-Mark Gurney <gurney_j@efn.org> Cc: multimedia@freebsd.org Subject: Re: Looking at darwin? (was: Re: BSD video capture emulation question) Message-ID: <200307160120.48765.mupi@mknet.org> In-Reply-To: <20030715215454.GL35337@funkthat.com> References: <20030714064137.GT35337@funkthat.com> <200307151502.14625.mupi@mknet.org> <20030715215454.GL35337@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307160120.48765.mupi>