Re: tm6000 and IR

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Hi Dmitri/Stefan,

Em 17-12-2010 05:08, Dmitri Belimov escreveu:
> On Fri, 17 Dec 2010 06:18:31 +0100
> Stefan Ringel <stefan.ringel@arcor.de> wrote:
> 
>> Am 17.12.2010 02:46, schrieb Dmitri Belimov:
>>> Hi Stefan
>>>
>>>> Am 16.12.2010 10:38, schrieb Dmitri Belimov:
>>>>> Hi
>>>>>
>>>>>>> I think your mean is wrong. Our IR remotes send extended NEC it
>>>>>>> is 4 bytes. We removed inverted 4 byte and now we have 3 bytes
>>>>>>> from remotes. I think we must have full RCMAP with this 3 bytes
>>>>>>> from remotes. And use this remotes with some different IR
>>>>>>> recievers like some TV cards and LIRC-hardware and other. No
>>>>>>> need different RCMAP for the same remotes to different IR
>>>>>>> recievers like now.
>>>>>> Your change doesn't work with my terratec remote control !!
>>>>> I found what happens. Try my new patch.
>>>>>
>>>>> What about NEC. Original NEC send
>>>>> address (inverted address) key (inverted key)
>>>>> this is realy old standart now all remotes use extended NEC
>>>>> (adress high) (address low) key (inverted key)
>>>>> The trident 5600/6000/6010 use old protocol but didn't test
>>>>> inverted address byte.
>>>>>
>>>>> I think much better discover really address value and write it to
>>>>> keytable. For your remotes I add low address byte. This value is
>>>>> incorrent but usefull for tm6000. When you found correct value
>>>>> update keytable.
>>>>>
>>>> That is not acceptable. Have you forgotten what Mauro have written?
>>>> The Terratec rc map are use from other devices.
>>> NO
>>> The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module.
>>> My patch didn't kill support any other devices.
>> That is not true.
> 
> I search "RC_MAP_NEC_TERRATEC_CINERGY_XS" on FULL linux kernel sources.
> And found this string in:
> include/media/rc-map.h
> drivers/staging//tm6000/tm6000-cards.c
> drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c
> 
> No any other devices didn't use this keymap.
> 
>>>> The best are only the
>>>> received data without additional data. And I think the Trident chip
>>>> send only compatibly data (send all extended data like standard
>>>> data). The device decoded the protocols not the driver.
>>> You can't use this remotes with normal working IR receivers because
>>> this receivers returned FULL scancodes. Need add one more keytable.
>>>
>>> 1. With my variant we have one keytable of remote and some
>>> workaround in device drivers. And can switch keytable and remotes
>>> on the fly (of course when keytable has really value and device
>>> driver has workaround)
>>>
>>> 2. With your variant we have some keytables for one remote for
>>> different IR recevers. Can't use incompatible keytable with other
>>> IR recievers. It is black magic for understanding what remotes is
>>> working with this hardware.
>>>
>>> I think my variant much better.
>>>
>>> With my best regards, Dmitry.
>>>
>> I think your variant is bad.
> 
> Mauro we need your opinion about this question.

I'm c/c Jarod, as he has a similar issue with some NEC-based boards 
(Apple "variant").

I also have experienced some cases where the NEC protocol in-hardware
decoder can provide only part of the NEC "extended" range.

I don't have a clear opinion about this issue, but I think that putting
all our brains to think about that, we may have a solution for it.

Let me summarize the issues. Please complete/correct me if is there anything
else.

1) NEC original format is 16 bits. However, some variants use 24 bits for it
(it is called, currently, NEC extended). A few other manufacturers, like Apple,
defines NEC protocol with 32 bits, removing both address and command checksums.

2) NEC raw decoder is capable of decoding the entire NEC code, but it only
accepts 16 or 24 bits, returning the scan code as:

	scancode = address << 8 | command;

for 16 bits, and:

	scancode = address << 16 | not_address <<  8 | command;

for 24 bits. There were some proposals to extend it to something like:

	scancode = address << 24 | not_address << 16 | not_command << 8 | command;
	(or some other bit order)

Or just return the complete 32 bits even for the original NEC protocol. However,
changing it will break the existing userspace decoding tables.

Another way would be to store the length of the scancode, using it as well during
the scancode->keycode translation.

But no patches were merged yet.

3) Some hardware decoders can't return the complete NEC address. There are variants
that returns 8 bits, others that returns 16 bits, and others that return the complete
code.

For hardware that returns only 8 bits, we currently address the issue by using a 
scancode mask. When "scanmask" is set at the rc structs, the scancode->keycode
logic will consider only the bits that are in the mask.

4) Some hardware filters the NEC address, returning only the codes for
some specific vendors.

Despite all discussions, we didn't reach an agreement yet.

There are some points to consider whatever solution we do:

1) A keycode table should be able to work with a generic raw decoder. So, on all
drivers, the bit order and the number of bits for a given protocol should be the same;

2) we should avoid to cause regressions on the existing definitions.

That's said, suggestions to meet the needs are welcome.

Thanks,
Mauro