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 Tue, May 25, 2010 at 5:05 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote:
> 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. :)

I was missing something blindingly stupid. Was accumulating duration
values in ms instead of us. Now alternating presses of the OK button
on the stock MCE remote get this:

ir_rc6_decode: RC6(6A) scancode 0x800f0422 (toggle: 1)
ir_rc6_decode: RC6(6A) scancode 0x800f0422 (toggle: 0)

This is with Jon's IR handling routine and a recent MCE device, still
need to go back and see how the older one behaves, but within the next
few days, I should have a patch worthy of submission.

-- 
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