Date: Thu, 15 Apr 2004 10:11:59 +0300 (EEST) From: Jari Kirma <kirma@cs.hut.fi> To: freebsd-arch@freebsd.org Subject: Digital-tv card drivers and API discussion Message-ID: <Pine.GSO.4.58.0404150910320.24624@hutcs.cs.hut.fi>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.58.0404150910320.24624>