On Thu, Aug 27, 2009 at 1:06 PM, Peter
Brouwer[off-list ref] 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