From: Jarod Wilson <jarod@redhat.com>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Andy Walls <awalls@md.metrocast.net>,
Christoph Bartelmus <lirc@bartelmus.de>,
jarod@wilsonet.com, linux-input@vger.kernel.org,
linux-media@vger.kernel.org, lirc-list@lists.sourceforge.net,
maximlevitsky@gmail.com, mchehab@redhat.com
Subject: Remote that breaks current system (was: IR: Port ene driver...) it.
Date: Mon, 2 Aug 2010 11:12:25 -0400 [thread overview]
Message-ID: <20100802151225.GA2296@redhat.com> (raw)
In-Reply-To: <AANLkTi=tZaSGp3V8+4FHupzegmVrgM4-dzJb-y8YazOh@mail.gmail.com>
On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
...
> > Since these two protocols have such close timings that systematic errors
> > can cause misclassification when using simple mark or space measurements
> > against fixed thresholds, it indicates that a more sophisticated
> > discrimination mechanism would be needed. Perhaps one that takes multiple
> > successive measurements into account?
>
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
>
> Find some remotes and receivers that break the current system.
Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
ported over the weekend, but this remote just won't decode correctly w/the
in-kernel RC5 decoder.
Working:
Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
Streamzap receiver + RC5 (Streamzap) remote, lirc decoding
Not working:
Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding
Failure mode is identical between the two, leading me to believe my
streamzap port is good to go, we just have an issue to track down with rc5
decoding.
Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
space provided by both receivers, then gets rolling with (I believe) the
first pulse. It then gets all the way to STATE_FINISHED, and bails,
because it should be on a space there, but its on a pulse.
I've twiddled the decoder to proceed even if its a pulse, but the
resulting decoding is still no good, as multiple adjacent keys (which have
proper decoded values that only differ by 1, per lirc decoding) get
decoded to the same value as one another.
Still poking around trying to figure out the problem, but here's what the
(slightly modified to not bail when it gets to STATE_FINISHED with a
pulse) rc5 decoder is seeing/doing:
ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
ir_rc5_decode: RC5 usually ends w/space, wtf?
ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
ir_getkeycode: unknown key for scancode 0x1129
This was for the OK button on the remote, which in lircd, decodes to
scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons.
At least, I think I'm decoding lircd.conf correctly. See here to be sure:
http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap
--
Jarod Wilson
jarod@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-08-02 15:24 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-30 2:17 [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Maxim Levitsky
2010-07-30 2:17 ` [PATCH 01/13] IR: Kconfig fixes Maxim Levitsky
2010-07-30 2:17 ` [PATCH 02/13] IR: minor fixes: Maxim Levitsky
2010-07-30 2:17 ` [PATCH 03/13] IR: replace spinlock with mutex Maxim Levitsky
2010-07-30 2:17 ` [PATCH 04/13] IR: fix locking in ir_raw_event_work Maxim Levitsky
2010-07-30 2:42 ` Andy Walls
2010-07-30 11:02 ` Maxim Levitsky
2010-07-30 2:17 ` [PATCH 05/13] IR: JVC: make repeat work Maxim Levitsky
2010-07-30 2:17 ` [PATCH 06/13] IR: nec decoder: fix repeat Maxim Levitsky
2010-07-30 2:50 ` Andy Walls
2010-07-30 2:17 ` [PATCH 07/13] IR: NECX: support repeat Maxim Levitsky
2010-07-30 2:17 ` [PATCH 08/13] IR: Allow not to compile keymaps in Maxim Levitsky
2010-07-30 2:17 ` [PATCH 09/13] IR: add helper function for hardware with small o/b buffer Maxim Levitsky
2010-07-30 2:17 ` [PATCH 10/13] IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver) Maxim Levitsky
2010-07-30 2:17 ` [PATCH 11/13] IR: report unknown scancodes the in-kernel decoders found Maxim Levitsky
2010-07-30 2:17 ` [PATCH 12/13] STAGING: remove lirc_ene0100 driver Maxim Levitsky
2010-07-30 2:17 ` [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it Maxim Levitsky
2010-07-30 2:39 ` Jon Smirl
2010-07-30 3:46 ` Andy Walls
2010-07-30 11:36 ` Maxim Levitsky
2010-07-30 11:51 ` Jon Smirl
2010-07-30 11:54 ` Maxim Levitsky
2010-07-30 12:02 ` Jon Smirl
2010-07-30 12:07 ` Jon Smirl
2010-07-30 12:45 ` Maxim Levitsky
2010-07-31 13:55 ` Andy Walls
2010-07-31 14:28 ` Maxim Levitsky
2010-07-31 14:37 ` Jon Smirl
2010-07-31 14:51 ` Maxim Levitsky
2010-07-31 15:12 ` Andy Walls
2010-07-31 16:25 ` Jon Smirl
2010-07-31 16:44 ` Maxim Levitsky
2010-07-31 16:51 ` Maxim Levitsky
2010-07-31 17:47 ` Christoph Bartelmus
2010-07-31 18:14 ` Jon Smirl
2010-07-31 18:33 ` Jon Smirl
2010-07-31 18:51 ` Andy Walls
2010-07-31 21:53 ` Jon Smirl
2010-07-31 23:26 ` Maxim Levitsky
2010-08-01 9:43 ` Christoph Bartelmus
2010-08-02 15:12 ` Jarod Wilson [this message]
2010-08-02 16:11 ` Remote that breaks current system (was: IR: Port ene driver...) it Jon Smirl
2010-08-02 16:42 ` Remote that breaks current system Christoph Bartelmus
2010-08-02 17:13 ` Jon Smirl
2010-08-02 18:09 ` Jarod Wilson
2010-08-02 20:42 ` Jon Smirl
2010-08-11 14:38 ` Jarod Wilson
2010-08-12 6:46 ` Christoph Bartelmus
2010-08-16 4:04 ` Jarod Wilson
2010-08-16 20:41 ` Maxim Levitsky
2010-08-17 0:14 ` Jarod Wilson
2010-08-17 3:30 ` Mauro Carvalho Chehab
2010-08-17 3:40 ` Jarod Wilson
2010-08-02 17:51 ` Jarod Wilson
2010-08-01 9:50 ` [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it Christoph Bartelmus
2010-08-01 14:00 ` Jon Smirl
2010-08-01 14:05 ` Jon Smirl
2010-08-01 15:13 ` Christoph Bartelmus
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=20100802151225.GA2296@redhat.com \
--to=jarod@redhat.com \
--cc=awalls@md.metrocast.net \
--cc=jarod@wilsonet.com \
--cc=jonsmirl@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lirc-list@lists.sourceforge.net \
--cc=lirc@bartelmus.de \
--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).