[android] renogotiation of pixel formats is not supported, leading to potential stride/pixelformat issues

[Kevin DuBois]

Some drivers will call android's perform hook with: NATIVE_WINDOW_SET_BUFFERS_FORMAT. In the case that the pixel formats are the same depth, we accommodate this by just setting the format to the newly-requested format. (ie, mir_pixel_format_rgbx_8888 to mir_pixel_format_rgba_8888 is accommodated, as no reallocation is needed).

However, we've encountered a device that will try to set the format to HAL_PIXEL_FORMAT_RGB_888 when mir has selected HAL_PIXEL_FORMAT_RGBX_8888. Since we're going from a 32 bit format to a 24 bit format, the stride information becomes incorrect.

[Kevin DuBois (kdub)]

Can be managed more easily with NBS, might be worth working on post 0.23

[Kevin DuBois (kdub)]

Don't actually know of a currently supported device that does this. I suppose this is in progress with the NBS transition.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ratchanan Srirattanamet (peat-new)]

Dear everyone in this bug,

This seems to also happen in Fairphone 2 in the client context. Could anyone explain more about this bug if this bug is talking about the client or the server?

[Daniel van Vugt (vanvugt)]

It's certainly a bug in Mir and not the client apps. Whether it's a bug in libmirclient or libmirserver and friends I think is not relevant.

But good news: We're looking at solving Mir's woes with EGL vs pixel format soon. In the new APIs we're releasing this year, Mir will use EGL more natively and not require that you know or specify the pixel format for that. So with some luck, the bug might go away without any additional effort.

[Daniel van Vugt (vanvugt)]

The Android platform was deleted from lp:mir at revision 4155.