Re: tm6000 and IR

Stefan Ringel
2010-12-17T05:18:34Z

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.
>> 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.
>>>>>> Then the function call usb_set_interface in tm6000_video, can
>>>>>> write for example:
>>>>>>
>>>>>> stop_ir_pipe
>>>>>> usb_set_interface
>>>>>> start_ir_pipe
>>>>> Ok, I'll try.
>>> See dmesg. I was add function for start/stop interrupt urbs
>>> All works well.
>>>
>>> With my best regards, Dmitry.