NECX scancode consistency

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