On Wed, Apr 28, 2010 at 12:32 AM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote: > 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... Got sidetracked for a few weeks, but I'm probably 95% of the way there as of this afternoon. Something isn't quite right with how I'm processing and handing off the raw IR data right now though, best as I can tell. Its also possible my first-gen mce device is throwing things for a loop, so I need to see if maybe things Just Work with a newer gen device so I know if its device-specific, or if something is still generally wrong. I did crib the simplified mce data processing routine from Jon's code, but the original lirc_mceusb.c has some changes specific to the first-gen mce device that were made to properly support it quite some time after Jon's port, so I may also try w/the uglier/more complex routine I know has been working on this device... David, you mentioned having something based on Jon's earlier port that was more or less working. I'd be curious to get a look at that if you're willing to drop me a copy, see if I've missed something blindingly stupid. :) What I get right now when I press a key: ... ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (1us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (1us pulse) Always fails at state 0, varying us values from 0 to 100, but mostly 0 and 1. -- 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
