All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Walls <awalls@md.metrocast.net>
To: Jarod Wilson <jarod@redhat.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] ir-nec-decoder: decode Apple's NEC remote variant
Date: Fri, 29 Oct 2010 18:15:16 -0400	[thread overview]
Message-ID: <1288390516.2387.27.camel@morgan.silverblock.net> (raw)
In-Reply-To: <20101029031319.GF17238@redhat.com>

On Thu, 2010-10-28 at 23:13 -0400, Jarod Wilson wrote:
> Apple's remotes use an NEC-like protocol, but without checksumming. See
> http://en.wikipedia.org/wiki/Apple_Remote for details. Since they always
> send a specific vendor code, check for that, and bypass the checksum
> check.

Jarrod,

This is kind of icky.

According to the Wikipedia article, the Apple remote is use the NEC
protocol's physical (PHY) layer, but it's using a different datalink
(DL) layer.

I say the data link layers are different, because the target device
address bytes are in different places and the command payload differs:

NEC bytes are:   Addr Addr' Command Command'
Apple bytes are: 0xee 0x87  Command ID


In NEC "Addr" is used to address a particular device (TV model, VCR
model, etc.) which in the Apple protocol seems to be the function of ID.

Maybe the Apple remote protocol just needs it's own decoder.  That way
the Apple rc-map can just ignore the ID bytes (or maybe make it a user
configurable option to ignore).

Or, if you really want to work, split up PHY vs DL layer in the ir
protocol decoders. ;) 

Regards,
Andy



> Signed-off-by: Jarod Wilson <jarod@redhat.com>
> ---
>  drivers/media/IR/ir-nec-decoder.c |   10 +++++++++-
>  1 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/IR/ir-nec-decoder.c b/drivers/media/IR/ir-nec-decoder.c
> index 70993f7..6dcddd2 100644
> --- a/drivers/media/IR/ir-nec-decoder.c
> +++ b/drivers/media/IR/ir-nec-decoder.c
> @@ -50,6 +50,7 @@ static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
>  	struct nec_dec *data = &ir_dev->raw->nec;
>  	u32 scancode;
>  	u8 address, not_address, command, not_command;
> +	bool apple = false;
>  
>  	if (!(ir_dev->raw->enabled_protocols & IR_TYPE_NEC))
>  		return 0;
> @@ -158,7 +159,14 @@ static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
>  		command	    = bitrev8((data->bits >>  8) & 0xff);
>  		not_command = bitrev8((data->bits >>  0) & 0xff);
>  
> -		if ((command ^ not_command) != 0xff) {
> +		/* Apple remotes use an NEC-like proto, but w/o a checksum */
> +		if ((address == 0xee) && (not_address == 0x87)) {
> +			apple = true;
> +			IR_dprintk(1, "Apple remote, ID byte 0x%02x\n",
> +				   not_command);
> +		}
> +
> +		if (((command ^ not_command) != 0xff) && !apple) {
>  			IR_dprintk(1, "NEC checksum error: received 0x%08x\n",
>  				   data->bits);
>  			break;
> -- 
> 1.7.1
> 
> 



  reply	other threads:[~2010-10-29 22:14 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29  3:11 [RFC PATCH 0/2] Apple remote support Jarod Wilson
2010-10-29  3:13 ` [RFC PATCH 1/2] ir-nec-decoder: decode Apple's NEC remote variant Jarod Wilson
2010-10-29 22:15   ` Andy Walls [this message]
2010-10-29  3:13 ` [RFC PATCH 2/2] IR: add Apple remote keymap Jarod Wilson
2010-10-29  3:15 ` [RFC PATCH 0/2] Apple remote support Jarod Wilson
2010-10-29 13:46   ` Mauro Carvalho Chehab
2010-10-29 15:11     ` Jarod Wilson
2010-10-29 19:17       ` David Härdeman
2010-10-29 19:27         ` Jarod Wilson
2010-10-29 19:59           ` David Härdeman
2010-10-29 20:09             ` Jarod Wilson
2010-10-30 23:36               ` David Härdeman
2010-10-31  2:32                 ` Jarod Wilson
2010-11-01 21:56                   ` David Härdeman
2010-11-02 20:42                     ` Jarod Wilson
2010-11-04 12:16                       ` David Härdeman
2010-11-04 15:54                         ` Jarod Wilson
2010-11-04 19:38                           ` David Härdeman
2010-11-04 19:43                             ` Mauro Carvalho Chehab
2010-11-05 13:27                               ` David Härdeman
2010-11-05 14:04                                 ` Christopher Harrington
2010-11-07 19:01                                   ` Jarod Wilson
2010-11-15  4:11                                 ` Jarod Wilson
2010-11-15 18:39                                   ` David Härdeman
2010-11-16 12:08                                   ` Mauro Carvalho Chehab
2010-11-16 23:26                                     ` David Härdeman
2010-11-18 16:33                                       ` Jarod Wilson
2010-11-18 20:43                                         ` David Härdeman
2010-11-18 20:49                                           ` Jarod Wilson
2010-11-18 20:59                                             ` Mauro Carvalho Chehab
2010-11-19 23:55                                               ` David Härdeman

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=1288390516.2387.27.camel@morgan.silverblock.net \
    --to=awalls@md.metrocast.net \
    --cc=jarod@redhat.com \
    --cc=linux-media@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.