>> 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! _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
