| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: 29 Nov 2009 12:07:00 +0100 From: lirc@...telmus.de (Christoph Bartelmus) To: khc@...waw.pl Cc: superm1@...ntu.com Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? Hi Krzysztof, on 28 Nov 09 at 18:21, Krzysztof Halasa wrote: [...] >> 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. Ah, sorry. I didn't mean the extension of the command code by inverting one of the start bits. The Streamzap really uses one more bit. In the LIRC world the RC5 start bit which is fixed to "1" is not counted as individual bit. So translated to your notation, the Streamzap uses 15 bits, not 14 like the extended RC-5 or 13 like the original RC-5... Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists