Re: tm6000 and IR

[Dmitri Belimov <d.belimov@gmail.com>]

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