dib0700 NEC scancode question

dib0700 NEC scancode question

[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:

	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

Re: dib0700 NEC scancode question

[David Härdeman]

On Thu, Mar 27, 2014 at 01:07:28PM +0100, David Härdeman wrote:
>Hi Patrick,
>
>a quick question regarding the dib0700 driver:
>
>in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:
...
>The NEC protocol transmits in the order:
...
>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?
...
>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/

-- 
David Härdeman

Re: dib0700 NEC scancode question

[Patrick Boettcher]

Hi David,

On Thursday 27 March 2014 22:40:41 David Härdeman wrote:
> On Thu, Mar 27, 2014 at 01:07:28PM +0100, David Härdeman wrote:
> >Hi Patrick,
> >
> >a quick question regarding the dib0700 driver:
> 
> >in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:
> ...
> 
> >The NEC protocol transmits in the order:
> ...
> 
> >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? 

-- 
Patrick.

Re: dib0700 NEC scancode question

[David Härdeman]

On Thu, Mar 27, 2014 at 11:13:35PM +0100, Patrick Boettcher wrote:
>Hi David,
>
>On Thursday 27 March 2014 22:40:41 David Härdeman wrote:
>> On Thu, Mar 27, 2014 at 01:07:28PM +0100, David Härdeman wrote:
>> >Hi Patrick,
>> >
>> >a quick question regarding the dib0700 driver:
>> 
>> >in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:
>> ...
>> 
>> >The NEC protocol transmits in the order:
>> ...
>> 
>> >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? 

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

-- 
David Härdeman