On 2025/05/13 2:01, Kim, Dongwon wrote:
Subject: Re: [PATCH v2 12/14] ui/gtk-gl-area: Remove extra draw call in refresh
On 2025/05/10 21:12, Dmitry Osipenko wrote:
On 5/10/25 07:52, Akihiko Odaki wrote:
On 2025/05/06 21:57, Alex Bennée wrote:
From: Dongwon Kim <dongwon....@intel.com>
This partially reverts commit
77bf310084dad38b3a2badf01766c659056f1cf2
which causes some guest display corruption when gtk-gl-area is used
for GTK rendering (e.g. Wayland Compositor) possibly due to
simulataneous accesses on the guest frame buffer by host compositor
and the guest.
Simply reverting the part of the commit may re-introduce the problem
the commit tried to solve, which will be a regression as the commit
is already included in releases.
I guess the problem is that the gl_block callback of GraphicHwOps is
not properly implemented and it is what should be fixed.
The reverted commit made QEMU GTK GUI unusable under Wayland. It was
fixing problem which requires very specific QEMU setup, while breaking
generic setups. The offending change should be reverted as it
introduced a bigger problem. A proper solution should be found,
meanwhile QEMU GTK under Wayland should be restored, IMO.
For the reference see [1]. First bug reports about a mirrored display
problem were made to me on IRC a year ago and the root of the problem
was identified only couple months ago.
[1]
https://lore.kernel.org/qemu-devel/5aedf1ad-d9b0-4edb-a050-f3d9bee9bcc
b...@collabora.com/
That describes the context well. It should also be described with an inline
comment so that we will not lose track of the known problem.
[Kim, Dongwon] Do you mean we should have this info in the commit message?
A comment in the code is better.
A description of the current version of the code should be left as a
comment so that readers can find it without git blame.
The commit message is suited for a description of the old version of
code (e.g., a bug fixed by the commit) or a comparison between the old
and new version; leaving them as comments will infinitely increase the
amount of the code.
In this case, it is about a problem with the current version so it
should be written as a comment.
As of today, the GTK problem isn't understood.
If your guess about simultaneous accesses on the guest frame buffer is correct,
it's a bug of the emulated device, not GTK.
[Kim, Dongwon] "Simultaneous accesses" was just a guess. This problem needs to
be debugged further.
BTW, the problem the original commit was trying to fix is some lockup due to
suspended rendering on
minimized or hidden GTK window. But according to Dmitry, this case wasn't hit
in his setup with wayland
compositor so I assume the risk of not having an extra draw in gtk-gl-area
would be low.
It is better to describe the estimation of the risk in the comment too.
Regards,
Akihiko Odaki
