Wednesday, July 6, 2011

Framebuffer Patch

I've narrowed down the issue with the distorted image seen in my previous post here. The issue was that the pixel format used by Android is a 16 bit format rather than the 32 bit default in QEMU, and it was never getting set correctly. After changing the pixel format, booting the Android image results in the below display. It is still unresponsive to any inputs, so that should be my next focus.

The patch used for this is commit 2b91f9d7 against my "android" branch. It forces QEMU to always use the 16-bit format, so it can't be used as a final solution, but it does demonstrate where the issue lies. In addition, this does not solve other issues with the framebuffer (the constant error message from the kernel about "goldfish_fb_pan_display: timeout wating for base update" and the lack of goldfish_fb_read/write calls when compared to the Android Emulator) but those issues appear to be a problem with the mechanisms that call the framebuffer functions rather than with the goldfish_fb code itself.

I'm still looking for the best way to incorporate this fix in QEMU without breaking compatibility with other QEMU guests.

1 comment:

  1. The best way to do that would be allow QEMU to create a default DisplayState that is not hard-coded to 640x480x32, as is currently the case.

    See the upstream dumb_display_init() in console.c which gets called when get_displaystate() is called _before_ machine initialization in vl.c.

    Because I wanted to minimize the changes from upstream in the Android emulator, I use a hack which is to modify vl-android.c to call "android_reset_display(width,height,depth)" just after the call to get_displaystate(). This function essentially scraps the default display surface, and replaces it with a version that has the right properties.

    A more correct, but more invasive, fix would be to modify console.c to allow the creation of a "dumb" display state of any size and depth instead, and have vl.c call this function instead of get_displaystate().

    Which width/height/depth parameters to use need to be passed on the command-line probably through new options, since this feature is currently unsupported.

    ReplyDelete