Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux