Commen=
t # 5
on bug 10933=
0
from Ilia Mirkin
As per my comments on IRC, I think this is a wlroots bug:
drm_connector_set_mode calls init_drm_plane_surfaces (which in turn creates=
a
gbm surface) with GBM_FORMAT_XRGB8888. Flipping that to ARGB8888 resolves t=
he
issue.
As per my understanding, the config has to match the surface format, otherw=
ise
you get stuff like this. (At the extreme, imagine one said RGB10A2.)
The more detailed issue is that the winsys fb calls dri2_drm_image_get_buff=
ers
(via the getBuffers loader API call), which in turn uses the surface's form=
at
to create a backing bo. That format is XRGB8888, which becomes
PIPE_FORMAT_BGRX8888_UNORM. The pipe_surface also has this format. However =
the
GL believes that the format should be MESA_FORMAT_BGRA8888 (since that's wh=
at
the config said), and since that matches the glReadPixels format, decides it
can just do a memcpy.
Perhaps the pipe_surface should ignore the resource's format in this case, =
but
that's not how the current logic flows. In st_framebuffer_validate, it calls
u_surface_default_template which copies the format out of the given resourc=
e.
AFAIK having mismatches between surface format and config format is really =
bad
though, and not really supported. But I'm not a gbm API expert.