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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
