Another approach to IR
in [Kernel]
|
From: Ferenc Wagner on 4 Dec 2009 11:20 Dmitry Torokhov <dmitry.torokhov(a)gmail.com> writes: > On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: >> Ferenc Wagner wrote: >>> Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: >> >> We should not forget that simple IR's don't have any key to select the address, >> so the produced codes there will never have KEY_TV/KEY_DVD, etc. > > Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select > media inputs in a device/application. My receiver accepts codes like > that. Sorry, my point wasn't the event names, I picked them for their superficial correspondence to the TV, DVD, SAT etc. buttons found on multifunction remotes. Obviously I picked wrong. I was also wrong to assume that remotes with such buttons are always multifunction remotes in the sense that they are meant to control separate devices. As Mauro pointed out, (some) bundled remotes with such buttons aren't; thus I wouldn't consider them multifunction at all. They simply have some extra buttons labelled TV, DVD etc, which probably shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry different semantics) but should be mapped to something else. Or not, if these buttons change some internal decoder state instead, modifying the mapping or destination input device of the other keys. It's just a different scenario, where the kernel could reasonably give rather different representations to simple applications aiming at plug&play: letting through the function change events untouched, or masking and using them internally. True multifunction devices don't send such events, the TV, DVD etc buttons on them change their internal state and the scan codes sent by the other keys, if I understand this correctly. I'd prefer if these two behaviours could be abstacted from, and the input layer interface would provide destination selection events + generic events, or (to be defined) device specific events only in either case. Is that possible or even reasonable? -- Thanks, Feri. Ps: I'm writing this in the hope to clean up the landscape and possibly help in choosing the best design. I'm not at all familiar with IR, and the above distinction was pretty surprising for me. Also, I'm just lurking here, so don't take me too seriously. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |