linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Young <sean@mess.org>
To: John G <johngo7470@yahoo.com>
Cc: linux-media@vger.kernel.org
Subject: Re: scancodes identified as invalid (I found the problem)
Date: Mon, 22 Jul 2019 14:26:45 +0100	[thread overview]
Message-ID: <20190722132645.5wevuv2d6opoeitw@gofer.mess.org> (raw)
In-Reply-To: <1881197532.5237588.1563795842895@mail.yahoo.com>

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.

See:
https://git.linuxtv.org/media_tree.git/tree/include/media/rc-core.h#n355

and:

https://git.linuxtv.org/media_tree.git/tree/drivers/media/rc/ir-nec-decoder.c#n134

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.

Thanks

Sean

> 
> Kind regards,JohnG
> 
> 
>     On Sunday, July 21, 2019, 2:36:29 PM CDT, Sean Young <sean@mess.org> 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 https://www.sbprojects.net/knowledge/ir/nec.php 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 irdb.tk 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:
> 
> https://git.linuxtv.org/v4l-utils.git/tree/utils/common/ir-encode.c#n344
> 
> 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]   ` <1981366943.5122868.1563752034290@mail.yahoo.com>
2019-07-22  5:22     ` Sean Young
     [not found]   ` <1881197532.5237588.1563795842895@mail.yahoo.com>
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:
  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=20190722132645.5wevuv2d6opoeitw@gofer.mess.org \
    --to=sean@mess.org \
    --cc=johngo7470@yahoo.com \
    --cc=linux-media@vger.kernel.org \
    --subject='Re: scancodes identified as invalid (I found the problem)' \
    /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

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).