From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-bk0-f46.google.com ([209.85.214.46]:43696 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755055Ab2LKUvY (ORCPT ); Tue, 11 Dec 2012 15:51:24 -0500 Received: by mail-bk0-f46.google.com with SMTP id q16so1848567bkw.19 for ; Tue, 11 Dec 2012 12:51:22 -0800 (PST) Message-ID: <50C79CD6.4060501@googlemail.com> Date: Tue, 11 Dec 2012 21:51:34 +0100 From: =?ISO-8859-1?Q?Frank_Sch=E4fer?= MIME-Version: 1.0 To: Antti Palosaari CC: Devin Heitmueller , Matthew Gyurgyik , Linux Media Mailing List Subject: Re: em28xx: msi Digivox ATSC board id [0db0:8810] References: <50B5779A.9090807@pyther.net> <50BE65F0.8020303@googlemail.com> <50BEC253.4080006@pyther.net> <50BF3F9A.3020803@iki.fi> <50BFBE39.90901@pyther.net> <50BFC445.6020305@iki.fi> <50BFCBBB.5090407@pyther.net> <50BFECEA.9060808@iki.fi> <50BFFFF6.1000204@pyther.net> <50C11301.10205@googlemail.com> <50C12302.80603@pyther.net> <50C34628.5030407@googlemail.com> <50C34A50.6000207@pyther.net> <50C35AD1.3040000@googlemail.com> <50C48891.2050903@googlemail.com> <50C4A520.6020908@pyther.net> <50C4BA20.8060003@googlemail.com> <50C4BAFB.60304@googlemail.com> <50C4C525.6020006@googlemail.com> <50C4D011.6010700@pyther.net> <50C60220.8050908@googlemail.com> <50C60772.2010904@googlemail.com> <50C6226C.8090302@iki! .fi> <50C636E7.8060003@googlemail.com> <50C64AB0.7020407@iki.fi> In-Reply-To: <50C64AB0.7020407@iki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org List-ID: Am 10.12.2012 21:48, schrieb Antti Palosaari: > On 12/10/2012 09:24 PM, Frank Schäfer wrote: >> Am 10.12.2012 18:57, schrieb Antti Palosaari: >>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote: >>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer >>>>> Adding a new property to the RC profile certainly seems to be the >>>>> cleanest solution. >>>>> Do all protocols have paritiy checking ? Otherwise we could add a new >>>>> type RC_TYPE_NEC_NO_PARITY. >>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull >>>>> for >>>>> other flags, too, in the future... >>>> >>>> It's probably also worth mentioning that in that mode the device >>>> reports four bytes, not two. I guess perhaps if parity is ignored it >>>> reports the data in some other format? You will probably have to do >>>> some experimentation there. ... >>> >>> Uh, current em28xx NEC implementation is locked to traditional 16 bit >>> NEC, where is hw checksum used. >>> >>> Implementation should be changed to more general to support 24 and 32 >>> bit NEC too. There is multiple drivers doing already that, for example >>> AF9015. >>> >> >> Hmm... are there and documents (, links, books, ...) where I can learn >> more about all those RC protocols ? > > Specification comes here: > NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols: > > 1) 16bit NEC standard, 1 byte address code, 1 byte key code > full 4 byte code: AA BB CC DD > where: > AA = address code > BB = ~address code > CC = key code > DD = ~key code > > checksum: > AA + BB = 0xff > CC + DD = 0xff > > 2) 24bit NEC extended, 2 byte address code, 1 byte key code > full 4 byte code: AA BB CC DD > where: > AA = address code (MSB) > BB = address code (LSB) > CC = key code > DD = ~key code > > 3) 32bit NEC full, 4 byte key code > full 4 byte code: AA BB CC DD > where: > AA = > BB = > CC = > DD = > > I am not sure if there is separate parts for address and key code in > case of 32bit NEC. See some existing remote keytables if there is any > such table. It is very rare protocol. 1) and 2) are much more common. > Many thanks. So the problem is, that we have only a single RC_TYPE for all 3 protocol variants and need a method to distinguish between them, right ? Regards, Frank > > regards > Antti > >