On 03/01/2015 06:03 PM, Michael Mrozek wrote:
Hi,
Anyways, this is only of temporary need. ED already has a batch of unprogrammed panels, while for series production he was promised to get them programmed at the factory.
Unfortunately this whole setup brings back bad memories of what we have with pandora nubs, where the microcontrollers are only readable and not programmable. If OMAP could reflash the micros, we could have updated them after release, and maybe it would made sense to start an reverse engineering project to create alternative firmware. As it is now absolutely nothing can be done to improve the nubs on pandora.
It's not good if we won't be able to program the panel, like updating gamma curves, something we already do on pandora. Or is that just for the init sequence that has problems?
The main usage for the Solomon chip is not the rotation but powersaving and color correction features. So while we can't program the panel, we can use the chip to correct gamma curves, etc.
There are plenty of possibilities for this to fail, like having some important setting wrong, for example setting the panel to 16bit mode and not noticing it (just an example, I don't know if such mode actually exists). There is nothing Solomon would be able to do if such thing happened to improve the color depth, as the panel would be destroying parts of incoming data. Or some tolerance issue like we had with pandora's audio where most boards worked fine, but some did not, which turned out to be wrong clock edge setting that I could fix in the kernel. Imagine if it wasn't possible to fix it in software, many boards would have to be thrown away...
I don't think we have the resources to prove that the settings we choose are 100% correct. Although maybe BOE can help with that, I don't know...
Grazvydas