Hi! Am Sonntag, den 12.04.2009, 13:37 -0400 schrieb CityK: > Mauro Carvalho Chehab wrote: > > On Tue, 07 Apr 2009 23:02:43 -0400 > > CityK <cityk@xxxxxxxxxx> wrote: > > > > > >> Regarding the KS003 (& KS007; the other "mystery" chip): > >> > >> Upon further investigation of some info from a post from last year > >> (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html), > >> it appears that these (assuming that they are the same IC across the > >> various MSI, Leadtek & KWorld cards; and I believe that to be true) are > >> the "AT8PS54/S56" chip from "Feeling Technology" ... the datasheet for > >> that part is available through a google search .... probing further (as > >> I had never heard of FT before and so I looked them up), it looks like > >> FT renamed and/or upgraded the chip to the "FM8PS54/S56" ... the near > >> identical datasheet for that second version is also available: > >> http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05&Category=100018 > >> > > > > From what I've investigated, several of those IR chips are micro-controllers like > > the one you pointed. I've seen a few boards whose IR chip is not masked. On > > those, I always went into some micro-controller datasheet. > > > > Those IR's with a micro-controller have some software inside it to decode one IR > > protocol and generate scan-code sequences that can be received via GPIO or via > > I2C, depending on the firmware content. > > > > The datasheet of those chips are useless, since the behaviour of the > > device is programmed inside their ROM/EEPROM [1]. So, even being the same chip, > > you could have two "K007" devices with different firmwares, listening on > > different i2c addresses and eventually generating different scan-codes for the > > same IR. > > > > On the other hand, for USB devices and for bttv, saa7134 and cx88, there are > > some easy ways to monitor what i2c messages or GPIO pins are involved with IR. > > In general, the IR received messages generated by the firmware are some header, > > a scan code, a repeat key bit and a trailer. So, it is not hard to generate a > > get-key routine to get the scan code and the repeat bit from the protocol. > > > > That's why the modern ir-kbd-i2c approach is to select the proper IR parameters > > after binding the module, at the bridge driver. The bridge driver is the one > > who knows what's the IR scan code of the original IR (to set it as the > > default), and the proper get-key function. With the new i2c behaviour, the > > bridge driver can also specify the proper i2c address for each device. > > > > Cheers, > > Mauro > > > > [1] It doesn't seem to be practical for me to get their internal software.In > > general, such micro-controllers block EEPROM/ROM read of the software inside. > > If this is the case of this chip, the only remaining option to get the internal > > software would be to cut the plastic and try to see the state of each eeprom > > bit with the help of a good microscope. > > Anyway, assuming that there are some way to read the ROM content, in order to > > see the device behavior, one should remove the chip from the board, get the > > ROM/EEPROM content, write a disassembler for this processor, disassemble the > > code and analyse the results. This would be a real hard work, would take a lot > > of time, and I doubt that this would help to improve the driver, since we > > already know how to read scan codes from those devices. > > Thanks for the detailed response Mauro. I've actually been wondering > about whether the specific "KS00x" designation/label might refer to the > embedded firmware or to a dataline, so that thought is certainly > consistent with your description. Consistent with that, as from some first seen ever, the KS007 chip remotes seem to have always more keys than the KS003 ones. Cheers, Hermann -- 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
