Skip to contentSkip to conversation

dib0700 NEC scancode question

DISCUSSION David Härdeman 2 participants 4 messages Mar 27, 2014 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

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).

Signature · 1 line
David Härdeman
#1 lore raw
Quoted 5 lines · David Härdeman

Hi Patrick,

a quick question regarding the dib0700 driver:

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

...

Quoted 1 line

The NEC protocol transmits in the order:

...

Quoted 3 lines

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?

...

Quoted 10 lines

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

s/correct/make sure it's consistent/

Signature · 1 line
David Härdeman
#2 lore raw

Hi David,

Quoted 6 lines · On Thursday 27 March 2014 22:40:41 David Härdeman wrote:
Quoted 5 lines · David Härdeman

Hi Patrick,

a quick question regarding the dib0700 driver:

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

Quoted 8 lines

...

Quoted 1 line

The NEC protocol transmits in the order:

...

Quoted 3 lines

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?

It feels like a hundred years I haven't work on that. I'm not sure whether this knowledge can still be retrieved as of today or not. I would lie if I told you that I look the archives... and I can't want to do that (lying and looking).

However, I realize that your assumption might not be totally far-fetched. If you can find another IR-receiver just check whether the same remote control delivers swapped bytes or not (if I understood it correctly, that's your real question). Then you have you answer, haven't you?

Signature · 1 line
Patrick.
#3 lore raw
Quoted 23 lines · Patrick Boettcher

Hi David,

Quoted 6 lines · On Thursday 27 March 2014 22:40:41 David Härdeman wrote:
Quoted 5 lines · David Härdeman

Hi Patrick,

a quick question regarding the dib0700 driver:

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

Quoted 8 lines

...

Quoted 1 line

The NEC protocol transmits in the order:

...

Quoted 3 lines

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?

It feels like a hundred years I haven't work on that. I'm not sure whether this knowledge can still be retrieved as of today or not. I would lie if I told you that I look the archives... and I can't want to do that (lying and looking).

Quoted 4 lines

However, I realize that your assumption might not be totally far-fetched. If you can find another IR-receiver just check whether the same remote control delivers swapped bytes or not (if I understood it correctly, that's your real question). Then you have you answer, haven't you?

If I had the hardware, yes :)

I don't, I just want to refactor some parts of the IR handling code across several drivers, which is why I came across this...I guess there are others who do have the hardware who will complain loudly if I try changing it and my assumptions turn out to be incorrect though...

Signature · 1 line
David Härdeman