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: <BDkdITRHqgB@lirc>
Date:	28 Nov 2009 17:47: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 and Maxim,

on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
> Maxim Levitsky <maximlevitsky@...il.com> writes:

>> Generic decoder that lirc has is actually much better and more tolerant
>> that protocol specific decoders that you propose,

> Actually, it is not the case. Why do you think it's better (let alone
> "much better")? Have you at least seen my RC5 decoder?

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:

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, 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.

@Maxim: I think Mauro is right. We need to find an approach that makes  
everybody happy. We should take the time now to discuss all the  
possibilities and choose the best solution. LIRC has lived so long outside  
the kernel, that we can wait another couple of weeks/months until we  
agreed on something which will be a stable API hopefully for many years to  
come.

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/