Re: Can I expect in-kernel decoding to work out of box?

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

 



On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
> On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky <maximlevitsky@xxxxxxxxx> wrote:
>> On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote:
>>> Hi,
>>>
>>> I ported my ene driver to in-kernel decoding.
>>> It isn't yet ready to be released, but in few days it will be.
>>>
>>> Now, knowing about wonders of in-kernel decoding, I try to use it, but
>>> it just doesn't work.
>>>
>>> Mind you that lircd works with this remote.
>>> (I attach my lircd.conf)
>>>
>>> Here is the output of mode2 for a single keypress:
>
>    8850     4350      525     1575      525     1575
>     525      450      525      450      525      450
>     525      450      525     1575      525      450
>     525     1575      525      450      525     1575
>     525      450      525      450      525     1575
>     525      450      525      450      525    23625
>
> That decodes as:
> 1100 0010 1010 0100
>
> In the NEC protocol the second word is supposed to be the inverse of
> the first word and it isn't. The timing is too short for NEC protocol
> too.
>
> Valid NEC...
> 1100 0011 1010 0101
>
> Maybe JVC protocol but it is longer than normal.
>
> The JVC decoder was unable to get started decoding it.  I don't think
> the JVC decoder has been tested much. Take a look at it and see why it
> couldn't get out of state 0.

Personally, I haven't really tried much of anything but RC-6(A) and
RC-5 while working on mceusb, so they're the only ones I can really
vouch for myself at the moment. It seems that I don't have many
remotes that aren't an RC-x variant, outside of universals, which I
have yet to get around to programming for various other modes to test
any of the protocol decoders. I assume that David Hardeman already did
that much before submitting each of the ir protocol decoders with his
name one them (which were, if I'm not mistaken, based at least
partially on Jon's earlier work), but its entirely possible there are
slight variants of each that aren't handled properly just yet. That
right there is one of the major reasons I saw for writing the lirc
bridge driver plugin in the first place -- the lirc userspace decoder
has been around for a LOT longer, and thus is likely to know how to
handle more widely varying IR signals.

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