On Nov 25, 2009, at 1:20 PM, Devin Heitmueller wrote:

On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson [off-list ref] wrote:

quoted

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@wilsonet.com