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