On Sat, Apr 24, 2010 at 1:12 AM, David Härdeman <david@xxxxxxxxxxx> 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@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
