archive mirror
 help / color / mirror / Atom feed
From: Sean Young <>
To: John G <>
Subject: Re: scancodes identified as invalid (I found the problem)
Date: Mon, 22 Jul 2019 14:26:45 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi John,

On Mon, Jul 22, 2019 at 11:44:02AM +0000, John G wrote:
>  Hi Sean,
> Using s = 0x20df10ef, protocol_scancode_valid() will return false (meaning it is not a valid scancode).
> s>>24 = 0x00000020
> s>>16 = 0x000020df
> ~(0x20df) = 0xdf20
> ( 0x0020 ^ 0xdf20) = 0xdf00
> 0xdf00 & 0xff = 00 !=0 will return false (fails scancode check)
> I'm not sure I understand what is being checked, since any code between 0x0 and 0xffffffff should be valid for nec32.

So first of all, nec is divided into three sub-protocols: nec, nec-x and nec32.
This is done because there are a lot of dvb IR receivers which can only
decode nec, or only nec and nec-x.

So the way kernel nec decoder works means that if you transmit nec32:0x20df10ef,
it will be decoded as nec:0x20df.



ir-ctl is being pendantic about this and wants you to specify the protocol
the way it will be decode. How about the following output for ir-ctl:

$ ir-ctl -S nec32:0xef10c03f
warning: `nec32:0xef10c03f' will be decoded as `nec:0xefc0'

Does this make sense?

> Is this check really necessary? Maybe a -force option to bypass the scancode check? ;)
> I did try to send ir-ctl -S 0x2010, but the TV did not respond.
> I've only had success sending it the RAW version, which does look like the full 32-bit code.
> -----
> Ah! I just had a breakthrough!  
> I noticed the nec description you sent me to, has LSB being transmitted first.
> On a hunch, I reversed the bit order of the code, (ir-ctl -S 0x0408, instead of 0x2010), and bingo!  
> It make sense, really, because the raw code that works, is in LSB first order, so my error was (unintentionally) giving the hex code to ir-ctl, in raw/LSB order, instead of first converting it to Big Endian/MSB order. 
> So, it's still not clear why "any" 32-bit code can't be entered, but in any case, I'm able to control things now!
> Thank you for your support!

Please keep it on the list and please don't top-post.



> Kind regards,JohnG
>     On Sunday, July 21, 2019, 2:36:29 PM CDT, Sean Young <> wrote:  
>  Hi,
> On Fri, Jul 19, 2019 at 06:50:05AM -0500, JohnG wrote:
> > I have POWER_KEY scancodes, that work as RAW data with ir-ctl -s [file], but
> > are not working with ir-ctl -S:
> > 
> >     0x20df10ef (POWER_KEY for my LG tv)
> >     0x02FD48B7 (POWER_KEY for my Toshiba tv)
> As you can see here the
> nec protocol has an inverted address (2nd byte) and inverted command
> (3rd byte). The inverted values are not in regular nec scancodes for ir-ctl,
> as they are redundant.
> So the first values would be "ir-ctl -S nec:0x2010" and the second one
> "ir-ctl -s nec:0x0248".
> > rc6_mce:0x800f0410 works, as does nec32:0x800f0410 (though not
> > nec:0x800f0410), so it doesn't seem to be an issue with 32-bit codes.
> > 
> > I use AnalysIR, and it indicates the protocol is NEC for the above codes,
> > though indicates the protocol is NEC1.
> > 
> > 1) is there a description of the various protocols? (how can I know if I
> > should use nec or nec32, with a 32 bit value?)
> There isn't any documentation, although we could really use some. I'll try
> to write something up when I get some time. In the mean time, you
> can see a list of the protocols to and bitmask here:
> So the scancode_mask shows which bits are actually valid; if any bits
> outside of the mask are set, ir-ctl will say the scancode is invalid.
> So for nec any value between 0 and 0xffff is valid; necx it is 0 to 0xffffff
> and nec32 it is 0 to 0xffffffff.
> > 2) are my scancodes failing to work, because they are (possibly) NEC1
> > protocol?
> I'm not sure what the nec1 protocol is exactly. This sounds like a AnalysIR
> invention.
> > 
> > 3) if NEC1 is not the same as nec or nec32, is it scheduled to be added to
> > ir-ctl in the near future?
> Please let me know how you get on with the above.
> Thanks
> Sean

      parent reply	other threads:[~2019-07-22 13:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19 11:50 scancodes identified as invalid JohnG
2019-07-21 19:36 ` Sean Young
     [not found]   ` <>
2019-07-22  5:22     ` Sean Young
     [not found]   ` <>
2019-07-22 13:26     ` Sean Young [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: scancodes identified as invalid (I found the problem)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).