public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Antti Palosaari <crope@iki.fi>
Cc: Malcolm Priestley <tvboxspy@gmail.com>,
	linux-media@vger.kernel.org, Jarod Wilson <jarod@redhat.com>
Subject: NEC 32 bits RC codes - was: Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
Date: Wed, 23 Mar 2011 06:07:07 -0300	[thread overview]
Message-ID: <4D89B83B.1040307@redhat.com> (raw)
In-Reply-To: <4D89B23B.7000803@iki.fi>

Em 23-03-2011 05:41, Antti Palosaari escreveu:
> On 03/23/2011 01:00 AM, Mauro Carvalho Chehab wrote:
>> Em 22-03-2011 19:12, Malcolm Priestley escreveu:
>>> On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote:
> 
>>>> Anyhow, my opinion is still that we *should* make all NEC remotes as 32
>>>> bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For
>>>> example AF9015 current NEC handling is too complex for that reason... I
>>>> don't like how it is implemented currently.
>>>
>>> One of the reasons for using 32 bit was interference from other consumer
>>> remotes.  It appears, these near identical bubble remotes originate from
>>> a Chinese factory and supplied with the same product with completely
>>> different key mapping.
>>>
>>> I am not sure how many of these remotes are common to other devices.
>>
>> Drivers should get the 32 bit codes form NEC when hardware provides it.
>> What we currently do is to identify if the code has 16, 24 or 32 bits,
>> but it is probably better to always handle them as if they have 32 bits.
> 
> That's how af9015 driver handles it currently.
> 
> if (buf[14] == (u8) ~buf[15]) {
>     if (buf[12] == (u8) ~buf[13]) {
>         /* 16 bit NEC standard */
>         priv->rc_keycode = buf[12] << 8 | buf[14];
>     } else {
>         /* 24 bit NEC extended*/
>         priv->rc_keycode = buf[12] << 16 | buf[13] << 8 | buf[14];
>     }
> } else {
>     /* 32 bit NEC full scancode */
>     priv->rc_keycode = buf[12] << 24 | buf[13] << 16 | buf[14] << 8 | buf[15];
> }
> 
> I think there is no any better currently.

RC core does the same. I talked with Jarod, and we're thinking on just use 32 bits
for everything. There are two issues however:
	1) All NEC tables will need to be replaced. This affects userspace. Not sure
how to workaround it there, to allow userspace to do the right thing. New protocol type?
	2) Some hardware decoders only provide 16 bits for NEC.

Cheers,
Mauro

      reply	other threads:[~2011-03-23  9:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-13  1:35 [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions Malcolm Priestley
2011-03-22  0:17 ` Mauro Carvalho Chehab
2011-03-22  0:32   ` Malcolm Priestley
2011-03-22  0:40     ` Mauro Carvalho Chehab
2011-03-22 21:34       ` Malcolm Priestley
2011-03-22 22:57         ` Mauro Carvalho Chehab
2011-03-22  0:43     ` Antti Palosaari
2011-03-22 22:12       ` Malcolm Priestley
2011-03-22 23:00         ` Mauro Carvalho Chehab
2011-03-23  8:41           ` Antti Palosaari
2011-03-23  9:07             ` Mauro Carvalho Chehab [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=4D89B83B.1040307@redhat.com \
    --to=mchehab@redhat.com \
    --cc=crope@iki.fi \
    --cc=jarod@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=tvboxspy@gmail.com \
    /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