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