Date: Tue, 15 Jul 2003 14:54:54 -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: <20030715215454.GL35337@funkthat.com> In-Reply-To: <200307151502.14625.mupi@mknet.org> References: <20030714064137.GT35337@funkthat.com> <20030715075307.GD17691@cobweb.example.org> <20030715090724.GH35337@funkthat.com> <200307151502.14625.mupi@mknet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Porter wrote this message on Tue, Jul 15, 2003 at 15:02 -0600: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 15 July 2003 03:07 am, John-Mark Gurney wrote: > After some casual perusal of the Darwin website, it appears that > > 1) IO/Kit (the device driver interface) is part of Darwin, not part of the > "proprietary" part of OS/X i.e. newbus, nothing new. The IO/Kit documentation should mention that FreeBSD now supports the features, but when Apple borrowed from FreeBSD, FreeBSD didn't have the set of features it needed. > 2) If we really wanted to, we could probably therefore use it, but a) we would We could also use the Linux frame work, or NetBSD's frame work with just as much work, but again, this is completely off topic from what I am trying to do. > What IO/Kit DOES have that we want, is a way to interface from userland and > control the device driver: "The I/O Kit is the device driver subsystem of Mac > OS X, and is part of Darwin. The I/O Kit provides a set of C functions and > C++ classes, including object-oriented abstractions common to various > families of drivers. In addition, for many device types, the I/O Kit provides > a device interface that enables an application to communicate with and > control a device from user space." (from > http://developer.apple.com/documentation/DeviceDrivers/DeviceDrivers.html ) 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. > This description does sound pretty much like what I've seen discussed here, > except that the discussion here has focussed specifically on Video drivers, > not "all" IO devices (and note that not necessarily all devices have (or > need) userland access) 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. 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. > My gut feeling, based on all of this is that while we could probably benefit > from some of the work already done, I don't think the headaches it would > entail would be worth moving the entire structure over. I don't think the > licensing issue is one we want to tackle either, especially without approval > from -core. (Although looking about some of the things apple is saying about > themselves and how they work to get their changes implemented upstream > (specifically citing Apache (anyone know the details on this?)) perhpas they > would push such a change "upstream" (or perhaps they already tried and were > rejected?) As for the licensing issue, I have heard the Apple is willing to relicense parts as necessary. We can talk with jkh about this more in detail, but again, the IO/Kit brings nothing on the logical side for capture devices. The closes is the graphics class, but that is only for frame buffers, but nothing relating to video capture. > 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. 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. VideoBSD has no plans on recreating the hardware side of things. If you have a hammer, everything looks like a nail. -- 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?20030715215454.GL35337>