qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 12/12] ui/console: call gfx_switch() even if the current s


From: Akihiko Odaki
Subject: Re: [PATCH v3 12/12] ui/console: call gfx_switch() even if the current scanout is GL
Date: Wed, 9 Mar 2022 18:32:00 +0900
User-agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

On 2022/03/09 18:26, Gerd Hoffmann wrote:
   Hi,
dpy_gfx_switch and dpy_gfx_update need to be called to finish the
initialization or switching of the non-OpenGL display. However, the proposed
patch only calls dpy_gfx_switch.

vnc actually does not need dpy_gfx_update because the vnc implementation of
dpy_gfx_switch implicitly does the work for dpy_gfx_update, but the model of
ui/console expects the two of dpy_gfx_switch and dpy_gfx_update is separated
and only calling dpy_gfx_switch violates the model. dpy_gfx_update used to
be called even in such a case before and it is a regression.

Well, no, the ->dpy_gfx_switch() callback is supposed to do everything
needed to bring the new surface to the screen.  vnc isn't alone here,
gtk for example does the same (see gd_switch()).

Yes, typically this is roughly the same an explicit dpy_gfx_update call
would do.  So this could be changed if it helps making the opengl code
paths less confusing, but that should be a separate patch series and
separate discussion.

take care,
   Gerd


Then ui/cocoa is probably wrong. I don't think it does the update when dpy_gfx_switch is called.

Please tell me if you think dpy_gfx_switch shouldn't do the implicit update in the future. I'll write a patch to do the update in cocoa's dpy_gfx_switch implementation otherwise.

Regards,
Akihiko Odaki



reply via email to

[Prev in Thread] Current Thread [Next in Thread]