Bero, will you be available for tomorrow's hacking session?
bernhard.rosenkranzer at linaro.org
Sat Aug 27 19:45:30 UTC 2011
> OK, here's one preliminary theory after I dragged Jason to a conversation
> from his weekend in a vacation.
Thanks! Could have waited until Monday of course, but it's great to
have another starting point to work on over the weekend.
> There could be mis-use of the framebuffer's FBIOPUT_VSCREENINFO as a
> way to update the screen instead of using FBIOPAN_DISPLAY.
That's exactly what Android does in a couple of places, e.g.
system/core/init/logo.c, function fb_update() [that one actually calls
FBIOPUT_VSCREENINFO _twice_ to update the screen]
hardware/libhardware/modules/gralloc/framebuffer.cpp, function fb_post
This should be fairly easy to fix, but googling it, I found an
explanation from an upstream engineer on why they're doing it that way
-- apparently on some graphics drivers, FBIOPAN_DISPLAY does smooth
panning, which obviously isn't what you want for a simple screen
I'm definitely going to change it to see whether or not this is the
problem (and also to probably get a bit of a performance boost on
Panda) - but I wonder what hardware we're going to break with that.
Given other pieces of code (e.g. SDL) use FBIOPAN_DISPLAY for screen
refreshes, I think using that ioctl should be mostly safe.
> 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.
That is consistent with the messages I'm seeing in dmesg output.
Maybe (in addition to fixing userland) the driver should be a bit
smarter and not reinitialize the controller if it realizes the old and
new modes are actually the same, given Android is probably not the
only piece of code that uses FBIOPUT_VSCREENINFO, given apparently
some fb drivers interpret FBIOPAN_DISPLAY as something different...
More information about the linaro-dev