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
=2D----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= ,=20 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.=20 Depending, of course, on the device in question. My little webcam, for=20 example, isn't on the list <)}: No big deal, although it was a gift, and th= e=20 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=20 "logical glue", writing the hardware side is much easier, which should resu= lt=20 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=20 exactly what I am saying! Rather than one monolithic driver that supports= =20 all of the functions of the device (as is necessary with most device=20 drivers), all you need to do is interface to a basic framework, much like t= he=20 newpcm drivers, rather than implementing specific individual drivers,=20 implemented a kernel framework providing certain basic functions, prototype= s=20 if you will, which the hardware side interfaces to, and then on the other=20 side, provide the "normal" devices like /dev/dsp that programs using sound= =20 expect to see. This frees the developer from having to worry about which=20 device files to support, and so on. If I understand correctly, what you are suggesting goes another level beyon= d=20 even that, but certainly it is worth looking at. How much of it will=20 actually prove useful, translationg from Audio to Video device support, is= =20 certainly beyond me, and perhaps you are to the point in your project where= =20 you are beyond needing that level of idea--clearly this is something that y= ou=20 have been working on, at least itellectually, for some time--but an=20 understanding of how newpcm works as a bit of logical glue between the=20 hardware and the kernel, might prove instructive, as well as looking at wha= t=20 went into newpcm from the kernel side.=20 > 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= =20 current driver interface (at the very least, you will have to design=20 something to make the library calls), and this puts it very much in the rea= lm=20 of what newpcm does on the audio side. newpcm, itself, doesn't really care= =20 if you are talking via PCI or USB, or if your device supports 44khz or 48kh= z=20 sampling. "All" (OK, so it's more work than I can do) your driver has to d= o=20 is figure out a way to bridge the gap between the hardware and newpcm, rath= er=20 than having to figure out how to tell applications whether or not it suppor= ts=20 full duplex. While this may not be exactly what you had in mind, I think y= ou=20 have to have it, in order to get the driver support that you seem to expect= =2E =20 In other words, if you expect the people writing device drivers to throw in= =20 the necessary calls to talk to your framework, you probably need to provide= =20 some benefit to the author. Of course, you aren't going to write device=20 drivers for everything under the sun, I don't think anyone is seriously=20 asking that. But by providing a common framework, you not only make your j= ob=20 easier at the receiving end, you encourage others to sit down and write=20 drivers for their devices, which increases the overall device support of=20 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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/FPzOY30jZzkECLcRAtdnAJ0dy/V7VhmEHZKY9xIJKuIMT/a3OACgkt41 z9TimfeJQI+7v3K6cM1gcIE=3D =3DICnv =2D----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307160120.48765.mupi>