Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Krzysztof Halasa]

Trent Piepho <xyzzy@xxxxxxxxxxxxx> writes:

> Then you use the protocol that fits best.  For instance decoding with one
> protocol might produce a scancode that isn't assigned to any key, while
> another protocol produces an assigned scancode.  Clearly then the latter is
> most likely to be correct.

Right.

> It also possible to have a space/mark length
> that is within the allowable tolerances for one remote, but is even closer
> another remote.  You don't want to just find *a* match, you want to find
> the *best* match.

That won't work, the decoders don't calculate quality. And even if they
did, if you have two remotes generating the same e.g. RC5 code, you
won't be able to differentiate between them. Your TV etc. won't do that
either.

> The in kernel code in v4l is very simple in that it is only designed to
> work with one procotol and one remote.  Once you have multiple remotes of
> any type things become much more complicted.

If you're using them at once, sure :-)

> Keep in mind that remotes
> that aren't even intended to be used with the computer but are used in the
> same room will still be received by the receiver.  It's not enough to
> decode the signals you expect to receive, you must also not get confused by
> random signals destined for somewhere else.

This is usually not a problem. My experience is the decoding is very
reliable.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/