On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote: > Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? > > Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. This is one of the key use cases I would be very concerned with. For many users who have bought tuner products, the bundled remotes work "out-of-the-box", regardless of whether lircd is installed. I have no objection so much as to saying "well, you have to install the lircd service now", but there needs to be a way for the driver to automatically tell lirc what the default remote control should be, to avoid a regression in functionality. We cannot go from a mode where it worked automatically to a mode where now inexperienced users now have to deal with the guts of getting lircd properly configured. If such an interface were available, I would see to it that at least all the devices I have added RC support for will continue to work (converting the in-kernel RC profiles to lirc RC profiles as needed and doing the associations with the driver). The other key thing I don't think we have given much thought to is the fact that in many tuners, the hardware does RC decoding and just returns NEC/RC5/RC6 codes. And in many of those cases, the hardware has to be configured to know what format to receive. We probably need some kernel API such that the hardware can tell lirc what formats are supported, and another API call to tell the hardware which mode to operate in. This is why I think we really should put together a list of use cases, so that we can see how any given proposal addresses those use cases. I offered to do such, but nobody seemed really interested in this. 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
