Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 awa...@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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 awa...@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-media in the body of a message to majord...@vger.kernel.org
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. 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). OK. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: 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. Hmmm. Let me see how the protoype turns out keeping that design objective in mind. I've already got the current RC-5 and NEC decoding state machines in cx23885-input a bit layered, but they are taking advantage of specific events signaled by my v4l2_subdev implementation. Strictly speaking the state machines don't have to. All of the remote protocols I have played with make framing pretty easy. 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. Hmm. That's not what I just thought I read from Dmitry Oh well. If I don'y get it done by 24 Dec, it'll be in the new year. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. 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). OK. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. The address field on RC-5 protocol is not meant to distinguish different vendors, but different applications. It identifies that a code should be sent to a TV or a VCR, or a DVD or a SAT. In the case of bundled IR's, some vendors like Hauppauge opted to use a reserved address to avoid conflicts with other equipments. It happens that vendor's reserved address can be different between two different vendors, but is just an educated guess to say that an address equal to 0x1e is Hauppauge. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. s/all of the loaded maps/all of the loaded maps per device/ You may have more than one IR receiver on a given machine. IMO, we may have a mask filter matching also, associated with each keycode table, to minimize the keycode seek time. Something like: if (scancode scancode_mask) check_scancode() This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. There's nothing wrong on receiving a scancode that won't map. This can simply be an event that you don't want to handle (for example, an IR code sent to user's TV set). IMO, the better is to provide this scancode at KERN_DEBUG (if debug is enabled), and via an observer program. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. However, I prefer a different scheme for splitting the signals apart. Load separate maps containing scancodes for each address. When the IR signals come in they are matched against the maps and a keycode is generated when a match is found. Now there is no need to distinguish between the remotes. It doesn't matter which remote generated the signal. scancode RC5/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1 on interface 2. Using the maps to split the commands out also fixes the problem with Sony remotes which use multiple protocols to control a single device. scancode Sony12/12/1 - protocol, address, command tuplet. Map this to power_on on interface 1. scancode Sony15/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. The address field on RC-5 protocol is not meant to distinguish different vendors, but different applications. It identifies that a code should be sent to a TV or a VCR, or a DVD or a SAT. In the case of bundled IR's, some vendors like Hauppauge opted to use a reserved address to avoid conflicts with other equipments. It happens that vendor's reserved address can be different between two different vendors, but is just an educated guess to say that an address equal to 0x1e is Hauppauge. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). However, I prefer a different scheme for splitting the signals apart. Load separate maps containing scancodes for each address. When the IR signals come in they are matched against the maps and a keycode is generated when a match is found. Now there is no need to distinguish between the remotes. It doesn't matter which remote generated the signal. scancode RC5/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1 on interface 2. Using the maps to split the commands out also fixes the problem with Sony remotes which use multiple protocols to control a single device. scancode Sony12/12/1 - protocol, address, command tuplet. Map this to power_on on interface 1. scancode Sony15/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. I agree. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. s/all of the loaded maps/all of the loaded maps per device/ You may have more than one IR receiver on a given machine. IMO, we may have a mask filter matching also, associated with each keycode table, to minimize the keycode seek time. Something like: if (scancode scancode_mask) check_scancode() This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. There's nothing wrong on receiving a scancode that won't map. This can simply be an event that you don't want to handle (for example, an IR code sent to user's TV set). IMO, the better is to provide this scancode at KERN_DEBUG (if debug is enabled), and via an observer program. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: With RC-5, you have no fields describing the remote. So, all the driver could do is an educated guess. It can't even do that, e.g. single remotes (even the dumb ones) can send different code groups (addresses) for different keys. 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. I think setting the keytables for each logical device would do. I.e. just have a way to create additional logical devices. Each can have its own keytable. The decoders would send their output to all logical remotes, trying to match the tables etc. It should be possible to use the filter API to match different IR's by vendor/product on protocols that supports it, That would mean unnecessary limiting. or to match address/command tuples on protocols where you just have those fields. Precisely. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Multi-function remotes combine multiple single function remotes into a single device. All universal remotes I have seen are multi-function. They usually combine three to five single function remotes. Yours is a two function remote TV and SAT. When you push TV and SAT you are changing which single function remote is being emulated. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Note that it is common for multfunction remotes to completely change IR protocol families when you switch which single function remote you are emulating. I have my universal set for a Sony TV , JVC DVD player and a Comcast STB. All three of those use different IR protocols. By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. However, I prefer a different scheme for splitting the signals apart. Load separate maps containing scancodes for each address. When the IR signals come in they are matched against the maps and a keycode is generated when a match is found. Now there is no need to distinguish between the remotes. It doesn't matter which remote generated the signal. scancode RC5/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1 on interface 2. Using the maps to split the commands out also fixes the problem with Sony remotes which use multiple protocols to control a single device. scancode Sony12/12/1 - protocol, address, command tuplet. Map this to power_on on interface 1. scancode Sony15/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. I agree. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: 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. I think setting the keytables for each logical device would do. Yes. I.e. just have a way to create additional logical devices. Each can have its own keytable. The decoders would send their output to all logical remotes, trying to match the tables etc. It should be possible to use the filter API to match different IR's by vendor/product on protocols that supports it, That would mean unnecessary limiting. If the mask is (unsigned)-1, it will not add any limit. This should be the default. The advantage of the mask is that you can speedup the keycode decoding by not calling a seek routine in the cases where it doesn't make sense. Also, the cost of scancode scancode_mask is cheap enough, comparing with the potential optimization gain of not seeking a data in a table that wouldn't match anyway. Also, the IR core may automatically generate such mask, by doing an and operation of all the scancodes at the table during table initialization/changes. If the mask is zero, it defaults to use a (unsigned) -1 mask. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 8, 2009 at 9:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Removing the maps for the bundled remotes from the receiver device drivers will break just works. The map will be in an __init section of the IR device driver. When it is fed into the input system a RAM based structure will be created. If you really want the 1KB memory back, use sysfs to remove the default map. An embedded system will have a bundled remote so it is going to want the map. If you want to change the default map loading a new map will release the memory from the previous map. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Removing the maps for the bundled remotes from the receiver device drivers will break just works. No. This can be provided by an udev application that will load the keytable when the device is connected. Of course before adding it into a module, we'll need to write such app. This will only affects the need of IR during boot time. The map will be in an __init section of the IR device driver. When it is fed into the input system a RAM based structure will be created. We can't use __init, since another device needing the keymap may be hot-plugged. If you really want the 1KB memory back, use sysfs to remove the default map. An embedded system will have a bundled remote so it is going to want the map. Yes, but it needs just one map, not all of them. The maps shouldn't be linked into the drivers, as the same map is used by several different devices on different drivers. So, the option is to allow customizing the available keymaps, if CONFIG_EMBEDDED. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 8, 2009 at 9:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Splitting them into multiple devices requires remembering state and scripting so it needs to be done in user space. If the user wants to control a radio app and a home automation app they need to choose. Keep the bundled remote and do some non-trivial scripting or buy a universal remote. Universal remotes make it much easier to achieve just works. The IR core can contain default universal profiles for various classes of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check if the receiver is cable of receiving these profiles before loading them. There would be ten of these default universal profiles at most and you can unload them from RAM if they aren't needed. Now Myth can have a menu with three remote choices: Universal Morotola_DVR Universal SciAtlanta_DVR Bundled The Bundled choice came from the map built into the IR receiver's device driver. The other two choices were loaded by the IR core after ensuring that the hardware could receive from a universal remote. The core would also load a couple of default radio profiles Univeral SonyDR112_RADIO Univeral OnkyoTX8255_RADIO Same for automation and mouse/keyboard emulation. Myth looks in sysfs and builds a menu containing DVR devices and all bundled entries. First app to open the Bundled device gets to keep it. These apps could take just works even farther. When they start up they could listen on all three evdev devices: Morotola_DVR, SciAtlanta_DVR, Bundled. And then if you find Myth responding to unwanted commands you could disable the unwanted profiles by deselecting them in the Myth
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 8, 2009 at 9:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Removing the maps for the bundled remotes from the receiver device drivers will break just works. No. This can be provided by an udev application that will load the keytable when the device is connected. Why do you want to pull the 1KB default mapping table out of the device driver __init section and more it to a udev script? Now we will have to maintain a parallel udev script for ever receiver's device driver. The purpose of putting this table into __init is to get rid of all these udev scripts in the default case. Of course before adding it into a module, we'll need to write such app. This will only affects the need of IR during boot time. The map will be in an __init section of the IR device driver. When it is fed into the input system a RAM based structure will be created. We can't use __init, since another device needing the keymap may be hot-plugged. You can handle that with __devinit If you really want the 1KB memory back, use sysfs to remove the default map. An embedded system will have a bundled remote so it is going to want the map. Yes, but it needs just one map, not all of them. The maps shouldn't be linked into the drivers, as the same map is used by several different devices on Link them or #include them, it doesn't make any difference. different drivers. So, the option is to allow customizing the available keymaps, if CONFIG_EMBEDDED. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: Jon Smirl wrote: This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? This case feels similar to that of Caps Lock, Num Lock and Scrool Lock, but I don't know if that scheme could be applied here. -- Regards, Feri. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Splitting them into multiple devices requires remembering state and scripting so it needs to be done in user space. It shouldn't be hard to do it in kernelspace, since you'll need to have one evdev interface associated with the IR anyway, but this will add some extra complexity at the scancode-keycode conversion, but I'm wandering if we should do it or not. Maybe the better is to not do it in kernelspace, to avoid adding there an extra complexity that can easily be done in userspace. If the user wants to control a radio app and a home automation app they need to choose. Keep the bundled remote and do some non-trivial scripting or buy a universal remote. Ok, but using the shipped IR even without a separate address group for different applications, and having it controlling radio app and tv app (not simultaneously) should not be hard, but I LIRC already covers such usecase, so maybe we don't need to worry about it. Universal remotes make it much easier to achieve just works. True. The IR core can contain default universal profiles for various classes of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check if the receiver is cable of receiving these profiles before loading them. There would be ten of these default universal profiles at most and you can unload them from RAM if they aren't needed. Now Myth can have a menu with three remote choices: Universal Morotola_DVR Universal SciAtlanta_DVR Bundled The Bundled choice came from the map built into the IR receiver's device driver. The other two choices
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 awa...@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
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 07:52:02AM -0500, Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) 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. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. How many sancodes do we need to reliably recognize the device though? I am not sure users would want to press 5 random buttons in order to start using the remote, unless it happens exactly once and then we manage to store the data somewhere. This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. Just report MSC_SCAN always. As I said elsewhere we can extend it to be multi-dword if needed (just need to agree on endianness). -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 07:46:52AM -0500, Andy Walls wrote: On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: 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. Hmmm. Let me see how the protoype turns out keeping that design objective in mind. I've already got the current RC-5 and NEC decoding state machines in cx23885-input a bit layered, but they are taking advantage of specific events signaled by my v4l2_subdev implementation. Strictly speaking the state machines don't have to. All of the remote protocols I have played with make framing pretty easy. 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. Hmm. That's not what I just thought I read from Dmitry I am a resonable guy ;) In cases when we can certainly say that there are 2 separate remotes (and we know characteristics somehow) we need to create 2 input devices. Otherwise we can't ;) -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 8, 2009 at 11:27 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: 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)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Splitting them into multiple devices requires remembering state and scripting so it needs to be done in user space. It shouldn't be hard to do it in kernelspace, since you'll need to have one evdev interface associated with the IR anyway, but this will add some extra complexity at the scancode-keycode conversion, but I'm wandering if we should do it or not. Maybe the better is to not do it in kernelspace, to avoid adding there an extra complexity that can easily be done in userspace. If the user wants to control a radio app and a home automation app they need to choose. Keep the bundled remote and do some non-trivial scripting or buy a universal remote. Ok, but using the shipped IR even without a separate address group for different applications, and having it controlling radio app and tv app (not simultaneously) should not be hard, but I LIRC already covers such usecase, so maybe we don't need to worry about it. Universal remotes make it much easier to achieve just works. True. The IR core can contain default universal profiles for various classes of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check if the receiver is cable of receiving these profiles before loading them. There would be ten of these default universal profiles at most and you can unload them from RAM if they aren't needed. Now Myth can have a menu with three remote choices: Universal Morotola_DVR Universal SciAtlanta_DVR Bundled The
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl jonsm...@gmail.com writes: Why do you want to pull the 1KB default mapping table out of the device driver __init section and more it to a udev script? Now we will have to maintain a parallel udev script for ever receiver's device driver. Of course no. We will need a single program (script etc.) for all devices. And we will need a database of the known remotes (scan and key codes). You can handle that with __devinit __devinit is NOP with hot-plug. Fortunately we don't need the keymaps in the kernel. For certain uses we may (and may not) need to have one keymap built-in, perhaps something similar to the embedded initrd. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Jon Smirl jonsm...@gmail.com writes: Why do you want to pull the 1KB default mapping table out of the device driver __init section and more it to a udev script? Now we will have to maintain a parallel udev script for ever receiver's device driver. Of course no. We will need a single program (script etc.) for all devices. And we will need a database of the known remotes (scan and key codes). The keycode database can be easily extracted from kernel drivers by script. I have it already at V4L/DVB development tree. You can handle that with __devinit __devinit is NOP with hot-plug. Fortunately we don't need the keymaps in the kernel. For certain uses we may (and may not) need to have one keymap built-in, perhaps something similar to the embedded initrd. I still think the better is to have them in kernel, but compiled only if selected at Kbuild. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov wrote: I am a resonable guy ;) In cases when we can certainly say that there are 2 separate remotes (and we know characteristics somehow) we need to create 2 input devices. Otherwise we can't ;) Only on very few specific cases (a few protocols), you can be (almost) sure. Even on this case, universal remotes can fake another IR. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: I don't like the idea of automatically loading 3 different keycodes at the same time. You may have overlaps between different keycode tables. The better is to have some userspace GUI that will allow the user to select what keycode table(s) he want to be available, if he decides to not use the bundled IR. Of course there is going to be overlap of the keycodes, but not the scancodes. There should be almost 100% overlap. What prevents users to create overlaps at scancodes? We might add some protection, but, providing that different keycode tables can be used by different applications, why do we need to prevent it? The three maps are there to support a non-technical user, a sophisticated user will disable two of them. This works because the non-technical user is only going to use one of the three IR device profiles. The other two may be loaded, but the user isn't sending any IR signals that match their maps. I doubt you can map all cases with just three profiles. Where this breaks down is if they are using SciAtlanta_DVR to control MythTV and they also happen to have a physical Motorola DVR in the same room. The Linux box is going to pick up the commands meant for the Motorola DVR and both boxes will respond.. In that cause they will need to figure figure out how to disable the Motorola DVR profile. I used to have a Set Top Box that has some broken code to decode IR. So, sometimes, when I used to press a key on my TV IR, the STB were getting the code, producing a really bad result. That's really bad. A normal user is able to click on some graphical application and select his IR model. The app may even have some photos or pictures representing the most used IR's. This is better than letting him to to to some forum, asking his friends, etc, trying to figure out why his PC is doing something wrong when he changes a channel on his TV. But is a non-technical person likely to have two DVRs in the same room? Well, I know someone that has an 8 year old children with a setup like this: a PC monitor that has an IR, and a PC with a TV board also with IR. Of course, both the monitor and the PC are at the same room. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 awa...@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. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 awa...@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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 awa...@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). -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote: On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov dmitry.torok...@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 ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Fri, Nov 27, 2009 at 2:33 AM, Christoph Bartelmus l...@bartelmus.de wrote: Hi Jon, on 27 Nov 09 at 00:06, Jon Smirl wrote: [...] 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. Can you elaborate on this? I'm not aware of any issue with Sony remotes. irrecord can't figure out that Sony remotes transmit multiple protocols so it reverts to raw mode. When trying to figure that out I started working on the concept of running simultaneous state machines to decode the pulse timings. I also had an embedded system with an IR receiver hooked to a timer input pin. I started off with a implementation that ran multiple Sony protocol decoders and used the input from the timer pin. I know now that I could use irrecord individually for each group of keys on the Sony remote and then glue the flies together. But that's the path that caused me to write the code. Also throw into pot that I had previously had some very bad experiences trying to deal with the old mouse and kbd device inside of the X server. I was aware that evdev was designed to fix all of those problems. That made me want a fully evdev based design. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Em Thu, 26 Nov 2009 17:06:03 -0200 Mauro Carvalho Chehab mche...@redhat.com escreveu: Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Technically, it is not hard to port this solution to the other drivers, but the issue is that we don't have all those IR's to know what is the complete scancode that each key produces. So, the hardest part is to find a way for doing it without causing regressions, and to find a group of people that will help testing the new way. We don't want to port it to other drivers. We need to have a common module which does all RCx decoding. The individual drivers should be as simple as possible, something that I outlined in a previous mail. With the current 7bits mask applied to almost all devices, it is probably not very useful for those who want to use generic IRs. We really need to port the solution we've done on dvb-usb to the other drivers, allowing them to have the entire scancode at the tables while keep supporting table replacement. The issue is that we currently have only 7bits of the scan codes produced by the IR's. So, we need to re-generate the keycode tables for each IR after the changes got applied. Ok, I got some time to add support for tables with the full scan codes at the V4L drivers. In order to not break all tables, I've confined the changes to just one device (HVR-950, at the em28xx driver). The patches were already committed at the -hg development tree. In order to support tables with the full scan codes, all that is needed is to add the RC5 address + RC5 data when calling ir_input_keydown. So, the change is as simple as: - ir_input_keydown(ir-input, ir-ir, -poll_result.rc_data[0]); + ir_input_keydown(ir-input, ir-ir, +poll_result.rc_address 8 | +poll_result.rc_data[0]); + else An example of such patch can be seen at: http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56 There are still some work to do, since, currently, the drivers will use a table with a fixed size. So, you can replace the current values, but it is not possible to add new keys. The fix for it is simple, but we need to think what would be the better way for it. There are two alternatives: - A table with a fixed size (like 128 or 256 entries - maybe a modprobe parameter could be used to change its size); - some way to increase/reduce the table size. In this case, we'll likely need some ioctl for it. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Gerd, on 26 Nov 09 at 00:22, Gerd Hoffmann wrote: [...] To sum it up: I don't think this information will be useful at all for lircd or anyone else. [...] I know that lircd does matching instead of decoding, which allows to handle unknown encodings. Thats why I think there will always be cases which only lircd will be able to handle (using raw samples). That doesn't make attempts to actually decode the IR samples a useless exercise though ;) Well, in my opinion it is kind of useless. I don't see any use case or any demand for passing this kind of information to userspace, at least in the LIRC context. If there's no demand, why bother? Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi, on 25 Nov 09 at 12:44, Jarod Wilson wrote: [...] Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: [...] [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight. I'm happy to see that the discussion is getting along. But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just because I'm not familiar at all with input layer toolset. 1. For sure in-kernel decoding will require some assistance from userspace to load the mapping from IR codes to keys. So, if there needs to be a tool in userspace that does some kind of autodetection, why not have a tool that does some autodetection and autoconfigures lircd for the current device. Lots of code duplication in kernel saved. What's the actual benefit of in-kernel decoding? 2. What would be the format of the key map? lircd.conf files already exist for a lot of remote controls. Will we have a second incompatible format to map the keys in-kernel? Where are the tools that create the key maps for new remotes? Maybe someone can shed some light on this. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 09:01:00AM +0100, Christoph Bartelmus wrote: Hi, on 25 Nov 09 at 12:44, Jarod Wilson wrote: [...] Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: [...] [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight. I'm happy to see that the discussion is getting along. But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just because I'm not familiar at all with input layer toolset. 1. For sure in-kernel decoding will require some assistance from userspace to load the mapping from IR codes to keys. So, if there needs to be a tool in userspace that does some kind of autodetection, why not have a tool that does some autodetection and autoconfigures lircd for the current device. Lots of code duplication in kernel saved. What's the actual benefit of in-kernel decoding? Why are you mixing configuration and decoding? Configuration I expect will be done with the help of userspace. Udev is probably the best place. 2. What would be the format of the key map? lircd.conf files already exist for a lot of remote controls. Will we have a second incompatible format to map the keys in-kernel? Where are the tools that create the key maps for new remotes? Same as the keymaps for the other input devices I'd expect. Maybe someone can shed some light on this. Christoph -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/26/09 08:28, Christoph Bartelmus wrote: Hi Gerd, on 26 Nov 09 at 00:22, Gerd Hoffmann wrote: [...] To sum it up: I don't think this information will be useful at all for lircd or anyone else. [...] I know that lircd does matching instead of decoding, which allows to handle unknown encodings. Thats why I think there will always be cases which only lircd will be able to handle (using raw samples). That doesn't make attempts to actually decode the IR samples a useless exercise though ;) Well, in my opinion it is kind of useless. I don't see any use case or any demand for passing this kind of information to userspace, at least in the LIRC context. If there's no demand, why bother? There have been complains about this getting lost somewhere in this thread, so it looks like there are people which do care. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: (This is no recommendation for lirc. I have no idea whether a pulse/space - scancode - keycode translation would be practical there.) It would, but not exactly in the present shape. For example, there are several bttv and saa7134 devices that polls (or receive IRQ interrupts) to detect pulses (and the absense of them) in order to create a pulse/space code. The conversion from pulse/space to scancode is done inside the driver, with the help of some generic routines and based on the protocol specifications. Right. There are currently several problems (I'm quite familiar with saa713x RC5 code): the one that it barely works and is not implemented for most such GPIO/IRQ-driven cards (as of 2.6.29 or so). This could be fixed, I even have a working though quickdirty patch. Another: the RC5 allows for groups and codes within groups. The mapping can only use one group, and there can only be one mapping. These design limitations mean it's unusable in many cases. This is a current limitation, since the saa713x code converts the RC5 code into a 7bits scancode, by applying a mask. One of the reasons for that conversion is that the two ioctls that allows reading/changing the keycode table (EVIOCSKEYCODE and EVIOCGKEYCODE) were implemented via a table with a fixed size of 128 entries. We already have an implementation at the dvb-usb driver that uses a table without such limits, where the IR scancode is completely stored there. So, you can create any arbitrary scancode -- keycode table there. Technically, it is not hard to port this solution to the other drivers, but the issue is that we don't have all those IR's to know what is the complete scancode that each key produces. So, the hardest part is to find a way for doing it without causing regressions, and to find a group of people that will help testing the new way. Maybe one alternative would be to add a modprobe parameter at the converted drivers to allow them to work with the old behavior, after their migration. Those devices where the decoding is done by software can support any IR protocols. Yes, and there can be multiple remote controllers, and multiple code groups within a remote. This can be solved by adding a few ioctls to enumerate the supported protocols and to select the one(s) that will be handled by the kernel driver. The driver may have to handle many protocols simultaneously. This is not a problem from a technical POV. There are 3 different situations: 1) hardware where you can support multiple protocols at the same time; 2) hardware that supports one programmable protocol; 3) hardware that support just one (or a limited set) of protocols. In general, (1) applies only to those devices that outputs a raw pulse/space code, where they just connect the IR sensor to a generic I/O pin and let the software to decode the code. This is the case of most of cheapest devices. Yet, you can find some cheap devices with low-cost micro-controllers with a dedicated firmware on its ROM, doing (2). The most commonly found hardware, in general have a chip to decode IR pulse/space sequences, converting it on a scancode and implementing (3). That's said, a raw input interface, only fits on case (1). On the other hand, the existing input API works for all types of IR. However, we need to add the ioctls to allow protocol selection, to better handle (1) and (3). Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 2009-11-26 at 01:23 -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: Czesc Krzysztof, on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: [...] I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely unacceptable for many LIRC users, including myself. I agree with Christoph. Is it that the input subsystem is better developed and seen as a leverage point for development and thus an easier place to get results earlier? If so, then one should definitely deal with transmitters early in the design, as that is where the most unknowns lie. With the end of analog TV, people will have STBs feeding analog only video cards. Being able to change the channel on the STB with an IR transmitter controlled by applications like MythTV is essential. And on some different notes: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are forced to support lirc because the remores are not available through other means? I believe it is the latter and applications writers would be happy to reduce number of ways they get button data. Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. serial receivers and transmitters, both supported by lirc_serial, were the most frequently used devices outside of plain old keyboards. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that... I don't think there is LIRC aversion per se. We are just trying to decide whether multiple interfaces for the same data is needed. And I don't think that we will completely reject userspace components. Just as input subsystem allows for userspace drivers I do not think why we can't have the same for the LIRC. But I do think that the primary interface for regular userspace consumers (read mplayer and MythTV and the likes) should be input event interface (EV_KEY/KEY_*). Works for me. Even though two interfaces is a bit of extra work, I'm not averse to Gerd's suggestions of a dual implementation: input layer for the simple, common use case, and lirc type interface for more sophisticated usage. One thing I would like to be provided by the input layer is automatic key-up after a specified time. Remote protocols send an initial button press and then after a certain amount of time (~115 ms for RC-5) send a repeated code or repeat sequence, if the button is still pressed. Currently, most of the V4L-DVB drivers have some code to perform a timeout just to send the key-up event. That's a good bit of redundant code for key-up timeouts that I suspect makes sense for the input layer to handle. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. IOW the driver generates artificial pulse code for lircd? I think - pure bloat. lircd can get events from input layer without problems. Perhaps I misunderstood? lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse codes. It is very bad to have two interfaces for the same thing, because people may do things like that. I think having a raw scan code interface + the key code cooked mode is beneficial. For remotes lacking the raw interface only the latter could be used. It sounds an interesting idea. Are you meaning that we should do more than one RC per input event interface? I think so. Why not? For example, one of my remotes generates codes from at least two RC5 groups (in only one mode). Currently a remote is limited to only one RC5 group. Yet, both are RC5. This can already be handled by the input layer. See dvb-usb implementation. The issue I see is to support at the same time NEC and RC5 protocols. While this may work with some devices, for others, the hardware won't allow. I think the mapping should be: key = proto + group + raw code, while key2 could be different_proto + different group (if any) + another code. This may work for protocols up to RC5, that uses either 8 or 16 bits. However, RC6 mode 6 codes can be 32 bits, and we have only 32 bits for a scancode. So, we don't have spare bits to represent a protocol, if we consider RC6 mode 6 codes as well. If so, why do you think we need to handle more than one IR protocol at the same time? Why not? There are X-in-1 remotes on the market for years. They can speak many protocols at once. One may want to have a protocol to handle DVD apps while another for DVB etc. And someone may want to use several different remotes, why not? Personally I use two different remotes (both set to speak RC5 but what if I couldn't set the protocol?). Sure, it requires a bit of hackery (not with pulse code and lircd). I think this will just make the driver more complex without need. Not much more, and there is a need. See above. Also, several protocols have a way to check if a keystroke were properly received. When handling just one protocol, we can use this to double check the key. However, on a multiprotocol mode, we'll need to disable this feature. PS.: For those following those discussions that want to know more about IR protocols, a good reference is at: http://www.sbprojects.com/knowledge/ir/ir.htm Unfortunately, it doesn't describe RC6 mode 6. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls wrote: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Regards, Andy LIRC Fan-Boy Walls This is not a lirc love or hate thread. We're simply discussing the better API's for IR, from the technical standpoint, considering that some users may want to use lirc and some users may want to have their IR working out-of-the-box. By not using lirc, users will loose the advantages of having lircd, like clicking on a button and calling automatically the DVD player application, but this means that their device with the shipped IR will work without needing to do any setup. Whatever we do, both kind of usages should be possible, since there are demand for both. Also, the decision should consider that the existing drivers will need to support the new way without causing regressions. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: PS.: For those following those discussions that want to know more about IR protocols, a good reference is at: http://www.sbprojects.com/knowledge/ir/ir.htm Unfortunately, it doesn't describe RC6 mode 6. RC-6 Mode 0 and Mode 6A is briefly describe here: http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm That page is slightly wrong, as there is some data coded in the header such as the RC-6 Mode. This page is an older version of the sbprojects.com RC-6 page, before the information on RC-6 Mode 6A was removed: http://slycontrol.ru/scr/kb/rc6.htm My personal opinion is that, for non-technical reasons, RC-6 Mode 6A decoding should not be included in the kernel. That's why I didn't do it for the HVR-1850/CX23888. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls wrote:
On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
l...@bartelmus.de (Christoph Bartelmus) writes:
I think we shouldn't at this time worry about IR transmitters.
Sorry, but I have to disagree strongly.
Any interface without transmitter support would be absolutely unacceptable
for many LIRC users, including myself.
I don't say don't use a transmitter.
I say the transmitter is not an input device, they are completely
independent functions. I can't see any reason to try and fit both in the
same interface - can you?
The underlying hardware need not be completely independent.
For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
chips have IR hardware that shares a common timing source, interrupt
line, interrupt status register, etc, between IR Rx and Tx. They can
also do things like loopback of Tx to Rx.
That said, an underlying hardware implementation can be split up to user
space with separate interfaces Tx and Rx. The underlying driver module
would have to manage the dependencies. I would guess that would be
easier for driver modules, if the userspace interfaces were designed
with such combined IR Tx/Rx hardware in mind.
True, but, in the case of Rx, there are already API's for it. Tx case is
simpler, as we don't have any API for it yet.
I'm not sure if all the existing hardware for TX currently supports only
raw pulse/code sequencies, but I still think that, even on the Tx case,
it is better to send scancodes to the driver, and let it do the conversion
to raw pulse/code, if the hardware requires pulse/code instead of scancodes.
However, as we have green field,
I would add the protocol explicitly for each scancode to be transmitted, like:
struct ir_tx {
enum ir_protocol proto;
u32 scancode;
};
Eventually, we might have a protocol raw and some extra field to allow passing
a raw pulse/code sequence instead of a scancode.
Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
l...@bartelmus.de (Christoph Bartelmus) writes:
I think we shouldn't at this time worry about IR transmitters.
Sorry, but I have to disagree strongly.
Any interface without transmitter support would be absolutely unacceptable
for many LIRC users, including myself.
I don't say don't use a transmitter.
I say the transmitter is not an input device, they are completely
independent functions. I can't see any reason to try and fit both in the
same interface - can you?
The underlying hardware need not be completely independent.
For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
chips have IR hardware that shares a common timing source, interrupt
line, interrupt status register, etc, between IR Rx and Tx. They can
also do things like loopback of Tx to Rx.
That said, an underlying hardware implementation can be split up to user
space with separate interfaces Tx and Rx. The underlying driver module
would have to manage the dependencies. I would guess that would be
easier for driver modules, if the userspace interfaces were designed
with such combined IR Tx/Rx hardware in mind.
True, but, in the case of Rx, there are already API's for it. Tx case is
simpler, as we don't have any API for it yet.
I'm not sure if all the existing hardware for TX currently supports only
raw pulse/code sequencies, but I still think that, even on the Tx case,
it is better to send scancodes to the driver, and let it do the conversion
to raw pulse/code, if the hardware requires pulse/code instead of scancodes.
That seems like a decision which will create a lots of duplicative code
in the kernel. Add it's just busy-work to write such code when a
userspace application in common use already handles the protocols and
sends raw pulses to hardware that expects raw pulses.
However, as we have green field,
I would add the protocol explicitly for each scancode to be transmitted, like:
struct ir_tx {
enum ir_protocol proto;
u32 scancode;
};
Eventually, we might have a protocol raw and some extra field to allow
passing
a raw pulse/code sequence instead of a scancode.
I think you would have to. 32 bits is really not enough for all
protocols, and it is already partial encoding of information anyway.
If the Tx driver has to break them down into pulses anyway, why not have
fields with more meaningful names
mode
toggle
customer code (or system code or address),
information (or command)
According to
http://slycontrol.ru/scr/kb/rc6.htm
the information field could be up to 128 bits.
(Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
kernel.)
Regards,
Andy
Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson wrote: On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: ... I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. There's one gripe I agree with, and that is that its still not plug-n-play. Something where udev auto-loads a sane default remote config for say, mceusb transceivers, and the stock mce remote Just Works would be nice, but auto-config is mostly out the window the second you involve transmitters and universal remotes anyway. For several devices, an udev rule that auto-loads a sane default keymap does work. Of course, this won't cover 100% of the usages, and I lirc is a very good way of covering the holes. But outside of that, I think objections are largely philosophical -- in a nutshell, the kernel has an input layer, remotes are input devices, and lirc doesn't conform to input layer standards. Yes. I think this is mainly the issue. The other issue is how to migrate the existing drivers to a new API without causing regressions. If we decide that IR's that receive raw pulse/code should use the raw input interface, this means that a large task force will be needed to convert the existing drivers to use it. I do understand that argument, I just don't currently agree that all IR must go through the input layer before the drivers are acceptable for upstream -- especially since lircd can reinject decoded key presses into the input layer via uinput. IMHO, there are some scenarios for an upcoming kernel IR raw input interface: 1) as a temporary solution for merging lirc drivers, knowing in advance that it will be later converted to the standard input API; 2) as a raw interface for some weird usages, with its usage limited to just a few device drivers; 3) as the solution for all IR's that produces pulse/code raw sequences; For (1), while it may make sense, we'll be creating an userspace API that is meant to be stable, knowing in advance that it will be removed in a close future. IMHO, we should avoid (2), since it will be hard to define what is the limited usage, and I bet that it will evolute to (3) in a long term. For (3), we need to consider the migration of the existing drivers. By discarding scenario (2), this means that, in the long term, we'll need to either migrate all existing out-of-tree lirc drivers to the standard input API interface (scenario 1) or to migrate the existing drivers to the raw input interface (scenario 3). For me, scenario (1) is fine if we add the lirc drivers at drivers/staging. I believe Jarod's intent is to have the LIRC components, that need to be in kernel modules, moved into kernel mainline to avoid the headaches of out of kernel driver maintenance. I'm not sure it is time well spent for developers, or end users, to develop yet another IR receive implementation in addition to the ones we suffer with now. Yeah, a fairly relevant factor in all this is that, despite not being in the linux kernel source tree proper-like, the lirc drivers and lirc have been in use for many years by lots of users. The likes of Fedora, Debian, Ubuntu, SUSE, Mandriva, etc. have all been shipping lirc drivers for years now. While lirc certainly isn't perfect (its not always the easiest thing for users to set up), it has actually proven itself pretty robust and useful in the field, once set up. The bulk of breakage in lirc I've personally had to deal with has mostly come in the form of kernel interface changes, which would definitely be mitigated by not having to maintain the drivers out-of-tree any longer. Now, I'm all for improving things and integrating better with the input subsystem, but what I don't really want to do is break compatibility with the existing setups on thousands (and thousands?) of MythTV boxes around the globe. The lirc userspace can be pretty nimble. If we can come up with a shiny new way that raw IR can be passed out through an input device, I'm pretty sure lirc userspace can be adapted to handle that. If a new input-layer-based transmit interface is developed, we can take advantage of that too. But there's already a very mature lirc interface for doing all of this. So why not start with adding things more or less as they exist right now and evolve the drivers into an idealized form? Getting *something* into the kernel in the first place is a huge step in that direction. I agree. We should really move forward and add it to kernel as soon as possible, and start to work on improving the IR support at the upstream kernel. Jarold, What do you think of
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Andy Walls awa...@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? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson wrote: On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I'm not sure what two ways you are talking about. With the patches posted by Jarod, nothing has to be changed in userspace. Everything works, no code needs to be written and tested, everybody is happy. The existing drivers use input layer. Do you want part of the tree to use existing lirc interface while the other part uses their own in-kernel (badly broken for example) code to do precisely the same thing? Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? They are not limited to the currently bundled IR's, since almost all drivers allow replacing the existing scancode/keycode table to a new onw. Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. It should be done. Having two ways for doing the same thing is not an option. We'll need to unify them sooner or later. The sooner, the better. We can have a good code for both, or we can end up with badly broken media drivers and incompatible, suboptimal existing lirc interface (though most probably much better in terms of quality, especially after Jarod's work). Well, is there any reason most of those drivers with currently-in-kernel-but-badly-broken decoding can't be converted to use the lirc interface if its merged into the kernel? And/or, everything could converge on a new in-kernel decoding infra that wasn't badly broken. Sure, there may be two separate ways of doing essentially the same thing for a while, but meh. The lirc way works NOW for an incredibly wide variety of receivers, transmitters, IR protocols, etc. Yes: the same drivers support both pulse/space and in-hardware scancode conversion. In order to use the raw pulse/space API, they'll need to generate pseudo pulse/space's. This would be a dirty solution, IMHO. Also, changing the drivers would not be that easy, since it will require lots of tests with IR's and devices that the developers won't have. This is a weaker argument, since no matter what decided, we'll need to change the drivers code (on lirc drivers or on the in-kernel drivers) even without having all hardware available. I do concur that Just Works decoding for bundled remotes w/o having to configure anything would be nice, and one way to go about doing that certainly is via in-kernel IR decoding. But at the same time, the second you want to use something other than a bundled remote, things fall down, and having to do a bunch of setkeycode ops seems less optimal than simply dropping an appropriate lircd.conf in place. I don't see this as an issue. We have by far too much work to be done in kernelspace than the changes that are needed on userspace. Replace the entire scancode table with setkeycode ops is very fast, and needs to be done only once, at lirc startup. Once you load the new IR code at the driver, the kernel will send the new keycodes to lirc. It doesn't seem hard to modify lirc to do read the lircd.conf table and replace the IR scancodes at the in-kernel driver. It took me half an hour to write my own keycode loader code, and you can use it as the basis for such feature: http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Gerd Hoffmann wrote: On 11/25/09 19:20, Devin Heitmueller wrote: On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilsonja...@wilsonet.com wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. I think at the end of the day we'll want to have all IR drivers use the same interface. The way the current in-kernel input layer drivers work obviously isn't perfect too, so we *must* consider both worlds to get a good solution for long-term ... I made an attempt at implementing all of this a year ago. http://lkml.org/lkml/2008/11/5/233 All of this kernel code is tiny, about 20K including a driver. Basic flow works like this: Add a new IR data type to the input framework http://lkml.org/lkml/2008/11/5/234 Example mceusb IR input driver http://lkml.org/lkml/2008/11/5/238 In-kernel decoding of core IR protocols - RC5, RC6, etc http://lkml.org/lkml/2008/11/5/234 Decoded core protocols pass through a translation map based on configfs When core protocol matches an entry in configfs it is turned into a keycode event. http://lkml.org/lkml/2008/11/5/235 You make a directory in /configfs/remotes for each remote you have. Making the directory creates a new evdev device. Under the directory make an entry for each command generated by the device. These entries cause the decoded IR data to be mapped into keycodes on the new evdev device. udev would load these configfs mappings at boot time... mkdir /config/remotes/sony -- this creates a new evdev device mkdir remotes/sony/one echo 7 remotes/sony/one/protocol echo 264 remotes/sony/one/command echo 2 remotes/sony/one/keycode This transforms a button push of 1 on my remote into a key stroke for KEY_1 * configfs root * --remotes * specific remote * --keymap * protocol * device * command * keycode * --repeat keymaps * * another remote * --more keymaps You can map the 1 button from multiple remotes to KEY_1 if you want. Or you can use a single remote to create multiple virtual keyboards. - Raw IR pulse data is available in a FIFO via sysfs. You can use this to figure out new remote protocols. Two input events are generated 1) an event for the decoded raw IR protocol 2) a keycode event if thedecoded raw IR protocol matches an entry in the configfs You can also send pulses. -- If you want to script this, you would have a user space task that watches for either the decoded IR codes or the mapped keycodes. This system also works with user space device drivers. They can inject input events into the early event flow and they will get processed as if the event originated in the kernel. - Sure you could push the protocol decoding code (RC5, etc) into user space. Seems like a lot of hassle to move about 3KB of code out of the kernel. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
BTW, we used to have device specific user space interfaces for mouse and keyboard. These caused all sort of problems. A lot of work went into unifying them under evdev. It will be years until the old, messed up interfaces can be totally removed. I'm not in favor of repeating the problems with a device specific user space interface for IR. I believe all new input devices should implement the evdev framework. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson wrote: I guess the question is what is the interface we want the regular userspace (i.e. not lircd) to use. Right now programs has to use 2 intercfaces - one lirc for dealing with remotes that are not using the standard event interface and evdev for remotes using it as well as the rest of the input devices. From the mythtv perspective, using the input layer could yield a better out-of-the-box experience -- users don't have to set up an lircrc mapping that converts key names as specified in lircd.conf into commands (key strokes, actually) that mythtv understands. For example, a button labeled Play in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right thing with it. If everything came through the input layer, be that natively or via lircd's uinput reinjection, there would be no need to do that extra mapping step, mythtv would simply handle a KEY_PLAY event. So at worst, one manual mapping to do -- IR signal to standard button name in lircd.conf -- instead of two. But the lircrc approach does also allow more flexibility, in that you can only have a certain app respond to a certain key, if so desired, and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, KEY_YELLOW -- what should their default functionality be? I know some users map a pair of those to mythtv's skip to next commflag point and skip to prior commflag point). Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., etc. at all right now, it operates purely on keys commonly found on a standard keyboard. Remedying that is on my TODO list for the next release, if I can carve out the time. This discussion is a little OT from the API discussions, since it affects both out-of-the box IR reception via input layer and lirc. All media applications should be capable of handling the corresponding KEY_PLAY, KEY_VOLUMEUP ... keys without needing to do anything else than just handling the corresponding keycode. You shouldn't need to start a daemon or doing anything else for this to work out-of-the-box. They currently don't do it due to historic reasons (it is easier to let something else remap KEY_PLAY into 'p' than to add the proper code there). When using non-hot-pluggable devices where you're building a dedicated MCE hardware (this is the common case of MythTV setups), things are not that bad, since, once you set your hardware, it is done. However, by looking on the number of different new devices, it seems that the most common type of devices are the TV USB sticks. As they are hot pluggable, eventually users may have more than one hardware and they expect that the IR layer will work equally on all your devices. The proper way for supporting it is to have a common application-agnostic keycode to indicate the received events. For example, all IR's should produce KEY_CHANNELUP/KEY_CHANNELDOWN events for changing the channels. Also, on a perfect world, lirc should send this event to the multimedia application that handles TV when such key is pressed, instead of converting into some other keycode. This prevents future problems if, for some reason, the application needs to do something else with that key, or if the key has a different meaning on some different contexts. For example, on some applications, KEY_UP/KEY_DOWN can mean to change a channel, but those keys are also used for menu navigation. However, KEY_CHANNELUP has a clear unique meaning: to change a channel. The expected behavior, from users perspective, is to mimic a TV box, where if you press channel UP any open menu will be closed and the channel will be changed, but pressing UP key will navigate at the menu. Well, if you map KEY_CHANNELUP as KEY_UP, you'll produce a different behavior. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Christoph Bartelmus wrote: Hi, on 25 Nov 09 at 12:44, Jarod Wilson wrote: [...] Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: [...] [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight. I'm happy to see that the discussion is getting along. But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just because I'm not familiar at all with input layer toolset. 1. For sure in-kernel decoding will require some assistance from userspace to load the mapping from IR codes to keys. Current drivers have the IR keycode tables in-kernel also, directly associated with the board ID. So, if there needs to be a tool in userspace that does some kind of autodetection, why not have a tool that does some autodetection and autoconfigures lircd for the current device. There are userspace tools to change the IR keycode maps. It shouldn't be hard to change it to autodetect the hardware and to autoconfigure lircd. Lots of code duplication in kernel saved. Huh? The code is already there. What's the actual benefit of in-kernel decoding? There are two benefits: 1) the developer that adds the hardware also adds the IR code. He has the hardware and the IR for testing, so it means a faster development cycle than waiting for someone else with the same hardware and IR to recode it on some other place. You should remember that not all developers use lirc; 2) the IR works out of the box. 2. What would be the format of the key map? lircd.conf files already exist for a lot of remote controls. Will we have a second incompatible format to map the keys in-kernel? Where are the tools that create the key maps for new remotes? No matter what tool you use, the format should be very close: scancode - key_code. If you wan to take a look on a real example, I'm enclosing the keycode table used by dib0700 driver, as generated/readed by a simple keycode application I made to test the dynamic keycode loading: http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c Most of the keycodes there are RC5 keys. There are also some NEC keys, as those devices can work with either RC5 or NEC keycodes, by using a different parameter during module load. In the case of this driver, the pulse/space is done in hardware by the DibCom chip. The scancode is sent to PC via the USB interface. I hope it helps for you to better understand how this works. Cheers, Mauro. 0x0700 KEY_MUTE 0x0701 KEY_MENU 0x0739 KEY_POWER 0x0703 KEY_VOLUMEUP 0x0709 KEY_VOLUMEDOWN 0x0706 KEY_CHANNELUP 0x070c KEY_CHANNELDOWN 0x070f KEY_1 0x0715 KEY_2 0x0710 KEY_3 0x0718 KEY_4 0x071b KEY_5 0x071e KEY_6 0x0711 KEY_7 0x0721 KEY_8 0x0712 KEY_9 0x0727 KEY_0 0x0724 KEY_SCREEN 0x072a KEY_TEXT 0x072d KEY_REWIND 0x0730 KEY_PLAY 0x0733 KEY_FASTFORWARD 0x0736 KEY_RECORD 0x073c KEY_STOP 0x073f KEY_CANCEL 0xeb01 KEY_POWER 0xeb02 KEY_1 0xeb03 KEY_2 0xeb04 KEY_3 0xeb05 KEY_4 0xeb06 KEY_5 0xeb07 KEY_6 0xeb08 KEY_7 0xeb09 KEY_8 0xeb0a KEY_9 0xeb0b KEY_VIDEO 0xeb0c KEY_0 0xeb0d KEY_REFRESH 0xeb0f KEY_EPG 0xeb10 KEY_UP 0xeb11 KEY_LEFT 0xeb12 KEY_OK 0xeb13 KEY_RIGHT 0xeb14 KEY_DOWN 0xeb16 KEY_INFO 0xeb17 KEY_RED 0xeb18 KEY_GREEN 0xeb19 KEY_YELLOW 0xeb1a KEY_BLUE 0xeb1b KEY_CHANNELUP 0xeb1c KEY_VOLUMEUP 0xeb1d KEY_MUTE 0xeb1e KEY_VOLUMEDOWN 0xeb1f KEY_CHANNELDOWN 0xeb40 KEY_PAUSE 0xeb41 KEY_HOME 0xeb42 KEY_MENU 0xeb43 KEY_SUBTITLE 0xeb44 KEY_TEXT 0xeb45 KEY_DELETE 0xeb46 KEY_TV 0xeb47 KEY_DVD 0xeb48 KEY_STOP 0xeb49 KEY_VIDEO 0xeb4a KEY_AUDIO 0xeb4b KEY_SCREEN 0xeb4c KEY_PLAY 0xeb4d KEY_BACK 0xeb4e KEY_REWIND 0xeb4f KEY_FASTFORWARD 0xeb54 KEY_PREVIOUS 0xeb58 KEY_RECORD 0xeb5c KEY_NEXT 0x1e00 KEY_0 0x1e01 KEY_1 0x1e02 KEY_2 0x1e03 KEY_3 0x1e04 KEY_4 0x1e05 KEY_5 0x1e06 KEY_6 0x1e07 KEY_7 0x1e08 KEY_8 0x1e09 KEY_9 0x1e0a KEY_KPASTERISK 0x1e0b KEY_RED 0x1e0c KEY_RADIO 0x1e0d KEY_MENU 0x1e0e KEY_GRAVE 0x1e0f KEY_MUTE 0x1e10 KEY_VOLUMEUP 0x1e11 KEY_VOLUMEDOWN 0x1e12 KEY_CHANNEL 0x1e14 KEY_UP 0x1e15 KEY_DOWN 0x1e16 KEY_LEFT 0x1e17 KEY_RIGHT 0x1e18 KEY_VIDEO 0x1e19 KEY_AUDIO 0x1e1a KEY_MEDIA 0x1e1b KEY_EPG 0x1e1c KEY_TV 0x1e1e KEY_NEXT 0x1e1f KEY_BACK 0x1e20 KEY_CHANNELUP 0x1e21 KEY_CHANNELDOWN 0x1e24 KEY_LAST 0x1e25 KEY_OK 0x1e29 KEY_BLUE 0x1e2e KEY_GREEN 0x1e30 KEY_PAUSE 0x1e32 KEY_REWIND 0x1e34 KEY_FASTFORWARD 0x1e35 KEY_PLAY 0x1e36 KEY_STOP 0x1e37 KEY_RECORD 0x1e38 KEY_YELLOW 0x1e3b KEY_GOTO 0x1e3d KEY_POWER 0x0042 KEY_POWER 0x077c KEY_TUNER 0x0f4e KEY_PRINT 0x0840 KEY_SCREEN 0x0f71 KEY_DOT 0x0743 KEY_0 0x0c41 KEY_1 0x0443 KEY_2 0x0b7f KEY_3 0x0e41 KEY_4 0x0643 KEY_5 0x097f KEY_6 0x0d7e KEY_7 0x057c KEY_8 0x0a40 KEY_9 0x0e4e KEY_CLEAR 0x047c KEY_CHANNEL 0x0f41 KEY_LAST 0x0342 KEY_MUTE 0x064c KEY_RESERVED 0x0172 KEY_SHUFFLE 0x0c4e KEY_PLAYPAUSE 0x0b70 KEY_RECORD 0x037d KEY_VOLUMEUP 0x017d KEY_VOLUMEDOWN 0x0242 KEY_CHANNELUP 0x007d KEY_CHANNELDOWN 0x1d00 KEY_0 0x1d01 KEY_1 0x1d02 KEY_2 0x1d03 KEY_3
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls wrote:
On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
I'm not sure if all the existing hardware for TX currently supports only
raw pulse/code sequencies, but I still think that, even on the Tx case,
it is better to send scancodes to the driver, and let it do the conversion
to raw pulse/code, if the hardware requires pulse/code instead of scancodes.
That seems like a decision which will create a lots of duplicative code
in the kernel. Add it's just busy-work to write such code when a
userspace application in common use already handles the protocols and
sends raw pulses to hardware that expects raw pulses.
I don't see how this would create lots of duplicative code.
However, as we have green field,
I would add the protocol explicitly for each scancode to be transmitted,
like:
struct ir_tx {
enum ir_protocol proto;
u32 scancode;
};
Eventually, we might have a protocol raw and some extra field to allow
passing
a raw pulse/code sequence instead of a scancode.
I think you would have to. 32 bits is really not enough for all
protocols, and it is already partial encoding of information anyway.
If the Tx driver has to break them down into pulses anyway,
Do all Tx drivers need handle pulse by pulse, or there are some that works
only with scancodes?
why not have fields with more meaningful names
mode
toggle
customer code (or system code or address),
information (or command)
According to
http://slycontrol.ru/scr/kb/rc6.htm
the information field could be up to 128 bits.
Seems fine to me.
(Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
kernel.)
Regards,
Andy
Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Gerd Hoffmann kra...@redhat.com writes: Why not? With RC5 remotes applications can get the device address bits for example, which right now are simply get lost in the ir code - keycode conversion step. Right, this in fact makes the input layer interface unusable for many remotes at this time. I think the address (aka group) should be just a part of the key (command) code, IIRC this is what lirc RC5 does (I'm presently using a custom media version of RC5). I know that lircd does matching instead of decoding, which allows to handle unknown encodings. Thats why I think there will always be cases which only lircd will be able to handle (using raw samples). That doesn't make attempts to actually decode the IR samples a useless exercise though ;) Sure. Especially RC5-like protos are simple to decode, and it's very reliable, even with a very unstable remote clock source (such as RC-based = resistor + capacitor). -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/26/2009 04:14 AM, Gerd Hoffmann wrote: On 11/26/09 07:23, Jarod Wilson wrote: Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. lirc predates the input layer IR drivers by years, maybe even the input layer itself. That was my guess, but I didn't have a timeline in front of me. :) The main reason for the input layer IR drivers appearing was lirc not being mainline. A in-kernel driver (bttv in that case) which depends on a out-of-tree subsystem for IR support was simply a pain in the ass for both maintainer (/me back then) and users. At least for IR hardware which allows access to the raw samples it certainly makes sense to support lirc, additional to the current (or improved) input layer support. I'm liking the idea of a hybrid approach, where IR devices can support both lirc and input device interfaces. I think its the most regression-proof for end-users, if done correctly, which is one of my biggest concerns. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that... lircd can handle the input layer as input as well, so you actually can remap things via lircd even for pure input layer drivers. mythtv handling KEY_VOLUMEUP directly would be more elegant though. Yeah, no, I know lircd can attach to an input device. But even if you do that, you have to have a mapping that converts KEY_VOLUMEUP as captured by lircd into (iirc) right-bracket (]) for mythtv to actually consume it. Directly handling definitely needs to be added to mythtv. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote: Jarod Wilson wrote: On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: ... I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. There's one gripe I agree with, and that is that its still not plug-n-play. Something where udev auto-loads a sane default remote config for say, mceusb transceivers, and the stock mce remote Just Works would be nice, but auto-config is mostly out the window the second you involve transmitters and universal remotes anyway. For several devices, an udev rule that auto-loads a sane default keymap does work. Of course, this won't cover 100% of the usages, and I lirc is a very good way of covering the holes. But outside of that, I think objections are largely philosophical -- in a nutshell, the kernel has an input layer, remotes are input devices, and lirc doesn't conform to input layer standards. Yes. I think this is mainly the issue. The other issue is how to migrate the existing drivers to a new API without causing regressions. If we decide that IR's that receive raw pulse/code should use the raw input interface, this means that a large task force will be needed to convert the existing drivers to use it. Aversion to regression is definitely a major concern. And why I'm liking the idea of a hybrid approach, at least initially. What do you think of adding lirc at staging while we discuss/improve the API's and lircd support for the input event interface? Do you think this would work? Sure, I don't see why not. And I've got another dozen or so drivers to follow those first three... :) -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov dmitry.torok...@gmail.com writes: In what way the key interface is unsufficient for delivering button events? At present: 128 different keys only (RC5: one group). One remote per device only. The protocol itself doesn't have the above limitations, but has others, with are acceptable for key input. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson wrote: On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote: Jarod Wilson wrote: On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: ... I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. There's one gripe I agree with, and that is that its still not plug-n-play. Something where udev auto-loads a sane default remote config for say, mceusb transceivers, and the stock mce remote Just Works would be nice, but auto-config is mostly out the window the second you involve transmitters and universal remotes anyway. For several devices, an udev rule that auto-loads a sane default keymap does work. Of course, this won't cover 100% of the usages, and I lirc is a very good way of covering the holes. But outside of that, I think objections are largely philosophical -- in a nutshell, the kernel has an input layer, remotes are input devices, and lirc doesn't conform to input layer standards. Yes. I think this is mainly the issue. The other issue is how to migrate the existing drivers to a new API without causing regressions. If we decide that IR's that receive raw pulse/code should use the raw input interface, this means that a large task force will be needed to convert the existing drivers to use it. Aversion to regression is definitely a major concern. And why I'm liking the idea of a hybrid approach, at least initially. Yes. This indeed seems to be a very good idea. What do you think of adding lirc at staging while we discuss/improve the API's and lircd support for the input event interface? Do you think this would work? Sure, I don't see why not. And I've got another dozen or so drivers to follow those first three... :) Ok. As you said you'll do some work at the patches, could you please send us v3 in order to add it into drivers/staging? In the case of the API header file, I would tag at the header file that the API is experimental, so can be changed without prior announcements, etc (in order to avoid people to use and rely on it it outside lirc). IMO, the better is to keep such announcement there while we're still working at the hybrid approach, as we may need to change something during the development phase. Dmitry, While lirc is basically a series of input drivers, considering that they have lots in common with the input drivers at V4L/DVB and that we'll need to work on some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from my trees? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: In what way the key interface is unsufficient for delivering button events? At present: 128 different keys only (RC5: one group). One remote per device only. The protocol itself doesn't have the above limitations, but has others, with are acceptable for key input. This is not a limit at the input subsystem. It were a design decision for some drivers at the V4L subsystem that we need to change. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: 1) the developer that adds the hardware also adds the IR code. He has the hardware and the IR for testing, so it means a faster development cycle than waiting for someone else with the same hardware and IR to recode it on some other place. You should remember that not all developers use lirc; It's fine, but please - no keymaps in the kernel (except for fixed receivers, i.e. the ones which can only work with their own dedicated remote, and which don't pass RC5/etc. code). The existing keymaps (those which can be used with lirc) have to be moved to userspace as well. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: Technically, it is not hard to port this solution to the other drivers, but the issue is that we don't have all those IR's to know what is the complete scancode that each key produces. So, the hardest part is to find a way for doing it without causing regressions, and to find a group of people that will help testing the new way. We don't want to port it to other drivers. We need to have a common module which does all RCx decoding. The individual drivers should be as simple as possible, something that I outlined in a previous mail. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: 1) the developer that adds the hardware also adds the IR code. He has the hardware and the IR for testing, so it means a faster development cycle than waiting for someone else with the same hardware and IR to recode it on some other place. You should remember that not all developers use lirc; It's fine, but please - no keymaps in the kernel (except for fixed receivers, i.e. the ones which can only work with their own dedicated remote, and which don't pass RC5/etc. code). The existing keymaps (those which can be used with lirc) have to be moved to userspace as well. The removal of the existing keymaps from kernel depends on having an application to be called from udev to load the proper keymaps when a device is probed. After having it for a while, we should deprecate the in-kernel keymaps and move them to userspace. I also think that it is important to remove the 7 bits limitation from all drivers and re-generate the keymaps, since they'll change after it. cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Technically, it is not hard to port this solution to the other drivers, but the issue is that we don't have all those IR's to know what is the complete scancode that each key produces. So, the hardest part is to find a way for doing it without causing regressions, and to find a group of people that will help testing the new way. We don't want to port it to other drivers. We need to have a common module which does all RCx decoding. The individual drivers should be as simple as possible, something that I outlined in a previous mail. With the current 7bits mask applied to almost all devices, it is probably not very useful for those who want to use generic IRs. We really need to port the solution we've done on dvb-usb to the other drivers, allowing them to have the entire scancode at the tables while keep supporting table replacement. The issue is that we currently have only 7bits of the scan codes produced by the IR's. So, we need to re-generate the keycode tables for each IR after the changes got applied. With respect to a common module, unfortunately most of the work should be done on each driver, since the code that communicates with the hardware is specific to each device. There is a common code (at ir-common.ko) with helper decoding routines. Please feel free to send us contributions to improve the current code. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote:
Mauro Carvalho Chehab mche...@redhat.com writes:
The issue I see is to support at the same time NEC and RC5 protocols. While
this may work with some devices, for others, the hardware won't allow.
Sure. We can handle it for the simple devices at least.
I think the mapping should be: key = proto + group + raw code, while
key2 could be different_proto + different group (if any) + another code.
This may work for protocols up to RC5, that uses either 8 or 16 bits.
However, RC6 mode 6 codes can be 32 bits, and we have only 32 bits
for a scancode. So, we don't have spare bits to represent a protocol,
if we consider RC6 mode 6 codes as well.
I don't see this limitation. The number of bits should depend on the
protocol.
see include/linux/input.h:
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
extending the value to more than 32 bits require some changes at the input
layer,
probably breaking kernel API.
See above. Also, several protocols have a way to check if a keystroke were
properly received. When handling just one protocol, we can use this to double
check the key. However, on a multiprotocol mode, we'll need to disable this
feature.
I don't think so. We can pass the space/mark data to all (configured,
i.e. with active mapping) protocol handlers at once. Should a check
fail, we ignore the data. Perhaps another protocol will make some sense
out of it.
What happens if it succeeds on two protocol handlers?
Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Andy Walls awa...@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. I don't know for sure what Microsoft claims to be licensing. I think it is the protocol itself: http://www.microsoft.com/presspass/Press/2002/Apr02/04-16FreestylePhilipsPR.mspx Under the terms of the agreement, Microsoft and Philips will license to OEMs an IR protocol based on Philips proprietary RC6 IR technology. The patented and globally adopted solution minimizes interference from other remote-control devices in the household. Use of this established protocol will help ensure uniform development of Windows infrared remote-control products, which include infrared remote-control units and remote-control receivers... http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt See Slide 5, which has the bullet: How to License RC6 Since the content of the information field in RC-6 Mode 6A is left up to OEMs, I would not be surprised by bogus innovations in OEM patents about RC-6 Mode 6A contents. I would not be at all surprised by something like a bit to indicate a toggled remote key press in the information field since RC-6's T bits for mode 6 indicate Mode 6A or Mode 6B and not toggles. 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. Regards, Andy Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Mauro, on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote: [...] lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse codes. Nonsense! There's no generation of artificial pulse codes in the drivers. The LIRC interface includes ways to pass decoded IR codes of arbitrary length to userspace. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Christoph Bartelmus wrote: Hi Mauro, on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote: [...] lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse codes. Nonsense! There's no generation of artificial pulse codes in the drivers. The LIRC interface includes ways to pass decoded IR codes of arbitrary length to userspace. I might have got wrong then a comment in the middle of the imon_incoming_packet() of the SoundGraph iMON IR patch: + /* +* Translate received data to pulse and space lengths. +* Received data is active low, i.e. pulses are 0 and +* spaces are 1. +* +* My original algorithm was essentially similar to +* Changwoo Ryu's with the exception that he switched +* the incoming bits to active high and also fed an +* initial space to LIRC at the start of a new sequence +* if the previous bit was a pulse. +* +* I've decided to adopt his algorithm. +*/ Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa k...@pm.waw.pl wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: In what way the key interface is unsufficient for delivering button events? At present: 128 different keys only (RC5: one group). Where did this limitation come from? We have more than 256 keycodes already _defined_ in the input core and we can add more if needed. One remote per device only. Why would you want more? One physical device usually corresponds to a logical device. If you have 2 remotes create 2 devices. The protocol itself doesn't have the above limitations, but has others, with are acceptable for key input. -- Krzysztof Halasa -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Mauro, on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: [...] lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse codes. Nonsense! There's no generation of artificial pulse codes in the drivers. The LIRC interface includes ways to pass decoded IR codes of arbitrary length to userspace. I might have got wrong then a comment in the middle of the imon_incoming_packet() of the SoundGraph iMON IR patch: Indeed, you got it wrong. As I already explained before, this device samples the signal at a constant rate and delivers the current level in a bit-array. This data is then condensed to pulse/space data. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote: See above. Also, several protocols have a way to check if a keystroke were properly received. When handling just one protocol, we can use this to double check the key. However, on a multiprotocol mode, we'll need to disable this feature. I don't think so. We can pass the space/mark data to all (configured, i.e. with active mapping) protocol handlers at once. Should a check fail, we ignore the data. Perhaps another protocol will make some sense out of it. What happens if it succeeds on two protocol handlers? Then you use the protocol that fits best. For instance decoding with one protocol might produce a scancode that isn't assigned to any key, while another protocol produces an assigned scancode. Clearly then the latter is most likely to be correct. It also possible to have a space/mark length that is within the allowable tolerances for one remote, but is even closer another remote. You don't want to just find *a* match, you want to find the *best* match. The in kernel code in v4l is very simple in that it is only designed to work with one procotol and one remote. Once you have multiple remotes of any type things become much more complicted. Keep in mind that remotes that aren't even intended to be used with the computer but are used in the same room will still be received by the receiver. It's not enough to decode the signals you expect to receive, you must also not get confused by random signals destined for somewhere else. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote: lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse codes. Nonsense! There's no generation of artificial pulse codes in the drivers. The LIRC interface includes ways to pass decoded IR codes of arbitrary length to userspace. I might have got wrong then a comment in the middle of the imon_incoming_packet() of the SoundGraph iMON IR patch: + /* + * Translate received data to pulse and space lengths. + * Received data is active low, i.e. pulses are 0 and + * spaces are 1. I'm not sure about this specific code, but what is likely going on here is the waveform is being RLE encoding. For example, a cx88 receiver has two ways of being connected (without using an external decoder chip). One generates an IRQ on each edge of the signal. The time between IRQs gives mark/space lengths which is what lirc expects. This is how a simple serial port receiver works too. Another connections effectivly samples the waveform one bit deep at IIRC 4kHz. I think that's what the code you are looking at gets. The code extracts the edges from the waveform and returns the time between them. In effect one is run length encoding a sequence of bits. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehabmche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. Right, but still the keys usually do have the well-defined meaning, Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean. I guess we are talking about different things. While the 2 remotes may use different protocols to communicate and may use the same codes to mean different things they buttons have well-defined meaning and we could map that to input keycodes. Then what is left is to load the proper mapping for particular device into the kernel. This can be done either automatically (when we know the mapping) or with the help of the user (owner of the system). teh issue is in mapping raw code to the appropriate keycode. This can be done either by lirc config file (when lirc is used) or by some other means. The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too. No, at present we expect 1:1 button-event mapping leaving macro expansion (i.e. KEY_PROG1 - do some multi-step sequence to userspace). -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Wed, Nov 25, 2009 at 10:58:29PM +0100, Gerd Hoffmann wrote: (1) ir code (say rc5) - keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event-type = EV_IR input_event-code = IR_RC5 input_event-value = rc5 value In case the 32bit value is too small we might want send two events instead, with -code being set to IR_code_1 and IR_code_2 Advantages: * Applications (including lircd) can get access to the unmodified rc5/rc6/... codes. * All the ir-code - keycode mapping magic can be handled by the core input layer then. All the driver needs to do is to pass on the information which keymap should be loaded by default (for the bundled remote if any). The configuration can happen in userspace (sysfs attribute + udev + small utility in tools/ir/). * lirc drivers which get ir codes from the hardware can be converted to pure input layer drivers without regressions. lircd is not required any more. I think we need to separate 2 kinds of applications since they have different requirements as far as interface goes: 1. Reguilar user-space applications interested in receiving keystrokes from user and reacting to them. Movie players, CD players, MythTV-like applications and so on. Those, to my understanding, are not concerned with the fine details of RC5, RC6, NEC and so forth protocol decoding and just want to know when to start playing, when to stop and when to revind. That class of applications is best served by current input layer since it unifies data coming from IR, keyboards, button devices and so forth. 2. System applications that are interested in protocol decoding. Those need interface best suited for IR and nothing else. This protocol is appears is better kept separate from the evdev input protocol. In case where we rely solely on such userspace application(s) to perform protocol decoding we should route input events back to kernel through uinput for consumption by class 1 applications. We use this approach for PS/2 (serio allows binding either psmouse/atkbd or serio_raw to provide alternate interfaces depending on the users need), USB hid allows raw access as well, maybe we should follow the suit here. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote: Dmitry, While lirc is basically a series of input drivers, considering that they have lots in common with the input drivers at V4L/DVB and that we'll need to work on some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from my trees? Mauro, I would not mind if you will be pushing it to staging, however I am not sure we have an agreement on what exactly the interface that we will be using. I would hate to get something in that will need to be reworked again. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov dmitry.torok...@gmail.com writes: One remote per device only. Why would you want more? One physical device usually corresponds to a logical device. If you have 2 remotes create 2 devices. I meant per receiver device. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: Why do you want to replace everything into a single shot? Why not? It seems simpler to me. We need to change this anyway. If we change the whole table in a single ioctl, we can easily enumerate protocols requested and enable then selectively. But I think it's a minor implementation decision and we don't need to look at it at this time. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: One remote per device only. Why would you want more? One physical device usually corresponds to a logical device. If you have 2 remotes create 2 devices. I meant per receiver device. There is nothing in input layer that precludes you from creating multiple input devices per *whatever*. Please, when you are talking about limitations, specify whether those limitations are applicable to the input layer, the current implementation of IR in DVB or something else. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Why do you want to replace everything into a single shot? Why not? It seems simpler to me. We need to change this anyway. ioctls with a variable argument length are a pain for 32 bit emulation and stuff like strace. You either need to encode the variable length into the ioctl cmd, making it variable as well, or use a pointer in the data structure, which requires conversion. Ideally, ioctl arguments have a constant layout, no pointers and are at most 64 bits long. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov dmitry.torok...@gmail.com writes: There is nothing in input layer that precludes you from creating multiple input devices per *whatever*. Of course. I though it was obvious I mean present situation with the media drivers but I can see now it was far from being obvious. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Trent Piepho xy...@speakeasy.org writes: Then you use the protocol that fits best. For instance decoding with one protocol might produce a scancode that isn't assigned to any key, while another protocol produces an assigned scancode. Clearly then the latter is most likely to be correct. Right. It also possible to have a space/mark length that is within the allowable tolerances for one remote, but is even closer another remote. You don't want to just find *a* match, you want to find the *best* match. That won't work, the decoders don't calculate quality. And even if they did, if you have two remotes generating the same e.g. RC5 code, you won't be able to differentiate between them. Your TV etc. won't do that either. The in kernel code in v4l is very simple in that it is only designed to work with one procotol and one remote. Once you have multiple remotes of any type things become much more complicted. If you're using them at once, sure :-) Keep in mind that remotes that aren't even intended to be used with the computer but are used in the same room will still be received by the receiver. It's not enough to decode the signals you expect to receive, you must also not get confused by random signals destined for somewhere else. This is usually not a problem. My experience is the decoding is very reliable. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov wrote: On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote: Dmitry, While lirc is basically a series of input drivers, considering that they have lots in common with the input drivers at V4L/DVB and that we'll need to work on some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from my trees? Mauro, I would not mind if you will be pushing it to staging, however I am not sure we have an agreement on what exactly the interface that we will be using. I would hate to get something in that will need to be reworked again. I understand your concerns. IMHO, we should be really careful with API's when migrating from staging to the right place, but I'm not that much concerned with staging. We already have several drivers there with bad behaviors and even with some API's there that will go to /dev/null. For example there's a V4L2 driver there (staging/go7007) that has their own private API to handle compressed streams. I won't ack moving it from staging while it has their own private extensions for something that are part of V4L2 API. Also, staging drivers without progress for a few kernel cycles will be moved to /dev/null, so I don't see much sense of denying a driver to go there. Anyway, I'll add it there only when you feel comfortable about that and send us your ack. - From what I heard on the comments, I think we have already a consensus of some points: 1) all IR's should implement the standard evdev interface; 2) IR's with raw interfaces will implement a raw pulse/space IR interface. The proposal is to use lirc API interface for raw pulse/code TX and RX. Do you think we'll need to better detail the IR raw interface API before accepting the patches for staging? If so, what level of details do you want? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/26/2009 06:23 PM, Dmitry Torokhov wrote: On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehabmche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. Right, but still the keys usually do have the well-defined meaning, Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean. I guess we are talking about different things. While the 2 remotes may use different protocols to communicate The remotes use the exact same protocol. Their respective bundled receivers however, do translate key presses differently. Perhaps this is a bad example though, because both of these remotes came with receivers that do onboard decoding. But there's nothing stopping me from wanting to use either of these remotes with an mceusb IR transceiver. and may use the same codes to mean different things they buttons have well-defined meaning and we could map that to input keycodes. Then what is left is to load the proper mapping for particular device into the kernel. In this case, its not the device, but the remote, that we need a different mapping for. This can be done either automatically (when we know the mapping) or with the help of the user (owner of the system). Yep, that'd work. Just trying to illustrate that the same code doesn't always mean anywhere near the same thing from one remote to another. teh issue is in mapping raw code to the appropriate keycode. This can be done either by lirc config file (when lirc is used) or by some other means. The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too. No, at present we expect 1:1 button-event mapping leaving macro expansion (i.e. KEY_PROG1 - do some multi-step sequence to userspace). Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow. Bummer. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Am Donnerstag, den 26.11.2009, 14:59 -0800 schrieb Trent Piepho: On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote: See above. Also, several protocols have a way to check if a keystroke were properly received. When handling just one protocol, we can use this to double check the key. However, on a multiprotocol mode, we'll need to disable this feature. I don't think so. We can pass the space/mark data to all (configured, i.e. with active mapping) protocol handlers at once. Should a check fail, we ignore the data. Perhaps another protocol will make some sense out of it. What happens if it succeeds on two protocol handlers? Then you use the protocol that fits best. For instance decoding with one protocol might produce a scancode that isn't assigned to any key, while another protocol produces an assigned scancode. Clearly then the latter is most likely to be correct. It also possible to have a space/mark length that is within the allowable tolerances for one remote, but is even closer another remote. You don't want to just find *a* match, you want to find the *best* match. The in kernel code in v4l is very simple in that it is only designed to work with one procotol and one remote. Once you have multiple remotes of any type things become much more complicted. Keep in mind that remotes that aren't even intended to be used with the computer but are used in the same room will still be received by the receiver. It's not enough to decode the signals you expect to receive, you must also not get confused by random signals destined for somewhere else. Giving some random living room these days, likely open to the kids rooms, you have to take that into account. Another point, if decoding from IRQs generated by the remote, there is flawed hardware around, needing to poll IRQs in some timely manner to get it to something at all. This will break such remotes. Never seen? For me the first priority is, that existing remotes are not broken. Don't tell you have done a nice job just now, but are unfortunately in need of testers ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com wrote: No, at present we expect 1:1 button-event mapping leaving macro expansion (i.e. KEY_PROG1 - do some multi-step sequence to userspace). Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow. Bummer. That is scripting. Scripting always needs to be done in user space. 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. The configfs model is very flexible. You could make a remote that translates the UP/DOWN buttons of several different remotes into KEY_UP/DOWN. That lets several different remotes control the same app. Sure it is clunky to play with IR hex codes and keycodes in the configfs mapping dir. If you don't like it write a GUI app for manipulating the codes. GUI would then generate a script for udev to run which builds the configfs entries. Maybe I should rename those directory entries to app instead of remote. They contain the mappings from IR hex codes to keycodes that an app is interested in. Usually there is a 1:1 correspondence between remote and app but there doesn't have to be. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 09:28:51PM -0500, Jarod Wilson wrote: On 11/26/2009 06:23 PM, Dmitry Torokhov wrote: On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehabmche...@redhat.com writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized keyfunction mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. Right, but still the keys usually do have the well-defined meaning, Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean. I guess we are talking about different things. While the 2 remotes may use different protocols to communicate The remotes use the exact same protocol. Their respective bundled receivers however, do translate key presses differently. Perhaps this is a bad example though, because both of these remotes came with receivers that do onboard decoding. But there's nothing stopping me from wanting to use either of these remotes with an mceusb IR transceiver. and may use the same codes to mean different things they buttons have well-defined meaning and we could map that to input keycodes. Then what is left is to load the proper mapping for particular device into the kernel. In this case, its not the device, but the remote, that we need a different mapping for. I would say that the remote is the device, not the receiver... This can be done either automatically (when we know the mapping) or with the help of the user (owner of the system). Yep, that'd work. Just trying to illustrate that the same code doesn't always mean anywhere near the same thing from one remote to another. We have the same scenatio with atkbd and various laptops - the extended keys may use the same scancodes for different keys and we use DMI data to load the proper keymap. Obviously in case if IRC we won't be using DMI but something else. teh issue is in mapping raw code to the appropriate keycode. This can be done either by lirc config file (when lirc is used) or by some other means. The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too. No, at present we expect 1:1 button-event mapping leaving macro expansion (i.e. KEY_PROG1 - do some multi-step sequence to userspace). Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow. Bummer. What is Ctrl-x? Alt-tab? This are application-specific binding and of course kernel does not emit these. If there is a distinct action that needs to be signalled then there [normally] is a keycode for it. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote: On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com wrote: No, at present we expect 1:1 button-event mapping leaving macro expansion (i.e. KEY_PROG1 - do some multi-step sequence to userspace). Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow. Bummer. That is scripting. Scripting always needs to be done in user space. 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. The configfs model is very flexible. You could make a remote that translates the UP/DOWN buttons of several different remotes into KEY_UP/DOWN. That lets several different remotes control the same app. Sure it is clunky to play with IR hex codes and keycodes in the configfs mapping dir. If you don't like it write a GUI app for manipulating the codes. GUI would then generate a script for udev to run which builds the configfs entries. Maybe I should rename those directory entries to app instead of remote. They contain the mappings from IR hex codes to keycodes that an app is interested in. Usually there is a 1:1 correspondence between remote and app but there doesn't have to be. 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. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov dmitry.torok...@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? -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Jon, on 27 Nov 09 at 00:06, Jon Smirl wrote: [...] 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. Can you elaborate on this? I'm not aware of any issue with Sony remotes. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi Mauro, on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: [...] But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just because I'm not familiar at all with input layer toolset. [...] I hope it helps for you to better understand how this works. So the plan is to have two ways of using IR in the future which are incompatible to each other, the feature-set of one being a subset of the other? When designing the key mapping in the kernel you should be aware that there are remotes out there that send a sequence of scan codes for some buttons, e.g. http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159 Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls awa...@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. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson ja...@wilsonet.com writes: The bulk of breakage in lirc I've personally had to deal with has mostly come in the form of kernel interface changes, which would definitely be mitigated by not having to maintain the drivers out-of-tree any longer. Certainly. Now, I'm all for improving things and integrating better with the input subsystem, but what I don't really want to do is break compatibility with the existing setups on thousands (and thousands?) of MythTV boxes around the globe. The lirc userspace can be pretty nimble. If we can come up with a shiny new way that raw IR can be passed out through an input device, I'm pretty sure lirc userspace can be adapted to handle that. Lirc can already handle input layer. Since both ways require userspace changes, why not do it the right way the first time? Most of the code is already written. If a new input-layer-based transmit interface is developed, we can take advantage of that too. But there's already a very mature lirc interface for doing all of this. So why not start with adding things more or less as they exist right now and evolve the drivers into an idealized form? Getting *something* into the kernel in the first place is a huge step in that direction. What I see as potentially problematic is breaking compatibility multiple times. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Hi, on 25 Nov 09 at 17:53, Krzysztof Halasa wrote: Jarod Wilson ja...@wilsonet.com writes: [...] nimble. If we can come up with a shiny new way that raw IR can be passed out through an input device, I'm pretty sure lirc userspace can be adapted to handle that. As Trent already pointed out, adding support for raw IR through an input device would require a new interface too. You just put the label input device on it. This does not make much sense for me. Lirc can already handle input layer. Since both ways require userspace changes, I'm not sure what two ways you are talking about. With the patches posted by Jarod, nothing has to be changed in userspace. Everything works, no code needs to be written and tested, everybody is happy. We had exactly the same discussion around one year ago. I've seen no new arguements in the current discussion and nobody came up with this shiny new way of integrating LIRC into the input layer since last year. Maybe it's about time to just accept that the LIRC interface is the way to go. Can we finally get the patch integrated, please? Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 25, 2009, at 11:53 AM, Krzysztof Halasa wrote: Jarod Wilson ja...@wilsonet.com writes: ... Now, I'm all for improving things and integrating better with the input subsystem, but what I don't really want to do is break compatibility with the existing setups on thousands (and thousands?) of MythTV boxes around the globe. The lirc userspace can be pretty nimble. If we can come up with a shiny new way that raw IR can be passed out through an input device, I'm pretty sure lirc userspace can be adapted to handle that. Lirc can already handle input layer. Since both ways require userspace changes, why not do it the right way the first time? Most of the code is already written. There's obviously still some debate as to what the right way is. :) And the matter of someone having the time to write the rest of the code that would be needed. If a new input-layer-based transmit interface is developed, we can take advantage of that too. But there's already a very mature lirc interface for doing all of this. So why not start with adding things more or less as they exist right now and evolve the drivers into an idealized form? Getting *something* into the kernel in the first place is a huge step in that direction. What I see as potentially problematic is breaking compatibility multiple times. Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: 1) bring drivers in in their current state - users keep using lirc as they always have 2) add in-kernel decoding infra that feeds input layer 3) add option to use in-kernel decoding to existing lirc drivers - users can keep using lirc as they always have - users can optionally try out in-kernel decoding via a modparam 4) switch the default mode from lirc decode to kernel decode for each lirc driver - modparam can be used to continue using lirc interface instead 5) assuming users aren't coming at us with pitchforks, because things don't actually work reliably with in-kernel decoding, deprecate the lirc interface in driver 6) remove lirc interface from driver, its now a pure input device This would all be on a per-lirc-driver basis, and if/when all decoding could be reliably done in-kernel, and/or there was a way other than the lirc interface to pass raw IR signals out to userspace, the lirc interface could be removed entirely. And we still need to consider IR transmitters as well. Those are handled quite well through the lirc interface, and I've not seen any concrete code (or even fully fleshed out ideas) on how IR transmit could be handled in this in-kernel decoding world. [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight. ;) -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I'm not sure what two ways you are talking about. With the patches posted by Jarod, nothing has to be changed in userspace. Everything works, no code needs to be written and tested, everybody is happy. The existing drivers use input layer. Do you want part of the tree to use existing lirc interface while the other part uses their own in-kernel (badly broken for example) code to do precisely the same thing? Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. We can have a good code for both, or we can end up with badly broken media drivers and incompatible, suboptimal existing lirc interface (though most probably much better in terms of quality, especially after Jarod's work). Well, is there any reason most of those drivers with currently-in-kernel-but-badly-broken decoding can't be converted to use the lirc interface if its merged into the kernel? And/or, everything could converge on a new in-kernel decoding infra that wasn't badly broken. Sure, there may be two separate ways of doing essentially the same thing for a while, but meh. The lirc way works NOW for an incredibly wide variety of receivers, transmitters, IR protocols, etc. I do concur that Just Works decoding for bundled remotes w/o having to configure anything would be nice, and one way to go about doing that certainly is via in-kernel IR decoding. But at the same time, the second you want to use something other than a bundled remote, things fall down, and having to do a bunch of setkeycode ops seems less optimal than simply dropping an appropriate lircd.conf in place. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson ja...@wilsonet.com wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. This is one of the key use cases I would be very concerned with. For many users who have bought tuner products, the bundled remotes work out-of-the-box, regardless of whether lircd is installed. I have no objection so much as to saying well, you have to install the lircd service now, but there needs to be a way for the driver to automatically tell lirc what the default remote control should be, to avoid a regression in functionality. We cannot go from a mode where it worked automatically to a mode where now inexperienced users now have to deal with the guts of getting lircd properly configured. If such an interface were available, I would see to it that at least all the devices I have added RC support for will continue to work (converting the in-kernel RC profiles to lirc RC profiles as needed and doing the associations with the driver). The other key thing I don't think we have given much thought to is the fact that in many tuners, the hardware does RC decoding and just returns NEC/RC5/RC6 codes. And in many of those cases, the hardware has to be configured to know what format to receive. We probably need some kernel API such that the hardware can tell lirc what formats are supported, and another API call to tell the hardware which mode to operate in. This is why I think we really should put together a list of use cases, so that we can see how any given proposal addresses those use cases. I offered to do such, but nobody seemed really interested in this. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson ja...@wilsonet.com writes: Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: 1) bring drivers in in their current state - users keep using lirc as they always have 2) add in-kernel decoding infra that feeds input layer Well. I think the above is fine enough. 3) add option to use in-kernel decoding to existing lirc drivers - users can keep using lirc as they always have - users can optionally try out in-kernel decoding via a modparam 4) switch the default mode from lirc decode to kernel decode for each lirc driver - modparam can be used to continue using lirc interface instead 5) assuming users aren't coming at us with pitchforks, because things don't actually work reliably with in-kernel decoding, deprecate the lirc interface in driver 6) remove lirc interface from driver, its now a pure input device But 3-6 are IMHO not useful. We don't need lirc _or_ input. We need both at the same time: input for the general, simple case and for consistency with receivers decoding in firmware/hardware; input for special cases such as mapping the keys, protocols not supported by the kernel and so on (also for in-tree media drivers where applicable). [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight. ;) I think: in-kernel decoding only as the general, primary means. Not the only one. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jarod Wilson ja...@wilsonet.com writes: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Yes. Well, is there any reason most of those drivers with currently-in-kernel-but-badly-broken decoding can't be converted to use the lirc interface if its merged into the kernel? For many of them lirc mode can be easily _added_. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Devin Heitmueller dheitmuel...@kernellabs.com writes: The other key thing I don't think we have given much thought to is the fact that in many tuners, the hardware does RC decoding and just returns NEC/RC5/RC6 codes. And in many of those cases, the hardware has to be configured to know what format to receive. We probably need some kernel API such that the hardware can tell lirc what formats are supported, and another API call to tell the hardware which mode to operate in. For such cases, I wouldn't bother with lirc mode. Input layer + key mapping with ioctl (probably improved), and lircd can grab events from input layer if needed. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
