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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
