Date: Tue, 15 Jul 2003 15:02:09 -0600 From: Mike Porter <mupi@mknet.org> To: multimedia@freebsd.org Subject: Re: Looking at darwin? (was: Re: BSD video capture emulation question) Message-ID: <200307151502.14625.mupi@mknet.org> In-Reply-To: <20030715090724.GH35337@funkthat.com> References: <20030714064137.GT35337@funkthat.com> <20030715075307.GD17691@cobweb.example.org> <20030715090724.GH35337@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:07 am, John-Mark Gurney wrote: > Marco Molteni wrote this message on Tue, Jul 15, 2003 at 09:53 +0200: > > I appreciate your effort to provide a "video4bsd" facility. > > > > Since Apple is famous for being one of the OS of choice for multimedia > > professional work, and Darwin is so closely related to FreeBSD, may I > > suggest to check if Darwin already has some of the > > APIs/services/subsystems/whatever that might be ported to FreeBSD? > > > > I don't follow Darwin so I cannot say for sure, but I think we should > > try to avoid, if possible, the Not Invented Here syndrome ;-) > > Last I heard, there was an issue of licenses between Darwin and FreeBSD. > I have sent mail to -core asking about it. > > That said, we might want to leverage their userland API for it, but > I don't think we could use any of their hardware API. They have a very > different hardware framework. One that would make adding shims a bit > too complex. > > So, are you going to do the research and work on this? You didn't > even post any links to code, so all the video API may be apart of > Mac OSX and not Darwin. This means that we can't get the code. So, > if you really thing we should do this route, send your research to > the list. After some casual perusal of the Darwin website, it appears that=20 1) IO/Kit (the device driver interface) is part of Darwin, not part of the= =20 "proprietary" part of OS/X 2) If we really wanted to, we could probably therefore use it, but a) we wo= uld=20 have to including the original Apple licensing stuff (not a big deal, most = of=20 the stuff already includes a BSD disclaimer), and b) (more significantly, i= n=20 my book) anything we do, we have to give back to Apple for them to possibly= =20 use and make money from. However, it seems that it is not (just) a framework for video drivers, whic= h=20 is what we are looking at specifically. Using it in that context would=20 involve rewriting more or less that entire IO subsytem, something I don't=20 think we are (or should be) willing to tackle. I can see bringing some Aud= io=20 capabilities along for the ride in the new framework, just becuase most vid= eo=20 also has an audio component, so it makes sense to be able to streamline=20 audio+video, which could possibly help maintain sync, but I don't see=20 throwing out all the other IO pieces, or having to rewrite them (although=20 some might argue that this could give us better devoce support overall, and= =20 its possible, but it doesn't seem worth it to me). Also, using this=20 framework would bring yet another licensing arrangement to bear, and while,= =20 as far as this non-lawyer can tell, the Apple license is less restrictive=20 than, say, the GPL, it is still more restrictive than the BSD licesne we ar= e=20 trying to keep all the kernel under, and as much as possible of the thest o= f=20 the base system. Trying to figure out which bits are covered by which=20 license is bad enough when there are only 2 licenses involved. What IO/Kit DOES have that we want, is a way to interface from userland and= =20 control the device driver: "The I/O Kit is the device driver subsystem of M= ac=20 OS X, and is part of Darwin. The I/O Kit provides a set of C functions and= =20 C++ classes, including object-oriented abstractions common to various=20 families of drivers. In addition, for many device types, the I/O Kit provid= es=20 a device interface that enables an application to communicate with and=20 control a device from user space." (from=20 http://developer.apple.com/documentation/DeviceDrivers/DeviceDrivers.html ) This description does sound pretty much like what I've seen discussed here,= =20 except that the discussion here has focussed specifically on Video drivers,= =20 not "all" IO devices (and note that not necessarily all devices have (or=20 need) userland access) My gut feeling, based on all of this is that while we could probably benefi= t=20 from some of the work already done, I don't think the headaches it would=20 entail would be worth moving the entire structure over. I don't think the= =20 licensing issue is one we want to tackle either, especially without approva= l=20 from -core. (Although looking about some of the things apple is saying abou= t=20 themselves and how they work to get their changes implemented upstream=20 (specifically citing Apache (anyone know the details on this?)) perhpas the= y=20 would push such a change "upstream" (or perhaps they already tried and were= =20 rejected?) What may be worth it (and there may be some legal ramifications here=20 surrounding "derivative works") is looking to see how they do it, spcifical= ly=20 for video devices, and then see what it would take to provide something=20 similar--but that is, if I understand it, exactly what we are discussing he= re=20 anyway. It occurs to me that better model to follow (if I correctly understood the= =20 goals) would be to look at the newpcm stuff, which provides a common=20 interface for sound cards, rather than a unique all-encompassing device=20 driver that provides the entire device's necessary support.=20 Well, that's my 2CW, I better stop before I make a bigger fool of myself.... mike =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/FGvVY30jZzkECLcRAveeAKCgg9H6b6s0VibUo5ZRUk/BK9balwCfYjG6 KHALei+iomYb4TeiVgZtJLI=3D =3DZtR2 =2D----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307151502.14625.mupi>