Date: Wed, 16 Jul 2003 00:44:39 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Mike Porter <mupi@mknet.org> Cc: multimedia@freebsd.org Subject: Re: Looking at darwin? (was: Re: BSD video capture emulation question) Message-ID: <20030716074439.GV35337@funkthat.com> In-Reply-To: <200307160120.48765.mupi@mknet.org> References: <20030714064137.GT35337@funkthat.com> <200307151502.14625.mupi@mknet.org> <20030715215454.GL35337@funkthat.com> <200307160120.48765.mupi@mknet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Porter wrote this message on Wed, Jul 16, 2003 at 01:20 -0600: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 15 July 2003 03:54 pm, John-Mark Gurney wrote: > 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. Good, that's exactly what I'm targetting. :) With a well documented video interface, I could of made a much more functional Zoran driver sooner.. :) [...] > 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. Well, I would but newpcm is quite different from video. With audio you have either an input or an output... but video is quite a bit more complex.. If you want to understand it a bit better, I would recommend reading the specs for the Zoran chip... http://www.zoran.com/products/pcvideo/zr36067.asp > > 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 The one thing that FreeBSD misses is a good pseudo interface, which is part of the problem, but the newbus code is on a different side of things.. It's kinda like netgraph and blue tooth, or usb audio and pcm.. you still need the hardware interface (usb or blue tooth), and the logical, netgraph or pcm... I don't see how our device code will need to change.. [...] > 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. I think we are on the same page, :) spend a few months thinking about it.. I started thinking about this back in March.. of course I'm still open to ideas, but that's more on how the API on both sides will finally look.. Thanks for the help though. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030716074439.GV35337>