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..
In the worst case scenario, I think we may have to revert the change from gtk-gl-area.c for now until the problem is root-caused. But you would see some rendering timeout in case the GTK window is in invisible state (like minimization). > Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context > > On 2/4/25 04:51, Kim, Dongwon wrote: > >> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context > >> > >> "Kim, Dongwon" <dongwon....@intel.com> writes: > >> > >>> Hi, > >>> > >>> The commit below could change the timing of drawing by making the > >>> drawing done at refresh cycle instead of via drawing event. So it > >>> looks like either dmabuf or client's framebuffer is being written > >>> and read at the same time. Hey, can you describe how the corruption > >>> looks like? Is it just garbage image with random noise or the actual > >>> frame with some > >> defects like tearing...? > >> > >> The terminal gets mirrored upside down and the mouse creates damage > >> as it moves about. > > > > I am wondering if this is reproducible without virgl and drm native > > context (like w/ sw rasterizer on the guest) as well. > > It looks like a problem with redraw areas, see video sample [1]. > > [1] > https://drive.google.com/file/d/13PN2sFoPsM2ox6_gf9GLXStbsZ27xlLy/view?u > sp=sharing > > It's reproducible without native context with a SW render using '-device > virtio- > vga,hostmem=8G,blob=on' > > -- > Best regards, > Dmitry
