Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
in [Kernel]
|
Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.
From: Jarod Wilson on 30 Nov 2009 00:10 On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote: > On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov > <dmitry.torokhov(a)gmail.com> wrote: >>> In the code I posted there is one evdev device for each configured >>> remote. Mapped single keycodes are presented on these devices for each >>> IR burst. There is no device for the IR receiver. A LIRC type process >>> could watch these devices and then execute scripts based on the >>> keycodes reported. >>> > ... >> >> Maybe we should revisit Jon's patchset as well. Regretfully I did not >> have time to do that when it was submitted the last time. > > Consider my patch set a technology demo starting point. It shows a > modern architecture for integrating IR into evdev. Use the input from > everyone else to turn these concepts into a real design. I wrote the > code for the fun of it, I have no commercial interest in IR. I was > annoyed with how LIRC handled Sony remotes on my home system. > > The design is a clean slate implementation of IR for the kernel. No > attempt was made at legacy compatibility. I was familiar with evdev vs > /dev/mouse problems from my work on the X server. Because of working > on X I've also always hated keymaps (that's what drove the configfs > design). > > I wish one of the set top box or TV manufacturers would step up and > own this. They are the ones that would benefit the most. Jarod would > probably be open to some consulting, right? Mauro may actually have better connections on that front than I do... Thus far, I've only talked to a few vendors of IR devices, with mixed results getting any sort of support out of them. But its on my todo list to put out some feelers on the work front to see if we have any connections that we might be able to utilize. -- Jarod Wilson jarod(a)wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 7 Dec 2009 18:10 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: >> 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. That's good! Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andy Walls on 7 Dec 2009 21:50 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(a)radix.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? Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 8 Dec 2009 06:40 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(a)radix.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. Good! Please, try to design the decoder as an independent module that gets data from a kfifo and generate scancodes for the input API. > 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? IMO, the better is, by default, to open just one input device per IR receiver. From what I understand from our discussions, if the user wants to filter IR commands into several input interfaces, some userspace interface will be provided to allow the creation of other input interfaces for that purpose. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 8 Dec 2009 06:50
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(a)radix.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. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |