Mauro Carvalho Chehab <mche...@redhat.com> writes: > Dmitry Torokhov wrote: > >>>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: >>>>> >>>>>> Now I understand that if 2 remotes send completely identical >>>>>> signals we won't be able to separete them, but in cases when we >>>>>> can I think we should. >> >> They are the same key events (Lets's say KEY_PLAY) but one is >> supposed to affect CD player while another DVD player >> application. Evdev will not be able to distinguish them but if we had >> 2 separate devices then applications could read from the one thet >> user assigned to them. > > This is clear, but the point is that the two distinguish scancodes can > (and, in practice, will) be generated by the same IR. For example, my > Satellite IR produces two different sets of codes. if you press <SAT>, > all keys you press after that will have the "sat" address. If you > press <TV>, they'll get a different address.
The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent by any remote (ok, I'm stretching it a bit). Instead, a multifunction remote (or two distinct remotes) would send different scan codes, which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example. Btw. the former is already defined, besides the generic KEY_PLAY. Even if all this worked, user space would need integration with hal/devicekit to open the new input devices appearing on the fly (if it's initiated by the arrival of a scan code belonging to some new protocol), and also be able to decide whether the new event source is for it or not. Given that commodity home appliances manage not to be confused by multiple or multifunction remotes, decent software should be able to do so as well.  scan codes in the broadest possible sense, containing vendor, address and whatever, and only treating the case which is possible to handle in principle. -- Regards, Feri. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html