linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3einiy389.fsf@intrepid.localdomain>
Date:	Sat, 28 Nov 2009 18:21:42 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	lirc@...telmus.de (Christoph Bartelmus)
Cc:	awalls@...ix.net, dmitry.torokhov@...il.com, j@...nau.net,
	jarod@...hat.com, jarod@...sonet.com, jonsmirl@...il.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, maximlevitsky@...il.com,
	mchehab@...hat.com, stefanr@...6.in-berlin.de, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR 	system?

lirc@...telmus.de (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-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/