Jon Smirl 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. Agreed. You may start by adding either lirc "decoder" or mce. Both ways will end on having the same result ;) >> (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?) > > Why aren't these files going into drivers/input/rc? My embedded system > has a remote control and it has nothing to do with media. Historical reasons. It were simpler to start from drivers/media, as we've started with some already existing code there. My intention is to write one or two big patches at the end, moving everything to drivers/rc or drivers/input/rc and renaming the structures. The point is that a patch like that will force people that are working on the code to rebase to the newer names, so I prefer to postpone it to happen after we finish with the big changes. A change like that won't affect just the new RC code, but also several V4L/DVB drivers. Maybe the right moment would be during the next merge window, as all pending work for 2.6.35 will be already finished, and people likely didn't start working for 2.6.36. So, my intention is to write such patch during the merge week, just after sending the pending stuff. -- Cheers, Mauro -- 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
