Another approach to IR
in [Kernel]
|
From: Krzysztof Halasa on 3 Dec 2009 13:10 Jarod Wilson <jarod(a)wilsonet.com> writes: > Perhaps we should clarify something here. Are we intending to > auto-create a new input device for every IR command set we see arrive > at the IR receiver? We don't want this, and we aren't really able to do this, because we never know if two different scan codes are part of the same or different command set. Sharing the protocol and e.g. group code doesn't mean it's the same remote. Different protocol doesn't mean it's a different remote and what's more important, doesn't mean the user wants it to be a different logical remote. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Emmanuel Fusté on 3 Dec 2009 13:10 > > On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: > > Ferenc Wagner wrote: > > > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > > > > We should not forget that simple IR's don't have any key to select the address, > > so the produced codes there will never have KEY_TV/KEY_DVD, etc. > > Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select > media inputs in a device/application. My receiver accepts codees like > that. > Yes, it seem that there is confusion here. Forget my proposition. It is a corner case that could be handled later if needed. Cheers, Emmanuel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on 3 Dec 2009 13:20 Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > Btw, looking at that code, while it is not impossible to split the > IR pulse/space measures from the NEC decoder itself, and make it generic > to support other protocols, it is not a trivial task, and may result on > a less stable driver. And it's not needed at all. Protocol decoders can be easily run in parallel, I've done it on saa713x and this is trivial at least there. Can do that when the lirc interface is available. > The advantage of the NEC decoding approach on saa7134 is that you know for > sure how much time it is required to get the entire code. So, the code > can easily abort the reception of a bad code. The disadvantage is that > only one protocol can be decoded at the same time. This isn't a hard thing to fix. > The same problem also happens with almost all in-kernel drivers: the decoders > for raw mode were constructed to work with just one pulse/space code at the > same time. A conversion into a generic code can happen, but it will require > several tests to be sure that they won't cause undesirable side-effects. IOW any such receiver has to be tested, sure. > The advantage of hardware decoders is that you don't need to be polling the > IR serial port at a high rate, as you'll get directly the code. So, you'll > free the CPU to do something else. Which device requires polling the port? Most are IRQ-driven, aren't they? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: alhaz on 3 Dec 2009 14:50 Quoting Jon Smirl <jonsmirl(a)gmail.com>: >>> Now I understand that if 2 remotes send completely identical signals we >>> won't be able to separate them, but in cases when we can I think we >>> should. >> >> I don't have a problem with that, if its a truly desired feature. >> But for the most part, I don't see the point. Generally, you go >> from having multiple remotes, one per device (where "device" is >> your TV, amplifier, set top box, htpc, etc), to having a single >> universal remote that controls all of those devices. But for each >> device (IR receiver), *one* IR command set. The desire to use >> multiple distinct remotes with a single IR receiver doesn't make >> sense to me. Perhaps I'm just not creative enough in my use of IR. :) From a hobbiest's perspective there's likely rarely any reason to be able to do the same thing with two different remotes that send different signals, but i could see it come up - For example if you wanted to have both a feature-rich, busy/complicated remote but also wanted to provide a simpler remote with a relatively small number of large buttons on it for basic functions, as for children or people with poor eyesight or poor motor control. From a business perspective, I've worked for a company that sold turn-key video training systems, and depending on the whims of our so-called business partners and the desires of customers, there were as many as three distinct remotes that might get shipped with the training system, and they all sent different signals. That was a less than ideal situation, and if we had been really on top of things we'd have just declined to use any of those remotes and bought custom remotes from any of the numerous vendors that sell them which would allow us to have one set of IR signals used by remotes with different features - but for whatever reason that wasn't how management decided to do things. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 3 Dec 2009 16:00
Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > >> Btw, looking at that code, while it is not impossible to split the >> IR pulse/space measures from the NEC decoder itself, and make it generic >> to support other protocols, it is not a trivial task, and may result on >> a less stable driver. > > And it's not needed at all. > Protocol decoders can be easily run in parallel, I've done it on saa713x > and this is trivial at least there. Can do that when the lirc interface > is available. >> The advantage of the NEC decoding approach on saa7134 is that you know for >> sure how much time it is required to get the entire code. So, the code >> can easily abort the reception of a bad code. The disadvantage is that >> only one protocol can be decoded at the same time. > > This isn't a hard thing to fix. Good to know. We're open to patches to improve it. The point is that we've got in the past several complains about saa713x machines hanging due to IRQ's generated by IR sensor port. We ended by adding an option to disable IR and a code at the driver that disables IR IRQ if it happens too often. > >> The same problem also happens with almost all in-kernel drivers: the decoders >> for raw mode were constructed to work with just one pulse/space code at the >> same time. A conversion into a generic code can happen, but it will require >> several tests to be sure that they won't cause undesirable side-effects. > > IOW any such receiver has to be tested, sure. > >> The advantage of hardware decoders is that you don't need to be polling the >> IR serial port at a high rate, as you'll get directly the code. So, you'll >> free the CPU to do something else. > > Which device requires polling the port? > Most are IRQ-driven, aren't they? Most of the devices that have a hardware IR decodes needs polling. Most of they simply outputs the scan code on some set of GPIO pins. In general, the devices with the IR sensor connected to a GPIO pin are IRQ-driven. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |