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

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

Am 11.12.2012 21:59, schrieb Antti Palosaari:
> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
>> 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 ?
>
> Yes, that is. I have said it "million" times I would like to see that
> implemented as a one single 4 byte NEC, but it is currently what it
> is. What I understand David Härdeman has done some work toward that
> too, but it is not ready.
> See current af9015 driver as example how driver makes decision which
> variant of NEC is used. You will need something similar. Read all 4
> NEC bytes from the hardware and then use driver to make decision which
> variant it is.

Yes, checking for inverted address and key code bytes would be a
possibility...
OTOH it's a kind of hack and I think this issue should be fixed in th rc
core.

A possible solution would be to add three new RC_TYPEs (e.g.
RC_TYPE_NEC_STD, RC_TYPE_NEC_EXT, RC_TYPE_NEC_FULL).
RC_TYPE_NEC can be kept for compatibility but should be marked as
deprecated.

Hmmm... thinking about it for some minutes... Why the hell do we bind rc
maps to protocols ?
A key map consists of pairs of a scan code and the corresponding key
code. But that's common to all protocols, right ?
So why do we restrict a keymap to a specific protocol ?
Ok, rc_type is a bit field, so a key map can be bound to multiple protocols.
But then we can't use it to configure the hardware driver, which is
exactly out problem here...

> I am quite sure em28xx hardware supports reading all 4 bytes, but if
> not, you will need to do some other tricks.

Yes, reading 4 bytes form the hardware seems to supported.

Devin, how does it works with reg 0x50=0x01 ?
Have I understood you right that it means the 32bit NEC protocol variant
is used ?
Can the key code be read as usual from regs 0x52-0x55 ?
Any changes in reg 0x51 ?
And for that matter - what's the meaning of bit 1 in reg 0x50 ? ;)

Regards,
Frank

>
> regards
> Antti
>