FYI, I've gone through all the drivers in the media tree that generate NECX codes to make sure they are consistent. There are two question marks (that probably just need a small cleanup) and one driver that reverses the order of the address bytes compared to the rest. file: ./media/rc/ir-nec-decoder.c ====================================================================== order: aaããcc keymap: RC_MAP_NEC_TERRATEC_CINERGY_XS (0x04eb) (used in ./pci/cx23885/cx23885-input.c) code: address = bitrev8((data->bits >> 24) & 0xff); not_address = bitrev8((data->bits >> 16) & 0xff); command = bitrev8((data->bits >> 8) & 0xff); ... scancode = address << 16 | not_address << 8 | command; file: ./media/usb/dvb-usb/dib0700_core.c ====================================================================== note: clarification requested via mail http://www.spinics.net/lists/linux-media/msg75004.html order: aaããcc (?) keymap: RC_MAP_DIB0700_NEC_TABLE (0x866b) code: scancode = RC_SCANCODE_NECX(be16_to_cpu(poll_reply->system16), poll_reply->data); which seems to actually mean: keycode = poll_reply->system << 16 | poll_reply->not_system << 8 | poll_reply->data; file: ./media/usb/dvb-usb-v2/az6007.c ====================================================================== order: aaããcc keymap: RC_MAP_NEC_TERRATEC_CINERGY_XS (0x04eb) code: code = RC_SCANCODE_NECX(st->data[1] << 8 | st->data[2], st->data[3]); file: ./media/usb/dvb-usb-v2/af9035.c ====================================================================== order: aaããcc keymap: RC_MAP_IT913X_V1 (0x61d6 + 0x807f) RC_MAP_IT913X_V2 (0x807f + 0x866b) code: key = RC_SCANCODE_NECX(buf[0] << 8 | buf[1], buf[2]); file: ./media/usb/dvb-usb-v2/rtl28xxu.c ====================================================================== order: aaããcc keymap: RC_MAP_TERRATEC_SLIM (0x02bd) code: rc_code = RC_SCANCODE_NECX(buf[0] << 8 | buf[1], buf[2]); file: ./media/usb/dvb-usb-v2/af9015.c ====================================================================== order: aaããcc keymap: RC_MAP_MSI_DIGIVOX_III (0x61d6) RC_MAP_TERRATEC_SLIM (0x02bd) RC_MAP_TOTAL_MEDIA_IN_HAND (0x02bd) code: state->rc_keycode = RC_SCANCODE_NECX(buf[12] << 8 | buf[13], buf[14]); file: ./media/usb/dvb-usb-v2/lmedm04.c ====================================================================== note: clarification requested via mail order: almost aaããcc, except if aa = 0x00, in which case it's NEC16? keymap: RC_MAP_LME2510 (0x10ed) code: key = RC_SCANCODE_NECX((ibuf[2] ^ 0xff) << 8 | (ibuf[3] > 0) ? (ibuf[3] ^ 0xff) : 0, ibuf[5]); If firmware sends inverted bytes...then... ibuf[2] = ~addr = not_addr; ibuf[3] = ~not_addr = addr; ibuf[4] = ~cmd = not_cmd; ibuf[5] = ~not_cmd = cmd; roughly (not completely true due to the ibuf[3] > 0 ? check)... key = RC_SCANCODE_NECX(addr << 8 | not_addr, cmd); but for addr = 0x00 key = RC_SCANCODE_NECX(0x00, cmd); note that the keytable includes 1-byte scancodes, which would be explained by the addr = 0x00 scenario... file: ./media/usb/em28xx/em28xx-input.c ====================================================================== order: aaããcc keymap: RC_MAP_DELOCK_61959 (0x866b) keymap: RC_MAP_REDDO (0x61d6) code: poll_result->scancode = RC_SCANCODE_NECX(msg[1] << 8 | msg[2], msg[3]); file: ./media/pci/cx88/cx88-input.c ====================================================================== order: aaããcc keymap: RC_MAP_PIXELVIEW_MK12 (0x866b) code: addr = (data >> 8) & 0xffff; cmd = (data >> 0) & 0x00ff; scancode = RC_SCANCODE_NECX(addr, cmd); file: ./media/pci/saa7134/saa7134-input.c ====================================================================== order: ããaacc (!!!) keymap: RC_MAP_BEHOLD (0x6b86 -> 0x866b) code: *scancode = RC_SCANCODE_NECX(((data[10] << 8) | data[11]), data[9]); The only NECX keymap not listed above is RC_MAP_PIXELVIEW_002T which is used in ./usb/cx231xx/cx231xx-cards.c, but that driver has a one-byte scancode filter so only the last byte is actually compared. -- David Härdeman -- 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
