Introduction | Drivers (DVB/ATSC hardware) | iTele (viewer app) | Mpegitor | Forums

MultiMedia Input device drivers for Mac

In order to use Mac Digital TV / HDTV applications such as iTele, you need a driver that is a member of the MMInput family of device drivers. This family has been created to support multimedia input devices such as Digital TV cards. It is called the 'MultiMedia Input Family' because its use is not restricted to Digital TV applications alone: DVB and its cousins like ATSC promise all sorts of other media goodies, such as interactive TV shows (vote with your remote), IP over the air (internet downloads), data channels (weather/stockmarket), near video on demand (movie starts every half hour), and many others. Hopefully the MMInputFamily will eventually be adopted by writers of commercial drivers or Apple, but we could be waiting a while for that.

Therefore, support for multimedia input devices is provided by the MMInputFamily kernel extension, which is contained in this package:

Download the MultiMedia Input Family and Drivers v0.8.5 package
(compatible with Mac OS X 10.2 (Panther) through Mac OS X 10.4 (Tiger))

An important element of the package is the Userspace Driver Market daemon, allowing new drivers to be written in userspace, and allowing existing kernel drivers to be published over the local network.

Note: Please read the instructions displayed when you run the installer, do not just click through them! You may need to download some additional firmware.

Supported Devices

Included in the package are drivers for many DVB and ATSC devices. They are constructed from the PrincipalMMInputs and TypicalDVBFrontends kernel extensions. Below is a list of most of the devices that can be driven; OEM versions of these devices will also work: The following included drivers are in various stages of development:
The package also includes another kernel extension called PhilipsSAA7146, which is required by cards that include the chip of that name. I have separated it out because my driver could be reused for other (non-DVB) cards that also use this chip. The same thing goes for the ConexantCX2388X extension, which has drivers for both the ConexantCX2388X and the Conexant Fusion 878 / Brooktree BT8X8.

How It Came To Pass

The TechnoTrend PCI driver was created with the DPandA DVB-T card, which was the first DVB-T card available in Australia - I bought it and put it in my Mac, and a couple of weekends later I actually got it to work :). The USB driver was created over ssh with a Hauppauge Nova-t USB - thanks to David Paterson for letting me crash his Mac - only twice 'tho! :). The satellite USB box driver was made possible thanks to the combination of a loan of a DVB-S box from a Eutelsat, and the patience of my good friend Phill who let me plug it into his dish. The satellite PCI card driver was able to be developed at great speed thanks to the generosity of Apple Australia. The DVICO FusionHDTV DVB-T driver was sponsored by Mark Hosking with hardware and Chris Pascoe with his linux driver. The DVICO FusionHDTV 3 ATSC driver was facilitated by DVICO themselves with some technical info, and the brave tester Kevin bought one for his Mac in Korea.

I should note here that CI slots for decoding encrypted signals on TechnoTrend DVB-S cards are not currently supported - that means that you will only be able to watch the free-to-air satellite broadcasts with those devices. This is not an issue for the USB boxes since that is all they can do anyway, but you can get PCI cards with these extra slots. The existing drivers will probably work with such a card but the CI slot will not be enabled. Also the analogue input on the DVICO FusionHDTV cards is also not currrently supported.

Not-yet-supported Devices

The cards and boxes listed above are currently the only supported ones. There has to be a good reason for me to add support for a new device. But that shouldn't stop anyone else from writing a driver...

If there are any keen driver developers out there, then please download the CVS repository linked to from the main page and get to it. Don't hesitate to email me if you have any problems or questions - in fact it'd be great if you'd let me know what you were attempting in case someone else is already doing it. Note that the license for this code is a BSD-like 'do what you want with it' licence, as described on the main page. Of course the license for any drivers you develop using MMInputFamily can be whatever you want it to be.

Now that the FusionHDTV 3 ATSC driver has been properly tested and confirmed to work, I have completed the list of drivers that I personally wanted to write. If you have another device that you would like to see supported, and you're not willing or able to write a driver for it yourself, then by all means please make your case - if you make it easy for me then I could well be inclined to help out :) My intention now is to turn more of my efforts towards adding features to the userspace software side of things, as well as cleaning up a few loose ends in the existing drivers like remote control support, sleeping while recording, analogue inputs, etc.

MMInputFamily driver contents

This section contains information that may interest other driver developers (hello? anyone out there? ;-). I have also written a more extensive driver architecture walkthrough that people writing their own MMInputFamily drivers should read. It is still a work in progress but it has more details than the introductory sections below.


This is an IOService object that your driver object should derive from. It's got a dozen virtual methods that you have to implement. It's all copiously documented in the header file (which is actually shared with userspace), so just read that and you'll be away. Being at version 0.5 it's likely to change a little, but it'll probably only be a rearranging of enums - I've already rewritten it about half a dozen times before the first release.

With MMInput you get the MMInputClient (an IOKit User Client object) for free, so your driver will work with iTele and any other application that uses MMInputLib (the userspace device interface library).

Generic I²C interfaces

I have found two Apple I²C interfaces: one is very specific and seems to be for power management and other motherboard stuff, and the other is more general but it is hidden in the IOGraphics subdirectory of open source Darwin (i.e. not in the headers you get with the Developer package, and certainly not documented) and I only discovered it well after I got everything working with my own classes. It uses the good-old nasty parameter block approach too, so I'm not going to move to it unless someone can give me a good reason.

So if you have an I²C subsystem on your card, then you might consider using I2CNub from MMInputFamily. I2CNub is an IOService object that accepts simple (and complex) commands and uses an I2CPipe to communicate with its devices. It uses standard IOKit driver matching and the IOI2CAddressMatch property to find a client. All you have to do is implement a couple of simple virtual methods in I2CPipe and all your present and future I²C worries are taken care of. See the header file for doxygen-style documentation.

I2CNub.hpp also has some funky macros which allow you to talk to your I²C chip as if it were a memory-mapped structure from C++, e.g. myChip.flagRegister &= ~0x06. See the TechnoTrendDVB drivers for examples. Related to this is another header file 'FTypes.hpp' containing the classes LEUInt32 and LEUInt16, which let you deal with little endian integers from C++ just like you do with their big endian cousins. It's pretty efficient under gcc too (and not too bad under CodeWarrior).


This is a utility class that allows IOKit drivers to read resource files from the Resources directory of their bundle. Try as I might I couldn't find an Apple-sanctioned way of doing this - or of reading any file in the kernel. In fact it was hard enough to find any examples of this kind of thing at all. In bsd terms this class wraps up the ugly xnu vnode stuff. And funnels <shudder> ... if you don't know what these are then believe me you don't want to :). I think that quite a few people might find this class handy.


This is a class that frontend drivers for DVB device chips (e.g. I2CNub clients) might want to derive from. It contains virtual methods for doing frontend stuff like tuning to a given set of parameters. The idea is that MMInput drivers can look through their (say) I²C clients, and do a typesafe downcast (using Apple's OSMetaType stuff) to DVBFrontend, and then call generic methods on them, without caring what the specific frontend driver actually is. This is used by TechnoTrendDVB, but it's not particularly precious to me and certainly you don't have to use it in your drivers - but it might be useful if your device is set up like this.

Change Log

New in v0.8.5 New in v0.8.4 New in v0.8.3 New in v0.8.2 New in v0.8.1 New in v0.8.0 (Userspace Driver Market) New in v0.7.3T (Tiger time final) New in v0.7.3Tb2 (Tiger time 2) New in v0.7.3Tb1 (Tiger time) New in v0.7.2 (Latest Ultraview tweak) New in v0.7.1 (USB2 for Australia: MagicBox II, tinyUSB2, FusionHDTV USB 'Bluebird') New in v0.7.0 (DEC 2000-T, TerraTec Cinergy T2, FusionHDTV DVB-S, TechniSat SkyStar2, TwinHan DTV Ter, and general consolidation) New in v0.6.9 (FusionHDTV DVB-T Lite+BT8X8, old Nova-T USB, FusionHDTV Gold-T, betas galore) New in v0.6.8 (New Hauppauge drivers) New in v0.6.7 (Tested DVICO FusionHDTV 3 ATSC driver :) New in v0.6.6 (DVICO FusionHDTV 3 ATSC driver) New in v0.6.5b1 (DVICO FusionHDTV DVB-T driver) New in v0.6.4 (DVB-S over PCI driver) New in v0.6.3 (DVB-S over USB driver) New in v0.6.0 (USB driver) New in v0.5.2 (fixes for G5s): New in v0.5.1 (fixes for panic under Panther): New in v0.5: Original v0.1:
Back to DVB page

Last updated 15/6/2006 by John Dalgliesh