On 2/6/25 01:13, Dmitry Osipenko wrote: > On 2/5/25 23:08, Dmitry Osipenko wrote: >>> Thanks for showing me the video. I will take a look and check what would go >>> wrong here. I kinda understand corruption may happen >>> in some scenario but I don't know what could cause the upside down image. >>> Do you have any idea?? Maybe the frame was temporarily replaced with >>> a mishandled texture that QEMU creates from the surface temporarily but I >>> am not sure.. >> No clue. Could be anything. Could be a GTK/Wayland bug, could be an >> obscure QEMU bug. GTK expert wanted here. > > Alright, it's bugged with "blob=on", but works with "blob=off". While I > don't see QEMU using blobs. Might be QEMU's bug then. >
Looked further at it. So QEMU was using blobs with "blob=on" and I was looking at a wrong place. Then I found that setting y0_top=true for dmabuf makes display to show upside down, but there is no rendering bug with it. Something redraws display with y0_top=true, while it should be y0_top=false. I couldn't figure out how it's related to the offending change. I also noticed that QEMU checks Wayland presence in early_gtk_display_init() and doesn't use EGL callbacks that are used for X11 display, but the y0_top logic looks the same. Interestingly, Windows should be using same display code paths as Wayland, but I don't have ability to test Windows. If nobody will be able to fix the bug soon, at least reverting the Wayland part will be good to do. -- Best regards, Dmitry
