From: James Hogan <james@albanarts.com>
To: "David Härdeman" <david@hardeman.nu>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] winbond-cir: fix extended NEC scancode encoding
Date: Fri, 26 Nov 2010 21:37:49 +0000 [thread overview]
Message-ID: <20101126213749.GB21473@gandalf> (raw)
Hi,
This changes the scancode encoding behaviour for extended NEC on
winbond-cir by swapping the address bytes. This makes it consistent with
the software NEC decoder in drivers/media/IR, but changes the scancodes
for extended NEC. Comments in the code suggest NEC wasn't tested, and
I'm not sure if it has any users using extended NEC, so hopefully this
won't be a problem?
Note: i'm not able to test this patch other than compiling it.
Thanks
James
--
Swap the placement of the address bytes in the scancodes for extended
NEC in winbond-cir.
After comparing the extended NEC scancode construction of the software
NEC decoder (in media/IR) and winbond-cir it appears winbond-cir is
putting the two address bytes the wrong way around.
Here's how the decoders previously generated scancodes:
winbond-cir normal NEC: msb [ 0x0, 0x0, address1, command ] lsb
soft normal NEC: msb [ 0x0, 0x0, address1, command ] lsb
winbond-cir extended NEC: msb [ 0x0, address2, address1, command ] lsb
soft extended NEC: msb [ 0x0, address1, address2, command ] lsb
A NEC data sheet [1] describes the first byte (address1) of extended NEC
as 'Higher 8 bits of custom code' and the second byte (address2) as
'Lower 8 bits of custom code'.
[1] http://www.datasheetcatalog.org/datasheet/nec/UPD6122G-002.pdf
Signed-off-by: James Hogan <james@albanarts.com>
---
drivers/input/misc/winbond-cir.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/misc/winbond-cir.c b/drivers/input/misc/winbond-cir.c
index 64f1de7..01a9069 100644
--- a/drivers/input/misc/winbond-cir.c
+++ b/drivers/input/misc/winbond-cir.c
@@ -851,8 +851,8 @@ wbcir_parse_nec(struct device *dev, struct wbcir_data *data)
* and Command2 was the inverse of Command1 and were used as
* an error check.
*
- * With NEC extended, Address1 is the LSB of the Address and
- * Address2 is the MSB, Command parsing remains unchanged.
+ * With NEC extended, Address1 is the MSB of the Address and
+ * Address2 is the LSB, Command parsing remains unchanged.
*
* A repeat message is coded as:
* Leader - 9 ms burst
@@ -916,7 +916,7 @@ wbcir_parse_nec(struct device *dev, struct wbcir_data *data)
/* Check for extended NEC protocol */
address = address1;
if (address1 != ~address2)
- address |= address2 << 8;
+ address = address << 8 | address2;
scancode = address << 8 | command1;
--
1.7.3.2
reply other threads:[~2010-11-26 21:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101126213749.GB21473@gandalf \
--to=james@albanarts.com \
--cc=david@hardeman.nu \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox