Linux Media Controller development
 help / color / mirror / Atom feed
From: Malcolm Priestley <tvboxspy@gmail.com>
To: "David Härdeman" <david@hardeman.nu>
Cc: linux-media@vger.kernel.org
Subject: Re: lmedm04 NEC scancode question
Date: Sun, 30 Mar 2014 19:18:20 +0100	[thread overview]
Message-ID: <53385FEC.4050409@gmail.com> (raw)
In-Reply-To: <20140328003847.GA23351@hardeman.nu>

On 28/03/14 00:38, David Härdeman wrote:
> Hi Malcolm,
>
Hi David


> I'm trying to make sure that the extended NEC parsing is consistent
> across drivers and I have a question regarding
> drivers/media/usb/dvb-usb-v2/lmedm04.c
>
> In commit 616a4b83 you changed the scancode from something like this:
>
> 	ibuf[2] << 24 | ibuf[3] << 16 | ibuf[4] << 8 | ibuf[5]
>
> into:
>
> 	if ((ibuf[4] + ibuf[5]) == 0xff) {
> 		key = ibuf[5];
> 		key += (ibuf[3] > 0)
> 			? (ibuf[3] ^ 0xff) << 8 : 0;
> 		key += (ibuf[2] ^ 0xff) << 16;
>
> which can be written as:
>
> 	(ibuf[2] ^ 0xff) << 16 |
> 	(ibuf[3] > 0) ? (ibuf[3] ^ 0xff) << 8 : 0 |
> 	ibuf[5]
>
> At the same time the keymap was changed from (one example from each
> type):
>
> 	0xef12ba45 = KEY_0
> 	0xff40ea15 = KEY_0
> 	0xff00e31c = KEY_0
These original key maps need to restored for 32 bit.

>
> into:
>
> 	0x10ed45   = KEY_0 (0x10ed = ~0xef12; 0x45 = ~0xba)
> 	0xbf15     = KEY_0 (0xbf = 0x00bf = ~0xff40; 0x15 = ~0xea)
> 	0x1c       = KEY_0 (0x1c = 0x001c; this is a NEC16 coding?)
>
Bits 8~23 are inverted on the key map because they are shifted >> 8.


Bits 8~15 are removed from the scan code.

> I am assuming (given the ^ 0xff) that the hardware sends inverted bytes?
> And that the reason ibuf[5] does not need ^ 0xff is that it already is
> the inverted command (i.e. ibuf[5] == ~ibuf[4]).
>
> To put it differently:
>
>          ibuf[2] = ~addr         = not_addr;
>          ibuf[3] = ~not_addr     = addr;
>          ibuf[4] = ~cmd          = not_cmd;
>          ibuf[5] = ~not_cmd      = cmd;
>
> And the scancode can then be understood as:
>
> 	addr << 16 | not_addr << 8 | cmd
>
> Except for when addr = 0x00 in which case the scancode is simply NEC16:
>
> 	0x00 << 8 | cmd
>
> Is my interpretation correct?
>
No inverting.

At the time of the patch I couldn't get the 32 bit code to work 
correctly on rc_core so it was assumed to be 24 bit.

I have tested the patch series...

Is there a patch missing?  I get build error from ati_remote.c and
imon.c

error: too few arguments to function 'rc_g_keycode_from_table'

Anyway, I removed the errors.

Just needs the inverting removed and the original 32 bit key maps to work.

Regards


Malcolm

  reply	other threads:[~2014-03-30 18:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28  0:38 lmedm04 NEC scancode question David Härdeman
2014-03-30 18:18 ` Malcolm Priestley [this message]
2014-03-30 20:59   ` David Härdeman

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=53385FEC.4050409@gmail.com \
    --to=tvboxspy@gmail.com \
    --cc=david@hardeman.nu \
    --cc=linux-media@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