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

Dmitry Torokhov
2009-12-06T06:55:12Z

Hi,

On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote:
> Hi,
>
> Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
> > On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> > > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
> > > codes. Anyone here has docs on the XMP protocol?
> >
> > Assuming a general purpose receiver (not one with fixed hardware
> > decoding), is it important for Linux to receive IR signals from all
> > possible remotes no matter how old or obscure? Or is it acceptable to
> > tell the user to throw away their dedicated remote and buy a universal
> > multi-function one? Universal multi-function remotes are $12 in my
> > grocery store - I don't even have to go to an electronics store.
>
> finally we have some point here, IMHO, that is not acceptable and I told
> you previously not to bet on such. Start some poll and win it, and I'll
> shut up :)
>

Who would participate in the poll though?

> To be frank, you are quite mad at this point, or deliver working other
> remotes to __all__ for free.
>

I do not believe you are being realistic. Sometimes we just need to say
that the device is a POS and is just not worth it. Remember, there is
still "lirc hole" for the hard core people still using solder to produce
something out of the spare electronic components that may be made to
work (never mind that it causes the CPU constantly poll the device, not
letting it sleep and wasting electricity as a result - just hypotetical
example here).

We still need to do cost-benefit analysis and decide whether supporting
the exotic setups _in kernel_ makes sense if it encumbers implementation
and causes issues to the other 95% people.

--
Dmitry