On Nov 25, 2009, at 1:20 PM, Devin Heitmueller wrote: > 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. Agreed. Auto-config of lircd for remotes bundled with receivers is definitely on the TODO list. It sorta kinda works using gnome-lirc-properties, but well, that's not an actual lirc project component, and from what I've seen, its fairly incomplete (and reproduces a device ID list within its own code, that has never been fully updated to match the list of stuff the lirc drivers actually support). > 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. Well, we've got a number of IOCTLs already, could extend those. (Although its been suggested elsewhere that we replace the IOCTLs with sysfs knobs). A simple sysfs attr that contains the name of the default config file for the bundled remote of a given receiver would seem simple enough to implement. > 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. D'oh, sorry, I recall reading that email, but neglected to respond. Yes, I think that's useful, and would gladly contribute to the list. -- Jarod Wilson jarod@xxxxxxxxxxxx -- 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
