Message-ID: <20091208170640.GB14143@core.coreip.homeip.net>
Date:	Tue, 8 Dec 2009 09:06:40 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Andy Walls <awalls@...ix.net>, Jarod Wilson <jarod@...sonet.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <lirc@...telmus.de>, j@...nau.net,
	jarod@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was:
	Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Tue, Dec 08, 2009 at 09:44:29AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> >> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> >>> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> >>>
> >>>> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> >>>>> Krzysztof Halasa wrote:
> >>>>>> Andy Walls <awalls@...ix.net> writes:
> >>>>>>
> >>>>>>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> >>>>>>> developed by Philips, but Microsoft has some sort of licensing interest
> >>>>>>> in it and it is almost surely encumbered somwhow:
> >>>>>> I don't know about legal problems in some countries but from the
> >>>>>> technical POV handling the protocol in the kernel is more efficient
> >>>>>> or (/and) simpler.
> >>>>> A software licensing from Microsoft won't apply to Linux kernel, so I'm
> >>>>> assuming that you're referring to some patent that they could be filled
> >>>>> about RC6 mode 6A.
> >>>>>
> >>>>> I don't know if is there any US patent pending about it (AFAIK, only US
> >>>>> accepts software patents), but there are some prior-art for IR key
> >>>>> decoding. So, I don't see what "innovation" RC6 would be adding. 
> >>>>> If it is some new way to transmit waves, the patent issues
> >>>>> aren't related to software, and the device manufacturer had already handled
> >>>>> it when they made their devices.
> >>>>>
> >>>>> If it is just a new keytable, this issue 
> >>>>> could be easily solved by loading the keytable via userspace.
> >>>>>
> >>>>> Also, assuming that you can use the driver only with a hardware that comes
> >>>>> with a licensed software, the user has already the license for using it.
> >>>>>
> >>>>> Do you have any details on what patents they are claiming?
> >>>> The US Philips RC-6 patent is US Patent 5,877,702
> >>>>
> >>>> http://www.google.com/patents?vid=USPAT5877702
> >>>>
> >>>> Click on download PDF to get a copy of the whole patent.
> >>>>
> >>>> I am not a lawyer.  Philips claims' all appear to tie to a transmitter
> >>>> or receiver as part of a system, but most of the claims are about
> >>>> information and bit positions and lengths.
> >>> ...
> >>>> IMO, given
> >>>>
> >>>> a. the dearth of public information about RC-6, indicating someone
> >>>> thinks it's their trade secret or intellectual property
> >>>>
> >>>> b. Microsoft claiming to license something related to the MCE remote
> >>>> protocols (which are obviously RC-6 Mode 6A),
> >>>>
> >>>> c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
> >>>> encoding and decoding, as needed by MCE remotes, implemented in software
> >>>> doesn't violate anyone's government granted rights to exclusivity.
> >>>>
> >>>> I think it's much better to implement software RC-6 Mode 6A encoding and
> >>>> decoding in user space, doing only the minimum needed to get the
> >>>> hardware setup and going in the kernel.  
> >>>>
> >>>> Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
> >>>> worry me. 
> >>>>
> >>>>
> >>>> Maybe I'm being too conservative here, but I have a personal interest in
> >>>> keeping Linux free and unencumbered even in the US which, I cannot deny,
> >>>> has a patent system that is screwed up.
> >>> So I had one of the people who does all the license and patent audits
> >>> for Fedora packages look at the Philips patent on RC-6. He's 100%
> >>> positive that the patent *only* covers hardware, there should be no
> >>> problem whatsoever writing a software decoder for RC-6.
> >> OK.  Thanks for having some professionals take a look.  (I'm assuming
> >> that's the only patent.)
> >>
> >> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> >> end of the month.
> >>
> >> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> >> a common set of parameters, so I may be able to set up the decoders to
> >> handle decoding from two different remote types at once.  The HVR boards
> >> can ship with either type of remote AFAIK.
> >>
> >> I wonder if I can flip the keytables on the fly or if I have to create
> >> two different input devices?
> >>
> > 
> > Can you distinguish between the 2 remotes (not receivers)? Like I said,
> > I think the preferred way is to represent every remote that can be
> > distinguished from each other as a separate input device. Applications
> > expect to query device capabilities and expect them to stay somewhat
> > stable (we do support keymap change but I don't think anyone expectes
> > flip-flopping).
> > 
> With RC-5, you have no fields describing the remote. So, all the driver could
> do is an educated guess.
> 
> From a quick look I did at the RC-6 Mode 6A docs I found, I suspect that
> you can distinguish two different remotes when someone press a key there.
> 
> However, I don't think it is a good idea to automatically create a new interface
> every time a different vendor is detected. Maybe the user simply have a
> RC-6 IR to control his TV and doesn't have any intention on using that
> device on his computer.
> 
> IMO, the better is to have an API to allow creation of multiple interfaces
> per IR receiver, based on some scancode matching table and/or on some
> matching mask.
> 
> It should be possible to use the filter API to match different IR's by
> vendor/product on protocols that supports it, or to match address/command
> tuples on protocols where you just have those fields.
> 

OK, fair enough.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists