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@xxxxxxxxxxxxx> --- 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
