On Fri, 17 Dec 2010 06:18:31 +0100 Stefan Ringel <stefan.ringel@xxxxxxxx> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
