NECX scancode consistency

NECX scancode consistency

[David Härdeman]

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