Hi If Apple use full 32-bit scancode we need full raw 32-bit keytable for compatibility. For this need rework all keytables and all keyread function for add scanmask configuration and rework single byte scancode code -> key << 8. Use scanmask and return IR reading bytes on real place. For tm6000 don't need restore full scancode Only address filter scanmask = 0xff00ff00; return byte[1] << 24 | byte[0] <<8 With my best regards, Dmitry. > 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@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. > > 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 -- 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
