On Fri, Apr 23, 2010 at 1:40 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote: > On Wed, Apr 7, 2010 at 5:32 AM, David Härdeman <david@xxxxxxxxxxx> wrote: >> On Mon, Apr 05, 2010 at 04:49:10PM -0400, Jarod Wilson wrote: >>> On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman <david@xxxxxxxxxxx> wrote: >>> > Porting the msmce driver to rc-core will be high on my list of >>> > priorities once I've done some more changes to the API. >>> >>> Very cool. Though note that the latest lirc_mceusb is quite heavily >>> modified from what Jon had initially ported, and I still have a few >>> outstanding enhancements to make, such as auto-detecting xmit mask to >>> eliminate the crude inverted mask list and support for the mce IR >>> keyboard/mouse, though that'll probably be trivial once RC5 and RC6 >>> in-kernel decoders are in place. I'd intended to start with porting >>> the imon driver I'm working on over to this new infra (onboard >>> hardware decoder, should be rather easy to port), and then hop over to >>> the mceusb driver, but if you beat me to it, I've got no problem with >>> you doing it instead. :) >> >> I'd be happy with you doing it, you seem to know the hardware better >> than me. The mceusb driver I'm using right now with ir-core is based on >> Jon's driver which is in turn based on a version of lirc_mceusb which is >> quite old by now. My version of the driver is basically just random bits >> and pieces thrown together, enough to get pulse/space durations flowing >> through ir-core so that I can test the decoders, but not much more - so >> it's not something I'd even consider useful as a starting point :) > > 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. MSMCE is a good device for debugging protocol engines. It's easy to use and pretty much always captures the pulses correctly. > > (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. -- Jon Smirl jonsmirl@xxxxxxxxx -- 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
