> 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. > > > > >> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context > >> > >> Dmitry Osipenko <dmitry.osipe...@collabora.com> writes: > >> > >> > On 1/27/25 19:17, Alex Bennée wrote: > >> > ... > >> >> I'm still seeing corruption with -display gtk,gl=on on my x86 > >> >> system BTW. I would like to understand if that is a problem with > >> >> QEMU, GTK or something else in the stack before we merge. > >> > > >> > I reproduced the display mirroring/corruption issue and bisected it > >> > to the following commit. The problem only happens when QEMU/GTK > >> > uses Wayland display directly, while previously I was running QEMU > >> > with XWayland that doesn't have the problem. Why this change breaks > >> > dmabuf displaying with Wayland/GTK is unclear. > >> > >> Ahh that makes sense - I obviously forgot to mention I'm running > >> sway/wayland across both machines. > >> > >> > Reverting commit fixes the bug. > >> > > >> > +Dongwon Kim +Vivek Kasireddy > >> > > >> > commit 77bf310084dad38b3a2badf01766c659056f1cf2 > >> > Author: Dongwon Kim <dongwon....@intel.com> > >> > Date: Fri Apr 26 15:50:59 2024 -0700 > >> > > >> > ui/gtk: Draw guest frame at refresh cycle > >> > > >> > Draw routine needs to be manually invoked in the next refresh > >> > if there is a scanout blob from the guest. This is to prevent > >> > a situation where there is a scheduled draw event but it won't > >> > happen bacause the window is currently in inactive state > >> > (minimized or tabified). If draw is not done for a long time, > >> > gl_block timeout and/or fence timeout (on the guest) will happen > >> > eventually. > >> > > >> > v2: Use gd_gl_area_draw(vc) in gtk-gl-area.c > >> > > >> > Suggested-by: Vivek Kasireddy <vivek.kasire...@intel.com> > >> > Cc: Gerd Hoffmann <kra...@redhat.com> > >> > Cc: Marc-André Lureau <marcandre.lur...@redhat.com> > >> > Cc: Daniel P. Berrangé <berra...@redhat.com> > >> > Signed-off-by: Dongwon Kim <dongwon....@intel.com> > >> > Acked-by: Marc-André Lureau <marcandre.lur...@redhat.com> > >> > Message-Id: <20240426225059.3871283-1-dongwon....@intel.com> > >> > >> > >> Maybe a race on: > >> > >> QemuDmaBuf *dmabuf = vc->gfx.guest_fb.dmabuf; ? > >> > >> -- > >> Alex Bennée > >> Virtualisation Tech Lead @ Linaro > > -- > Alex Bennée > Virtualisation Tech Lead @ Linaro
