| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTOURBUG |
Comment # 5
on bug 109330
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 the issue. As per my understanding, the config has to match the surface format, otherwise 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_buffers (via the getBuffers loader API call), which in turn uses the surface's format 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 what 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 resource. 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.
You are receiving this mail because:
- You are the assignee for the bug.
- You are the QA Contact for the bug.
_______________________________________________ Nouveau mailing list Nouveau@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/nouveau
