Re: tm6000 and IR

Dmitri Belimov
2010-12-17T06:08:58Z

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.

With my best regards, Dmitry.

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