For the nec32 encoding, the kernel swaps in the "inverted" and normal
address and command. This might not be the most logical scheme.

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/common/ir-encode.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/utils/common/ir-encode.c b/utils/common/ir-encode.c
index c7e319eb..ccc75032 100644
--- a/utils/common/ir-encode.c
+++ b/utils/common/ir-encode.c
@@ -64,15 +64,10 @@ static int nec_encode(enum rc_proto proto, unsigned 
scancode, unsigned *buf)
                add_byte(~scancode);
                break;
        case RC_PROTO_NEC32:
-               /*
-                * At the time of writing kernel software nec decoder
-                * reverses the bit order so it will not match. Hardware
-                * decoders do not have this issue.
-                */
-               add_byte(scancode >> 24);
                add_byte(scancode >> 16);
-               add_byte(scancode >> 8);
+               add_byte(scancode >> 24);
                add_byte(scancode);
+               add_byte(scancode >> 8);
                break;
        }
 
-- 
2.11.0

Reply via email to