All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Akihiko Odaki <akihiko.odaki@gmail.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] ui/console: Assert graphic console surface is not NULL
Date: Fri, 19 Feb 2021 15:48:48 +0100	[thread overview]
Message-ID: <20210219144848.wy7wmel4lixaqkyb@sirius.home.kraxel.org> (raw)
In-Reply-To: <20210219101702.91002-1-akihiko.odaki@gmail.com>

On Fri, Feb 19, 2021 at 07:17:02PM +0900, Akihiko Odaki wrote:
> ui/console used to accept NULL as graphic console surface, but its
> semantics was inconsistent among displays:
> - cocoa and gtk-egl perform NULL dereference.
> - egl-headless, spice and spice-egl do nothing.
> - gtk releases underlying resources.
> - sdl2-2d and sdl2-gl destroys the window.
> - vnc shows a message, "Display output is not active."
> 
> Fortunately, there are only three cases where NULL is assigned as
> graphic console surface, and we can study them to figure out the
> desired behavior:
> - virtio-gpu-base assigns NULL when the device is realized.
>   We have nothing to do in the case because graphic consoles
>   already have a surface with a message saying the content is
>   not initializd yet.
> - virtio-gpu-3d assigns NULL when the device is reset. The initial
>   graphic console surfaces shows a message, so it would be
>   appropriate to do similar.
> - virtio-gpu-3d assigns NULL when scanout is disabled. That
>   affects its operations later but itself do not mean any effects
>   on displays. Removing the operation should be fine.
> 
> This change eliminates NULL as graphic console surface by
> implementing those behaviors.

No.

Background: Some display devices (qxl, virtio) support multiple outputs.
For secondary displays it totally makes sense to allow them being
disabled and the ui hiding the window then.  For the primary display it
usually is problematic though.

So in case the guest disabled the display virtio-gpu will create a
message surface for head 0 and pass NULL otherwise.

We certainly can make the whole thing more consistent.  One option I see
is deal with the surface == NULL case in dpy_gfx_replace_surface().  The
function can check whenever the display is primary (con->index == 0) and
show a message in that case and pass on the NULL otherwise.  We could
maybe also add a flag to the DisplayChangeListener struct to indicate
whenever surface == NULL can be handled (sdl for example) or not (vnc)
so dpy_gfx_replace_surface() could also create a message surface for
secondary displays if needed.

With that in plase virtio-gpu can just pass NULL for disabled displays
no matter what.  DisplayChangeListeners can ask for non-NULL surfaces if
they want.  All logic is in one place (dpy_gfx_replace_surface).

take care,
  Gerd



  reply	other threads:[~2021-02-19 15:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 10:17 [PATCH] ui/console: Assert graphic console surface is not NULL Akihiko Odaki
2021-02-19 14:48 ` Gerd Hoffmann [this message]
2021-02-20 11:38   ` [PATCH v2] ui/console: Pass placeholder surface to displays Akihiko Odaki
2021-02-22 10:51     ` Gerd Hoffmann
2021-02-23  4:43       ` Akihiko Odaki
2021-02-24 11:06         ` Gerd Hoffmann
2021-02-25  1:36           ` [PATCH v3 1/3] ui/console: Add placeholder flag to message surface Akihiko Odaki
2021-02-25  1:36             ` [PATCH v3 2/3] ui/console: Pass placeholder surface to displays Akihiko Odaki
2021-02-25  9:06               ` Gerd Hoffmann
2021-02-25  1:36             ` [PATCH v3 3/3] virtio-gpu: Do not distinguish the primary console Akihiko Odaki
2021-02-25  9:10               ` Gerd Hoffmann
2021-02-25  9:45                 ` Akihiko Odaki
2021-02-25 11:19                   ` Gerd Hoffmann
2021-02-25  9:01             ` [PATCH v3 1/3] ui/console: Add placeholder flag to message surface 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=20210219144848.wy7wmel4lixaqkyb@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=akihiko.odaki@gmail.com \
    --cc=mst@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.