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