On 9/14/07, Alan Cox <alan@xxxxxxxxxx> wrote: > On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote: > > what stops vendors of using the current existing code to achieve that > > goal. They could provide binary drivers with the existing API. > > If you feel lucky about the GPL > > > What stops companies to intercept the ioctl calls and overriding some > > I2C commands? > > The GPL - derivative work is the boundary not code linkage. Possibly a > userspace > tuner hack would probably fit this too. Especially if a specific vendor is > producing both bits together and trying to claim they are independant. > > > How about proprietary video formats, would you also place the decoding > > algorithms in kernel just to force companies to release their code > > for it? > > No, I would assume they'd provide a proprietary conversion library that > no nobody would use (just like their hw). We keep format conversion firmly > seperated from hardware I/O processing. > In general there are known formats available, the drawback is that every TV application deals with it in a non-unified way at the moment, meaning alot code duplication in userspace since there's no library available at the moment which does the videoconversion from one to another format. Such a library is beeing developed at the moment which gets plugged infront of accessing the devicenodes. Although in the long run I'm looking forward to reuse the userspace tuners with such a library infront of everything by using i2c-dev. This would also make it easy to reuse the sample code of several companies, without having to cut out several features of the drivers and to rewrite them to an inkernel format. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
