On Fri, 2010-04-23 at 14:06 -0400, Jon Smirl wrote: > On Fri, Apr 23, 2010 at 1:40 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> 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'd take whatever you think is the simplest path. It is more likely > that initial testers will want to work with the new in-kernel system > than the compatibility layer to LIRC. Existing users that are happy > with the current LIRC should just keep on using it. Jarod, Not that my commit rate has been > 0 LOC lately, but I'd like to see lirc_dev, just to get transmit worked out for the CX23888 chip and cx23885 driver. I think this device will bring to light some assumptions LIRC currently makes about transmit that don't apply to the CX23888 (i.e. LIRC having to perform the pulse timing). The cx23888-ir implementation has a kfifo for holding outgoing pulse data and the hardware itself has an 8 pulse measurement deep fifo. But I'd recommend whatever helps you get more productive work done first. I've had no time for linux lately. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
