Digital-tv card drivers and API discussion

[Jari Kirma]

> I am about to write a digital tv-driver for my dvb-c -card. Because
> FreeBSD does not yet have any dvb-devices and I don't have any prior
> driver development experience, I have a couple of questions for you.
>
> 1) Should we use Linux-DVB API as a reference,  or should we consider
> some changes to it? The API seems to be constantly changing and
> improving. Version 3 is available here:
> http://www.linuxtv.org/download/dvb/linux-dvb-api-1.0.0.pdf
> but they are currently working on version 4. In my opinion, the API
> should be minimal, but complete, so there is no need to constantly add
> new features to it.
>
> 2) As linux kernel is GPL-licensed, I cannot just port the linux driver
> to FreeBSD, right? In other words, we have to write the driver from
> scratch. In this case we don't have to stick with the Linux DVB-API and
> therefore I suggest that we give think the api through before
> deciding how we implement it (do we follow linux api or not).
>
> 3) Do you have any pointers to good books or other documentation on how
> to write device drivers for UNIX (BSD)? I already have read those from
> FreeBSD documentation, but a decent book would be handy.

I received my TechnoTrend USB DVB-C box couple weeks ago and pondered the
same issues. I got same suggestions in freebsd-multimedia (like,
compability with Linux is nice). I was also suggested to take a look at
early work at VideoBSD <http://people.freebsd.org/~jmg/videobsd.html>. I
haven't made any decisions on the interface yet, but I have had some
thoughts.

The biggest problem with Linux DVB API is that its interface is at
device/ioctl level. I consider that a poison for reasonable OS
independence. There's also libdvb <http://freshmeat.net/projects/libdvb/>
which supposedly abstracts away some OS-specific parts, but based on a
very quick glance, it might not cover whole set of operations required to
operate DVB sensibly.

In my case, I've been able to prototype my "driver" completely in
userspace as it is a USB device. I use ugen device bulk pipe for device
control, ugen isochronous pipe provides stream transport. I have had some
problems because ugen isn't really tried and tested on (relatively)
high-bandwith isochronous transfers, but most of those have been solved.
I'm able to watch DVB programs converted from MPEG TS substreams to MPEG
PS stream and piped to mplayer, completely in userland. Of course, this
isn't really doable with devices in PCI bus, but in USB or Firewire, it
should be pretty easy. It can also nicely separate the parts that may be
"poisoned" by GPL outside the kernel.

Even with this design, it would be possible to design "fake" devices
emulating Linux DVB interface and actually redirect the operations to
userland daemon. Extra copying of the MPEG TS stream can be avoided (I'm
planning to write a mmapped, properly synchronised, zero-copy usb
isochronous device driver), and testing is reasonably easy. Biggest
problem with this approach is obviously that you have to choose either
long latency or extra context switches...

Please note that I have not given thought on MPEG decoding, because my
device exports only MPEG stream. MPEG decoders should be handled in some
intelligent, modular way, because those two parts may well be operated
separately although they may be bundled on the same card.

-kirma