On Thu, Aug 27, 2009 at 1:06 PM, Peter Brouwer<pb.maillists@xxxxxxxxxxxxxx> wrote: > Mauro Carvalho Chehab wrote: > > Hi Mauro, All > > Would it be an alternative to let lirc do the mapping and just let the > driver pass the codes of the remote to the event port. > That way you do not need to patch the kernel for each new card/remote that > comes out. > Just release a different map file for lirc for the remote of choice. > > Peter The biggest challenge with that approach is that lirc is still maintained out-of-kernel, and the inputdev solution does not require lirc at all (which is good for inexperienced end users who want their product to "just work"). Keeping the remote definitions in-kernel also helps developers adding support for new products, since they can be sure that both the device and its remote will appear in the same kernel version (they are inherently in-sync compared to cases where the distribution upgrades the kernel but not necessarily the lircd version they bundle). The other big issue is that right now remotes get associated automaticallywith products as part of the device profile. While this has the disadvantage that there is not a uniform mechanism to specify a different remote than the one that ships with the product, it does have the advantage of the product working "out-of-the-box" with whatever remote it came with. It's a usability issue, but what I would consider a pretty important one. That said, if we had a way to have some sort of remote control signature that can be associated with lirc remote control definitions, which can be referenced in-kernel, that would solve the above mentioned problem of making the product work by default with the remote it shipped with. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
