diff options
author | David Härdeman <david@hardeman.nu> | 2014-04-03 20:31:51 -0300 |
---|---|---|
committer | Mauro Carvalho Chehab <m.chehab@samsung.com> | 2014-07-23 21:26:08 -0300 |
commit | af3a4a9bbeb00df3e42e77240b4cdac5479812f9 (patch) | |
tree | c58da3eef556c0122365bd3d0b37243fcf988842 /include/media | |
parent | 4dd9bb91bb5dc44e3f8c23c60a0ba432e50d7488 (diff) | |
download | linux-af3a4a9bbeb00df3e42e77240b4cdac5479812f9.tar.gz linux-af3a4a9bbeb00df3e42e77240b4cdac5479812f9.tar.bz2 linux-af3a4a9bbeb00df3e42e77240b4cdac5479812f9.zip |
[media] dib0700: NEC scancode cleanup
the RC RX packet is defined as:
struct dib0700_rc_response {
...
u8 not_system;
u8 system;
...
u8 data;
u8 not_data;
The NEC protocol transmits in the order:
system
not_system
data
not_data
Note that the code defines the NEC extended scancode as:
scancode = be16_to_cpu(poll_reply->system16) << 8 | poll_reply->data;
i.e.
scancode = 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:
scancode = 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.
This patch changes the code to match my assumption (the generated scancode
should, however, not change).
[m.chehab@samsung.com: rebased and fixed the decoding error message]
Signed-off-by: David Härdeman <david@hardeman.nu>
CC: Patrick Boettcher <pboettcher@kernellabs.com>
Tested-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Diffstat (limited to 'include/media')
0 files changed, 0 insertions, 0 deletions