Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins

[Jarod Wilson <jarod@wilsonet.com>]

On Sat, Apr 24, 2010 at 1:12 AM, David Härdeman <david@hardeman.nu> wrote:
> On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote:
>> So now that I'm more or less done with porting the imon driver, I
>> think I'm ready to start tackling the mceusb driver. But I'm debating
>> on what approach to take with respect to lirc support. It sort of
>> feels like we should have lirc_dev ported as an ir "decoder"
>> driver/plugin before starting to port mceusb to ir-core, so that we
>> can maintain lirc compat and transmit support. Alternatively, I could
>> port mceusb without lirc support for now, leaving it to only use
>> in-kernel decoding and have no transmit support for the moment, then
>> re-add lirc support. I'm thinking that porting lirc_dev as, say,
>> ir-lirc-decoder first is probably the way to go though. Anyone else
>> want to share their thoughts on this?
>
> I think it would make sense to start with a mce driver without the TX
> and lirc bits first. Adding lirc rx support can be done as a separate
> "raw" decoder later (so its scope is outside the mce driver anyway) and
> TX support is not implemented in ir-core yet and we haven't had any
> discussion yet on which form it should take.

So after looking at folks feedback, I did settle on starting the
mceusb port first, my logic going more or less like this... Having a
well-supported general-purpose IR receiver functional is a Good Thing
for people wanting to work on protocol support (i.e., so they have a
way to actually test protocol support). Having an
already-ir-core-ified driver to test out an ir-lirc-decoder (lirc_dev
port) would also be rather helpful. So rather than trying to port
lirc_dev before there's anything that can actually make use of it,
give myself something to work with. I'm kind of thinking that
ir-lirc-decoder might actually be ir-lirc-codec, able to do xmit as
well, maintaining full compat with lirc userspace, and then we'd have
a separate input subsystem based xmit method at some point, which
might be the "preferred/blessed" route. This means ripping a bunch of
code out of lirc_mceusb.c only to put it back in later, but that's not
terribly painful. I've already got as far as having an mceusb.c that
has no lirc dependency, which builds, but doesn't actually do anything
useful yet (not wired up to ir-core). Should be able to get something
functional RSN, I hope...

-- 
Jarod Wilson
jarod@wilsonet.com