The framebuffer is working all right under Ubuntu, so I assume there could be some mis-use, esp. the omapfb extends some of the framebuffer API and we have no idea what impact that will have on top of i.MX5' fb. And FYI - the framebuffer works all right as well with Adeneo's rootfs (a 3rd party that helps Freescale w/ Android on i.MX5)
Sure, but something up with Android and we need help fixing it.
Yves,
Do you have a PoC for the framebuffer driver owner at Freescale?
Jason is the owner for the fb driver and he's part of the landing team. That does _not_ necessarily mean he knows how to fix this issue.
And the key point here is: you have no idea if this _is_ a framebuffer driver issue before any analysis is done. Esp. because the framebuffer is working all right under ubuntu. And your Android team should have better idea how fb is integrated in Android, and have a better position to first debug this issue until the framebuffer driver can be blamed.
No ones blaming we're just getting things together to start debuggingi the issue. We need to get everyone in the room so that we can ask the right questions.
OK, here's one preliminary theory after I dragged Jason to a conversation from his weekend in a vacation.
There could be mis-use of the framebuffer's FBIOPUT_VSCREENINFO as a way to update the screen instead of using FBIOPAN_DISPLAY. The former ioctl could take significant amount of time re-calculating the timing assuming resolution/color depth changes, and re-initializing the controller for a new mode, and that could result in screen blinking. Please check your Android code against this theory.
We will do hands-on debugging from next week. Thank you!