From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Sean Young <sean@mess.org>
Cc: linux-media@vger.kernel.org, Jarod Wilson <jarod@redhat.com>
Subject: Re: [PATCH] [media] nec decoder: wrong bit order for nec32 protocol
Date: Tue, 22 Nov 2016 11:35:06 -0200 [thread overview]
Message-ID: <20161122113506.1a604721@vento.lan> (raw)
In-Reply-To: <1478708015-1164-5-git-send-email-sean@mess.org>
Em Wed, 9 Nov 2016 16:13:35 +0000
Sean Young <sean@mess.org> escreveu:
> The bits are sent in lsb first. Hardware decoders also send nec32
> in this order (e.g. dib0700). This should be consistent, however
> I have no way of knowing which order the LME2510 and Tivo keymaps
> are (the only two kernel keymaps with NEC32).
Hmm.. the lme2510 receives the scancode directly. So, this
patch shouldn't affect it. So, we're stuck with the Tivo IR.
On Tivo, only a few keys (with duplicated scancodes) don't start with
0xa10c. So, it *seems* that this is an address.
The best here would be to try to get a Tivo remote controller[1], and
do some tests with a driver that has a hardware decoder capable of
output NEC32 data, and some driver that receives raw IR data in
order to be sure.
In any case, we need to patch both the NEC32 decoder and the table
at the same time, to be 100% sure.
[1] or some universal remote controller that could emulate
the Tivo's scan codes. I suspect that the IR in question is
this one, but maybe Jarod could shed some light here:
https://www.amazon.com/TiVo-Remote-Control-Universal-Replacement/dp/B00DYYKA04
>
> Signed-off-by: Sean Young <sean@mess.org>
> ---
> drivers/media/rc/ir-nec-decoder.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/rc/ir-nec-decoder.c b/drivers/media/rc/ir-nec-decoder.c
> index 2a9d155..ba02d05 100644
> --- a/drivers/media/rc/ir-nec-decoder.c
> +++ b/drivers/media/rc/ir-nec-decoder.c
> @@ -170,7 +170,10 @@ static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev)
> if (send_32bits) {
> /* NEC transport, but modified protocol, used by at
> * least Apple and TiVo remotes */
> - scancode = data->bits;
> + scancode = address << 24 |
> + not_address << 16 |
> + command << 8 |
> + not_command;
> IR_dprintk(1, "NEC (modified) scancode 0x%08x\n", scancode);
> rc_type = RC_TYPE_NEC32;
> } else if ((address ^ not_address) != 0xff) {
Thanks,
Mauro
next prev parent reply other threads:[~2016-11-22 13:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 16:13 [PATCH] [media] nec decoder: wrong bit order for nec32 protocol Sean Young
2016-11-22 13:35 ` Mauro Carvalho Chehab [this message]
2016-11-22 14:19 ` Jarod Wilson
2016-11-22 15:08 ` Mauro Carvalho Chehab
2016-11-22 15:56 ` Sean Young
2016-11-22 15:49 ` Sean Young
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=20161122113506.1a604721@vento.lan \
--to=mchehab@s-opensource.com \
--cc=jarod@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=sean@mess.org \
/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).