On 9/14/07, Alan Cox <alan@redhat.com> wrote:
quoted text
> 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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/