Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934223AbXINQS3 (ORCPT ); Fri, 14 Sep 2007 12:18:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756083AbXINQSE (ORCPT ); Fri, 14 Sep 2007 12:18:04 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]:58633 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756428AbXINQSB (ORCPT ); Fri, 14 Sep 2007 12:18:01 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lE189KlfyVNUfa/0UP8EJGtmvLk2sn+mfpvfSv9H5k4qqSECfSoWIBaJCI3ucBrGXMqcUwyrkyL7YPDfe6duqIeHjcK11Aq+aSK5ma177lvD79haumjCZmslQ2rNx/G5vnfNmRd30lv7E4IS4xqVW6P3yluZtikUGWiin0sU8Vc= Message-ID: Date: Fri, 14 Sep 2007 18:18:00 +0200 From: "Markus Rechberger" To: "Alan Cox" Subject: Re: [linux-dvb] [PATCH] Userspace tuner Cc: "Steven Toth" , "akpm@linux-foundation.org" , "video4linux-list@redhat.com" , "linux-dvb@linuxtv.org" , "linux-kernel@vger.kernel.org" In-Reply-To: <20070914135237.GB19311@devserv.devel.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46C1BCC5.9090709@amd.com> <20070913131353.GB26972@linuxtv.org> <46E95C54.4060502@gmail.com> <46E99F36.8090809@hauppauge.com> <20070914135237.GB19311@devserv.devel.redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1942 Lines: 43 On 9/14/07, Alan Cox 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 - 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/