Messages in this thread | | | Date | Fri, 05 Feb 1999 23:20:32 +0100 | From | Edgar Toernig <> | Subject | Re: bttv.h: #define VBIBUF_SIZE 65536 |
| |
Hi,
Alan Cox wrote: > > Would you then include the following patch, please. > > Not as such. But as VIDIOCVBISIZE so its generic to all future VBI setups > maybe. The problem is there are other things that matter > > There ought to be a > > struct vbi_config > { > int size; > int format; > etc ... > }; > > and that wants defining with the whole API carefully and cleanly as a generic > VBI API
Oh come on. Of course, you could set up a vbi-api mailing list, a web page, and discuss (a couple of months) the form of a generic API for hardware that is not yet present and get an ugly duckling that breaks the moment that new hardware is present.
At the moment, it's an API of the bttv driver that handles what the hardware gives. Of course, you could blow it up (multiple clients registering for different vbi lines and mmap support, for example) but is it necessary at the moment?
To make it really generic, you would need a very complex API (sample rates, start offset, sampled bit depth, line selection, filter settings, ... with all the necessary functions to query possible values...) that IMO should not be in the kernel. If there's need for such an interface, it's still time to implement it.
If you really need such an API, put it in a shared library. The kernel should only supply what's necessary to access the hardware. (AFAIK, ALSA is going that (right) way...).
About the posted patch: I beg you, please put it in. At the moment, there's only one serious application that uses /dev/vbi (alevt) and this patch makes bttv compatible with older (future?) versions. It's really crazy to tell people, they should give the -oldbttv option when using the 2.2.1 version. The patch costs only a couple of bytes and doesn't hinder anybody to design a better API. (IMO, the missing BTTV_VERSION in vbi_ioctl could be even called a bug *g*, should be put into radio_ioctl, too).
Ciao, ET.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |