Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> 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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
