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

[Trent Piepho <xyzzy@speakeasy.org>]

On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> See above. Also, several protocols have a way to check if a keystroke were
> >> properly received. When handling just one protocol, we can use this to double
> >> check the key. However, on a multiprotocol mode, we'll need to disable this
> >> feature.
> >
> > I don't think so. We can pass the space/mark data to all (configured,
> > i.e. with active mapping) protocol handlers at once. Should a check
> > fail, we ignore the data. Perhaps another protocol will make some sense
> > out of it.
>
> What happens if it succeeds on two protocol handlers?

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

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