dib0700 NEC scancode question

["David Härdeman" <david@hardeman.nu>]

Hi Patrick,

a quick question regarding the dib0700 driver:

in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:

	struct dib0700_rc_response {
		u8 report_id;
		u8 data_state;
		union {
			u16 system16;
			struct {
				u8 not_system;
				u8 system;
			};
		};
		u8 data;
		u8 not_data;
	};

The NEC protocol transmits in the order:
	system
	not_system
	data
	not_data

Does the dib0700 fw really reorder the bytes, or could the order of
not_system and system in struct dib0700_rc_response have been
accidentally reversed?

Note that the NEC extended keycode is later defined in dib0700_core.c as:

	keycode = be16_to_cpu(poll_reply->system16) << 8 | poll_reply->data;

i.e.

	keycode = poll_reply->not_system << 16 |
		  poll_reply->system     << 8  |
		  poll_reply->data;

Which, if the order *is* reversed, would mean that the scancode that
gets defined is in reality:

	keycode = poll_reply->system     << 16 |
		  poll_reply->not_system << 8  |
		  poll_reply->data;

Which is the same as the order used in drivers/media/rc/ir-nec-decoder.c.

(An order which I'm considering trying to correct, which is why I'm
checking all the places where NEC scancodes are generated).

-- 
David Härdeman