lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <7m5j914h31hev0dqkj085vd7.1290777731791@email.android.com>
Date:	Fri, 26 Nov 2010 08:39:25 -0500
From:	Andy Walls <awalls@...metrocast.net>
To:	James Hogan <james@...anarts.com>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	David Härdeman <david@...deman.nu>,
	Jarod Wilson <jarod@...hat.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ir-nec-decoder: fix extended NEC scancodes

You might want to check the handling against this NEC datasheet

http://www.datasheetcatalog.org/datasheet/nec/UPD6122G-002.pdf

The datasheet calls the address bytes "custom code" (high byte apparently) and "custom code'" (low byte apparently) with both bytes sent lsb first.  It appears the high byte is sent first when using 16 bit codes.

I'm away from my computer so I can't check much more.

Regards,
Andy


James Hogan <james@...anarts.com> wrote:

>Could somebody check this as I'm unable to test it.
>
>I'm also not entirely certain it isn't winbond-cir that is in error
>instead of ir-nec-decoder.
>
>Cheers
>James
>--
>After comparing the extended NEC scancode construction of the software
>decoder and winbond-cir it appears the software decoder is putting the
>two address bytes the wrong way around.
>
>Here's how the decoders currently generate scancodes:
>winbond-cir normal NEC:   msb [ 0x0,      0x0,     addr, cmd ] lsb
>soft normal NEC:          msb [ 0x0,      0x0,     addr, cmd ] lsb
>winbond-cir extended NEC: msb [ 0x0, not_addr,     addr, cmd ] lsb
>soft extended NEC:        msb [ 0x0,     addr, not_addr, cmd ] lsb
>
>The soft decider is not consistent with [1], assuming the "Address high"
>byte (not_addr) should be more significant than the "Address low" byte
>(addr) in the scancode.
>
>[1] http://www.sbprojects.com/knowledge/ir/nec.htm
>
>Signed-off-by: James Hogan <james@...anarts.com>
>---
> drivers/media/IR/ir-nec-decoder.c |    4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/media/IR/ir-nec-decoder.c
>b/drivers/media/IR/ir-nec-decoder.c
>index 70993f7..11d3e78 100644
>--- a/drivers/media/IR/ir-nec-decoder.c
>+++ b/drivers/media/IR/ir-nec-decoder.c
>@@ -166,8 +166,8 @@ static int ir_nec_decode(struct input_dev
>*input_dev, struct ir_raw_event ev)
>
> 		if ((address ^ not_address) != 0xff) {
> 			/* Extended NEC */
>-			scancode = address     << 16 |
>-				   not_address <<  8 |
>+			scancode = not_address << 16 |
>+				   address     <<  8 |
> 				   command;
> 			IR_dprintk(1, "NEC (Ext) scancode 0x%06x\n", scancode);
> 		} else {
>-- 
>1.7.2.3
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majordomo@...r.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ