Shortly after I said my VM was running fine with freshly installed
drivers so that this bug could be closed, it started freezing up again.
I followed your plan to git bisect between v9.0.0 and v9.1.0.
For each iteration of the bisection, I did:
- buile the executable
(make clean; ../configure --prefix=/usr/ --target-list=x86_64-softmmu
--disable-tools; ninja qemu-system-x86_64)
- started the VM using virt-manager (to make libvirt use the compiled
qemu-system-x86_64, run 'sudo virsh edit [VM-NAME]' and set the
<emulator> variable to the path to the executable and save the new
configuration; note that the executable must already exist when you
edit the domain); Video display is set to QXL
- logged in and started firefox (just to give it something to do)
- waited a few minutes then tried to start something else, usually a
File Explorer instance. If the UI froze, 'git bisect bad', otherwise
'git bisect good'
After about 10 iterations, I got this:
4bba839808bb1c4f500a11462220a687b4d9ab25 is the first bad commit
commit 4bba839808bb1c4f500a11462220a687b4d9ab25
Author: Akihiko Odaki <akihiko.od...@daynix.com>
Date: Mon Jul 15 14:25:45 2024 +0900
ui/console: Remove dpy_cursor_define_supported()
Remove dpy_cursor_define_supported() as it brings no benefit today and
it has a few inherent problems.
All graphical displays except egl-headless support cursor composition
without DMA-BUF, and egl-headless is meant to be used in conjunction
with another graphical display, so dpy_cursor_define_supported()
always returns true and meaningless.
Even if we add a new display without cursor composition in the future,
dpy_cursor_define_supported() will be problematic as a cursor display
fix for it because some display devices like virtio-gpu cannot tell the
lack of cursor composition capability to the guest and are unable to
utilize the value the function returns. Therefore, all non-headless
graphical displays must actually implement cursor composition for
correct cursor display.
Another problem with dpy_cursor_define_supported() is that it returns
true even if only some of the display listeners support cursor
composition, which is wrong unless all display listeners that lack
cursor composition is headless.
Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Phil Dennis-Jordan <p...@philjordan.eu>
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-ID: <20240715-cursor-v3-4-afa5b9492...@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
hw/display/qxl-render.c | 4 ----
hw/display/vmware_vga.c | 6 ++----
include/ui/console.h | 1 -
ui/console.c | 13 -------------
4 files changed, 2 insertions(+), 22 deletions(-)
I'm hoping this tells you something useful. I would be very happy to
do any testing you need.
Hank
On Tue, 8 Oct 2024 08:38:43 +0300 Michael Tokarev <m...@tls.msk.ru> wrote:
> 08.10.2024 04:26, Hank Knox wrote:
> > I found a fix!
> >
> > I looked a little more carefully at the bug report you referenced
and saw something about updated virtio drivers so I downloaded and mounted
> > virtio-win-0.1.262.iso as a CD on the Windows VM, fired it up,
installed virtio-win-x64.msi and virio-win-guest-tools.exe, closed
Windows, set the
> > Video to QXL, restarted Windows, and voilà, it works just fine. So
the problem isn't with QEMU but with out-of-date or overwritten Windows
drivers.
> > You can close this bug now.
>
> Oh wow! :)
>
> Well. Somehow checking for the drivers is the very first step to do
for me.
> Not even the first, it is a "pre-debugging" step, like a step zero,
it occurs
> automatically before doing anything else. So I assumed you obviously
did that
> step zero and didn't dare to ask :)
>
> Congratulations! :)
>
> And I think now you see how interesting things might turn, and you
don't have
> any reasons to be jealous anymore ;)
>
> > Thanks for all your help with this. Maybe another time we'll get to
bisect a git repo together...
>
> You're welcome.
>
> Thanks,
>
> /mjt
>
>
--
Hank Knox, FRSC
Schulich School of Music of
McGill University (retired)
Montreal, QC
