| Message ID | 20241006234353.3201037-1-dmitry.osipenko@collabora.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | GTK/SDL fixes for a black screen displayed by virtio-gpu | expand |
07.10.2024 02:43, Dmitry Osipenko wrote: > Hi, > > This patchset fixes black screen displayed by Qemu using virtio-gpu. > There is a race condition bug with a timer that disables display output > after it has been enabled by virtio-gpu. The problem is reproducible > by running Qemu with a disabled GL vsync. Note vsync is disabled for > SDL display by default. > > Dmitry Osipenko (2): > ui/sdl2: Don't disable scanout when display is refreshed > ui/gtk: Don't disable scanout when display is refreshed Is it a -stable material? Myself I haven't seen this prob so far, so it might be not worth the effort. Also, any idea when the prob has been introduced (or since when it has become real)? Thanks, /mjt
On 10/7/24 22:26, Michael Tokarev wrote: > 07.10.2024 02:43, Dmitry Osipenko wrote: >> Hi, >> >> This patchset fixes black screen displayed by Qemu using virtio-gpu. >> There is a race condition bug with a timer that disables display output >> after it has been enabled by virtio-gpu. The problem is reproducible >> by running Qemu with a disabled GL vsync. Note vsync is disabled for >> SDL display by default. >> >> Dmitry Osipenko (2): >> ui/sdl2: Don't disable scanout when display is refreshed >> ui/gtk: Don't disable scanout when display is refreshed > > Is it a -stable material? Myself I haven't seen this prob so far, so > it might be not worth the effort. Also, any idea when the prob has been > introduced (or since when it has become real)? The problem is reproducible with a stable Qemu. With SDL display it may require many retries to repro, but with GTK display + vblank_mode=0 it happens all the time. Don't know when exactly it was introduced, but will become much easier to hit it with the upcoming changes to Qemu. Judging by the git blame, problem always existed, perhaps nobody payed attention to it in the past. Up to maintainers to decide whether it's worth having these patches in stable, to me it's not worthwhile because normally nobody would run Qemu with vblank_mode=0. And you won't notice the problem if you're running desktop session in the guest because it will re-enable scanout on startup.
07.10.2024 23:19, Dmitry Osipenko wrote: >> Is it a -stable material? Myself I haven't seen this prob so far, so >> it might be not worth the effort. Also, any idea when the prob has been >> introduced (or since when it has become real)? > > The problem is reproducible with a stable Qemu. With SDL display it may Which stable qemu do you mean? We've 4 currently active/supported stable series - 7.2.x, 8.2.x, 9.0.x, 9.1.x :) > require many retries to repro, but with GTK display + vblank_mode=0 it > happens all the time. Don't know when exactly it was introduced, but > will become much easier to hit it with the upcoming changes to Qemu. what is vblank_mode=0 anyway, how to turn it on/off ? Do you mean setting this variable in environment when launching qemu? Thanks, /mjt
On 10/7/24 23:48, Michael Tokarev wrote: > 07.10.2024 23:19, Dmitry Osipenko wrote: >>> Is it a -stable material? Myself I haven't seen this prob so far, so >>> it might be not worth the effort. Also, any idea when the prob has been >>> introduced (or since when it has become real)? >> >> The problem is reproducible with a stable Qemu. With SDL display it may > > Which stable qemu do you mean? We've 4 currently active/supported stable > series - 7.2.x, 8.2.x, 9.0.x, 9.1.x :) I check only the v8, v7 shouldn't differ from v8 in regards to the display code, AFAICT. >> require many retries to repro, but with GTK display + vblank_mode=0 it >> happens all the time. Don't know when exactly it was introduced, but >> will become much easier to hit it with the upcoming changes to Qemu. > > what is vblank_mode=0 anyway, how to turn it on/off ? > > Do you mean setting this variable in environment when launching qemu? Yes, you'll need to set this env var