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. > (Actually, while sharing thoughts... Should drivers/media/IR become > drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become > rc-keytable.c and so on?) It will happen...and on a related note, I still think rc-core should in the end expose an API where drivers create "rc" devices and the input device(s) are kept as an internal detail in rc-core rather than the way it works now (where drivers create input devices and use ir-core to create a kind of addon device). But that change is about as disruptive as the ir-core -> rc-core change, so it can also wait to a more convenient time. -- David Härdeman -- 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
