Re: em28xx: msi Digivox ATSC board id [0db0:8810]

["Frank Schäfer" <fschaefer.oss@googlemail.com>]

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