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

Christoph Bartelmus
2009-11-28T16:48:22Z

Hi Krzysztof and Maxim,

on 28 Nov 09 at 16:44, Krzysztof Halasa wrote:
> Maxim Levitsky <maximlevitsky@gmail.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