lirc@xxxxxxxxxxxx (Christoph Bartelmus) writes: > Nobody here doubts that you can implement a working RC-5 decoder. It's > really easy. I'll give you an example why Maxim thinks that the generic > LIRC approach has advantages: But surely not when compared to an in-kernel decoder _and_ the one in lircd? :-) > Look at the Streamzap remote (I think Jarod submitted the lirc_streamzap > driver in his patchset): > http://lirc.sourceforge.net/remotes/streamzap/PC_Remote > > This remote uses RC-5. But some of the developers must have thought that > it may be a smart idea to use 14 bits instead the standard 13 bits for > this remote. In LIRC you won't care, because this is configurable and > irrecord will figure it out automatically for you. In the proposed kernel > decoders I have seen until now, you will have to treat this case specially > in the decoder because you expect 13 bits for RC-5, not 14. Well, the 14-bit RC5 is de-facto standard for some time now. One of the start bits, inverted, now functions as the MSB of the command code. 13-bit receiver implementations (at least these aimed at "foreign" remotes) are obsolete. > Well, it can be done. But you'll have to add another IR protocol define > for RC-5_14, which will become very ugly with many non-standard protocol > variations. No, the 14-bit version is designed to be backward compatible. -- 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
