So this shows the problem is triggered by the priority order of supported pixel formats the Android platform returns. Mir's Android platform is returning the correct values in the correct order, but it's different to desktops, and that's enough to trigger this bug in Xorg.
It remains to be seen if the problem is an issue in Xorg that's always been there, or just something that Xmir is failing to initialize correctly.
Mir's Android graphics platform unfortunately does not support the same pixel formats as desktop that would avoid this bug. However adding ShmBuffer support to the Android platform would allow it to support all such pixel formats (and solve other bugs like the corruption issues).
Minor success. I've made a test available that you can use to replicate the bug using a desktop: /git.launchpad. net/~xmir- team/xorg- server/ +git/xmir/ commit/ ?id=637f0971b19 1c9fbdc459f3fdb 7ba5bc479b84be
https:/
So this shows the problem is triggered by the priority order of supported pixel formats the Android platform returns. Mir's Android platform is returning the correct values in the correct order, but it's different to desktops, and that's enough to trigger this bug in Xorg.
It remains to be seen if the problem is an issue in Xorg that's always been there, or just something that Xmir is failing to initialize correctly.
Mir's Android graphics platform unfortunately does not support the same pixel formats as desktop that would avoid this bug. However adding ShmBuffer support to the Android platform would allow it to support all such pixel formats (and solve other bugs like the corruption issues).