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-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
