qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Akihiko Odaki <akihiko.odaki@gmail.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH v3 12/12] ui/console: call gfx_switch() even if the current scanout is GL
Date: Tue, 8 Mar 2022 23:42:00 +0900	[thread overview]
Message-ID: <1fa142fb-7988-db25-c283-a6b16278f628@gmail.com> (raw)
In-Reply-To: <CAMxuvawuMvxWx7xtsf=PbWnu7UypNfVWf+Bufeqbi4J=SjsU9w@mail.gmail.com>

On 2022/03/08 23:26, Marc-André Lureau wrote:
> Hi
> 
> On Mon, Mar 7, 2022 at 4:49 PM Akihiko Odaki <akihiko.odaki@gmail.com> wrote:
>>
> 
> (taking notes, mostly for myself)
> 
>>> Could you provide a failing test case or a more concrete suggestion on
>>> what to do instead? I am all ears :)
>>>
>>> thanks
>>>
>>
>> Let me describe a more concrete case. Think that egl-headless and vnc
>> are enabled. The guest devices are serial virtio-gpu-gl. vnc selects
>> serial at first.
> 
> (I am not sure how you would select serial first, but let's assume you did)
> 
>>
>> vnc uses register_displaychangelistener and console_select to switch
>> consoles.
>>
>> displaychangelistener_display_console does the actual switching, and
>> calls dpy_gfx_switch and dpy_gfx_update if con->scanout.kind is
>> SCANOUT_SURFACE. It calls dpy_gl_scanout_texture or
>> dpy_gl_scanout_dmabuf if con->scanout.kind is SCANOUT_TEXTURE or
>> SCANOUT_DMABUF. It works for a OpenGL display, but it doesn't vnc in
>> combination with egl-headless.
> 
> (hmm, what doesn't work? With this patch, the DisplaySurface is always
> switched, no matter what con->scanout.kind is)
> 
>>
>> virtio-gpu-gl starts scanning out texture. It would happen in the
>> following sequence:
>> 1. virtio-gpu-gl calls qemu_console_resize. con->scanout.kind will be
>> SCANOUT_SURFACE.
>> 2. qemu_console_resize calls dpy_gfx_switch, delivering DisplaySurface
>> to egl-headless. con->scanout.kind will be SCANOUT_TEXTURE.
> 
> (qemu_console_resize calls dpy_gfx_replace_surface. con.scanout.kind
> is still SCANOUT_SURFACE)
> 
> (It calls displaychangelistener_gfx_switch() which will call
> egl_gfx_switch() and update the current surface)
> 
>> 3. virtio-gpu-gl calls dpy_gl_scanout_texture. egl-headless starts
>> rendering the texture to the DisplaySurface.
> 
> (now con.scanout.kind becomes SCANOUT_TEXTURE)
> 
>>
>> In the end, the DisplaySurface will have the image rendered, and
>> con->scanout.kind will be SCANOUT_TEXTURE.
> 
> (so far it works as expected, right?)
> 
> 
> 
>>
>> Now vnc switches to virtio-gpu-gl.
>>
>> 4. vnc calls console_select
>> 5. displaychangelistener_display_console finds con->scanout.kind is
>> SCANOUT_TEXTURE so it tries to scanout texture, but vnc is not an OpenGL
>> display. It essentially becomes no-op and the display would be blank.
>>
>> This patch will change it to call dpy_gfx_switch but not to call
>> dpy_gfx_update.
> 
> Alright, I think I see what you mean. egl-headless is associated with
> a specific con, and thus is not involved during vnc console switching.
> 
> However, dpy_gfx_switch on vnc is not a no-op. It updates the surface,
> resize the client and mark the area dirty. Because the con.surface is
> kept updated by egl-headless, the client gets the updated content.
> Iow, it still works.
> 
> If we always called dpy_gfx_update() during
> displaychangelistener_display_console(), it would mean for the
> listener to display the surface content, even when the scanout kind is
> set for a texture. Or we need to change the behaviour of
> dpy_gfx_update() to depend on the current scanout kind.

vnc has to display the surface content so dpy_gfx_update should be 
called for vnc, but not for OpenGL displays.

Regards,
Akihiko Odaki

> 
> Imho, it's acceptable in the current proposed form, since there is no
> apparent bug (unless I miss something). However, I can try to
> formulate a FIXME comment and add some documentation around the gfx
> callback to improve the situation.
> 
> thanks
> 



  reply	other threads:[~2022-03-08 14:43 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07  7:46 [PATCH v3 00/12] GL & D-Bus display related fixes marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 01/12] ui/console: move check for compatible GL context marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 02/12] ui/console: move dcl compatiblity check to a callback marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 03/12] ui/console: egl-headless is compatible with non-gl listeners marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 04/12] ui/dbus: associate the DBusDisplayConsole listener with the given console marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 05/12] ui/console: move console compatibility check to dcl_display_console() marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 06/12] ui/shader: fix potential leak of shader on error marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 07/12] ui/shader: free associated programs marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 08/12] ui/console: add a dpy_gfx_switch callback helper marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 09/12] ui/console: optionally update after gfx switch marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 10/12] ui/dbus: fix texture sharing marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 11/12] ui/dbus: do not send 2d scanout until gfx_update marcandre.lureau
2022-03-07  7:46 ` [PATCH v3 12/12] ui/console: call gfx_switch() even if the current scanout is GL marcandre.lureau
2022-03-07  8:08   ` Akihiko Odaki
2022-03-07 10:19     ` Marc-André Lureau
2022-03-07 10:34       ` Akihiko Odaki
2022-03-07 11:50         ` Marc-André Lureau
2022-03-07 12:24           ` Akihiko Odaki
2022-03-07 12:32             ` Marc-André Lureau
2022-03-07 12:49               ` Akihiko Odaki
2022-03-08 14:26                 ` Marc-André Lureau
2022-03-08 14:42                   ` Akihiko Odaki [this message]
2022-03-09  8:02                     ` Marc-André Lureau
2022-03-09  8:05                       ` Akihiko Odaki
2022-03-09  8:11                         ` Marc-André Lureau
2022-03-09  8:21                           ` Akihiko Odaki
2022-03-09  8:33                             ` Marc-André Lureau
2022-03-09  8:34                               ` Akihiko Odaki
2022-03-09  8:40                                 ` Marc-André Lureau
2022-03-09  8:49                                   ` Akihiko Odaki
2022-03-09  8:54                                     ` Marc-André Lureau
2022-03-09  9:02                                       ` Akihiko Odaki
2022-03-09  9:26                                     ` Gerd Hoffmann
2022-03-09  9:32                                       ` Akihiko Odaki
2022-03-09  9:53                                         ` Marc-André Lureau
2022-03-09 10:01                                           ` Akihiko Odaki
2022-03-09 10:07                                             ` Marc-André Lureau
2022-03-09 10:20                                               ` Akihiko Odaki
2022-03-09 10:27                                                 ` Marc-André Lureau
2022-03-09 10:38                                                   ` Akihiko Odaki
2022-03-09 10:45                                                     ` Marc-André Lureau
2022-03-09 10:54                                                       ` Akihiko Odaki
2022-03-09 10:13                                           ` Gerd Hoffmann
2022-03-09 10:15 ` [PATCH v3 00/12] GL & D-Bus display related fixes Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1fa142fb-7988-db25-c283-a6b16278f628@gmail.com \
    --to=akihiko.odaki@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).