From: Jon Smirl <jonsmirl@gmail.com>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Jarod Wilson <jarod@wilsonet.com>,
linux-input <linux-input@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
linux-media@vger.kernel.org
Subject: Re: Can I expect in-kernel decoding to work out of box?
Date: Wed, 28 Jul 2010 06:40:45 -0400 [thread overview]
Message-ID: <AANLkTingNgxFLZcUszp-WDZocH+VK_+QTW8fB2PAR7XS@mail.gmail.com> (raw)
In-Reply-To: <1280298606.6736.15.camel@maxim-laptop>
On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky <maximlevitsky@gmail.com> 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.
> No its not, its just extended NEC.
http://www.sbprojects.com/knowledge/ir/nec.htm
Says the last two bytes should be the complement of each other.
So for extended NEC it would need to be:
1100 0010 1010 0101 instead of 1100 0010 1010 0100
The last bit is wrong.
From the debug output it is decoding as NEC, but then it fails a
consistency check. Maybe we need to add a new protocol that lets NEC
commands through even if they fail the error checks. It may also be
that the NEC machine rejected it because the timing was so far off
that it concluded that it couldn't be a NEC messages. The log didn't
include the exact reason it got rejected. Add some printks at the end
of the NEC machine to determine the exact reason for rejection.
The current state machines enforce protocol compliance so there are
probably a lot of older remotes that won't decode right. We can use
some help in adjusting the state machines to let out of spec codes
through.
The timing of those pulses is exactly right for JVC. Maybe there is an
extended 4 byte version of the JVC protocol. JVC doesn't have the
error checks like NEC. The question here is, why didn't the JVC
machine get started?
User space lirc is much older. Bugs like this have been worked out of
it. It will take some time to get the kernel implementation up to the
same level.
>
> This lirc generic config matches that output quite well:
> NEC-short-pulse.conf:
>
> begin remote
>
> name NEC
> bits 16
> flags SPACE_ENC|CONST_LENGTH
> eps 30
> aeps 100
>
> header 9000 4500
> one 563 1687
> zero 563 562
> ptrail 563
> pre_data_bits 16
> # just a guess
> gap 108000
>
> repeat 9000 2250
>
> frequency 38000
> duty_cycle 33
>
> begin codes
> end codes
>
> end remote
>
>
>
>> >
>> > 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.
>
> In fact its dead easy to test a lot of remotes, by using an universal
> remote. These remotes are designed to tech literate persons for a
> reason....
>
> On my remote, all I have to do is press TV + predefined number + OK to
> make remote mimic a random remote.
> Unill now, kernel decoding couldn't pick anything but one mode....
>
>
> Here is a table I created long ago on my remote showing all kinds of
> protocols there:
>
> Heck, hardware isn't very accurate, I know, but streamzap receiver
> according to what I have heard it even worse...
>
> Best regards,
> Maxim Levitsky
>
>
> 08 - NEC short pulse / SANYO (38 khz), [15 - NEC]
> 9440 4640 620 550 620 550 620 550 620 550 620 550
> 620 550 620 1720 610 550 610 1720 620 1720 620 1720
> 620 1720 610 1730 610 1720 620 550 620 1720 620 550
> 620 550 620 550 620 550 620 550 620 550 610 550
> 610 550 610 1720 620 1720 620 1720 620 1720 620 1720
> 610 1720 620 1720 620 1720 620 41540 9440 2300 620 100110
> (9440 2300 610 100110)
> ---------------------------------------------------------------------------------------------------------------
> 02 - Philips (RC5): (36 khz)
> 990 890 970 890 1920 890 970 890 970 890 970 890
> 970 890 970 890 970 890 970 890 970 890 970 890
> 970 94190
> ---------------------------------------------------------------------------------------------------------------
> 25 - Philips (RECS-80): (38 khz)
> 200 7720 170 7720 170 7700 200 7690 200 7720 170 5090
> 160 7730 170 5090 170 5090 160 5090 170 5090 170
> ---------------------------------------------------------------------------------------------------------------
> 01 - JVC: (38 khz)
> 8840 4370 590 1600 590 1600 590 500 590 500 590 500
> 590 500 590 510 590 510 590 500 590 500 590 500
> 590 1600 590 500 590 1600 590 500 590 500 590 25730
> ---------------------------------------------------------------------------------------------------------------
> 07 - Sony (SIRC): (40 khz)
> 2550 600 1260 600 630 600 630 600 1260 600 630 600
> 630 600 630 600 1260 600 630 600 630 600 630 600
> 630 27450 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 19 - MOTOROLLA:
> 610 2730 550 550 580 520 580 520 580 490 600 520
> 580 520 580 520 580 520 580 520 580 21240
>
> (600 2720 580 1070 580 520 580 520 580 520 1130 1070
> 580 490 580 540 550 540 580 126890)
> ---------------------------------------------------------------------------------------------------------------
> 06 - Sharp (denon): (38 khz)
> 370 1870 340 750 340 760 340 750 340 750 340 750
> 340 1870 340 750 340 1870 340 760 340 760 340 760
> 340 760 340 1870 340 750 340 48940
>
> 370 1870 340 750 340 760 340 760 340 750 340 1870
> 340 750 340 1870 340 760 340 1870 340 1870 340 1870
> 340 1870 340 760 340 1870 340 44610
> ---------------------------------------------------------------------------------------------------------------
> 30 - Nokia NRC17:
> 580 2590 550 990 1100 490 550 480 550 480 550 480
> 550 480 550 490 550 480 550 480 550 490 550 480
> 550 490 550 480 550 480 550 480 550 20230
>
> 580 2580 560 990 550 490 1100 480 550 990 550 480
> 550 490 550 480 550 480 1100 990 1100 490 550 990
> 1100 990 550 84380
>
> 580 2580 550 990 550 490 1100 480 550 990 550 490
> 550 480 550 480 550 480 1100 990 1100 480 550 990
> 1100 990 550 84380
> ---------------------------------------------------------------------------------------------------------------
> 03 - Mitsubishi:
> 350 2220 320 2220 320 2220 320 950 320 950 340 920
> 320 2220 320 950 320 2220 320 950 350 920 320 2220
> 320 950 320 950 320 950 320 950 320 27630 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 04 - Panasonic:
> 3600 3460 950 820 960 820 950 820 950 820 950 820
> 960 2570 960 820 950 820 950 2580 950 2580 950 820
> 950 2580 950 2580 950 2580 950 2580 950 2580 950 820
> 950 2580 950 2580 960 820 960 820 950 2570 960 39070
> <rep>
> ---------------------------------------------------------------------------------------------------------------
> 11 - Panasonic:
> 3700 1780 490 410 500 1320 490 410 490 410 490 410
> 500 410 490 410 490 410 500 410 490 410 490 410
> 490 410 490 410 490 1320 490 410 500 410 490 410
> 490 410 490 410 500 410 490 410 490 410 500 410
> 490 1320 490 410 490 410 500 410 490 410 490 410
> 490 410 490 410 490 410 490 1320 500 410 490 410
> 490 1320 500 1310 500 410 490 410 490 410 490 1320
> 490 410 490 410 490 1320 490 1320 490 410 490 410
> 490 1320 500 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 05 - unknown:
> 20950 4110 620 1990 590 2020 580 2020 580 2020 590 980
> 580 980 580 2020 590 2020 580 980 580 980 590 980
> 590 980 580 980 580 980 580 980 580 980 580 2020
> 580 2020 590 980 580 980 580 2020 590 2020 580 2020
> 580 2020 1070
> ---------------------------------------------------------------------------------------------------------------
> 09 - unknown:
> 590 480 560 4230 560 480 560 4230 560 5260 560 5260
> 560 480 560 4230 560 5260 560 480 560 4220 560 5260
> 560 480 560 4220 560 5260 560 480 560 126450 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 12 - RCA?
> 4740 4650 620 1720 620 1720 620 1720 620 550 610 550
> 610 550 610 550 620 550 620 1720 620 1720 620 1720
> 620 550 620 550 620 550 620 550 620 550 620 1720
> 620 550 620 550 610 550 610 1730 610 550 610 550
> 610 550 620 550 620 1720 620 1720 620 1720 620 550
> 620 1720 620 1720 620 1720 620
> ---------------------------------------------------------------------------------------------------------------
> 26 - junk -(thomson) - unsuppored/no carrier
> 27 - junk -(unknown) - unsuppored/no carrier
> 28 - junk -ITT - unsuppored/no carrier
>
>
>
>
>
>>
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
next prev parent reply other threads:[~2010-07-28 10:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 22:33 Can I expect in-kernel decoding to work out of box? Maxim Levitsky
2010-07-27 23:32 ` Maxim Levitsky
2010-07-28 1:29 ` Jon Smirl
2010-07-28 2:33 ` Jarod Wilson
2010-07-28 6:30 ` Maxim Levitsky
2010-07-28 6:59 ` Maxim Levitsky
2010-07-28 10:40 ` Jon Smirl [this message]
2010-07-28 13:13 ` Mauro Carvalho Chehab
2010-07-28 13:46 ` Jon Smirl
2010-07-28 14:38 ` Andy Walls
2010-07-28 14:53 ` Jon Smirl
2010-07-28 15:42 ` Mauro Carvalho Chehab
2010-07-28 17:02 ` Andy Walls
2010-07-28 17:35 ` Jon Smirl
2010-07-28 18:18 ` Andy Walls
2010-07-28 20:13 ` Mauro Carvalho Chehab
2010-07-28 20:27 ` Maxim Levitsky
2010-07-29 2:36 ` Andy Walls
2010-07-29 11:58 ` Jon Smirl
2010-07-28 18:29 ` Mauro Carvalho Chehab
2010-07-28 14:24 ` Maxim Levitsky
2010-07-28 14:41 ` Jon Smirl
2010-07-28 15:18 ` Jarod Wilson
2010-07-28 15:56 ` Mauro Carvalho Chehab
2010-07-28 17:04 ` Jon Smirl
2010-07-28 17:21 ` Andy Walls
2010-07-28 17:38 ` Jon Smirl
2010-07-28 18:35 ` Mauro Carvalho Chehab
2010-07-28 18:08 ` Mauro Carvalho Chehab
2010-07-28 18:05 ` Jarod Wilson
2010-07-28 18:40 ` Mauro Carvalho Chehab
2010-07-28 21:01 ` Maxim Levitsky
2010-07-28 21:35 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTingNgxFLZcUszp-WDZocH+VK_+QTW8fB2PAR7XS@mail.gmail.com \
--to=jonsmirl@gmail.com \
--cc=jarod@wilsonet.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=mchehab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).