qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Kim, Dongwon" <dongwon.kim@intel.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: <qemu-devel@nongnu.org>, Gerd Hoffmann <kraxel@redhat.com>,
	"Vivek Kasireddy" <vivek.kasireddy@intel.com>
Subject: Re: [PATCH] ui/gtk: set the area of the scanout texture correctly
Date: Mon, 26 Jun 2023 12:49:07 -0700	[thread overview]
Message-ID: <6556daf6-a3a3-132d-df2c-2914c6bb2e47@intel.com> (raw)
In-Reply-To: <CAJ+F1CJ2cVDAOTY-j77QGj5W1d4wrphcQ2oEUqkw0R4hBX3q0w@mail.gmail.com>

Hi Marc-André Lureau,

On 6/26/2023 4:56 AM, Marc-André Lureau wrote:
> Hi
>
> On Wed, Jun 21, 2023 at 11:53 PM Dongwon Kim <dongwon.kim@intel.com> 
> wrote:
>
>     x and y offsets and width and height of the scanout texture
>     is not correctly configured in case guest scanout frame is
>     dmabuf.
>
>     Cc: Gerd Hoffmann <kraxel@redhat.com>
>     Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
>     Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
>     Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
>
>
> I find this a bit confusing, and I don't know how to actually test it.
>
> The only place where scanout_{width, height} are set is 
> virtio_gpu_create_dmabuf() and there, they have the same values as 
> width and height. it's too easy to get confused with the values imho.

Yes, scanout_width/height are same as width/height as far as there is 
only one guest display exist. But they will be different in case there 
multiple displays on the guest side, configured in extended mode (when 
the guest is running Xorg).

In this case, blob for the guest display is same for scanout 1 and 2 but 
each scanout will have different offset and scanout_width/scanout_height 
to reference a sub region in the same blob(dmabuf).

I added x/y/scanout_width/scanout_height with a previous commit:

commit e86a93f55463c088aa0b5260e915ffbf9f86c62b
Author: Dongwon Kim <dongwon.kim@intel.com>
Date:   Wed Nov 3 23:51:52 2021 -0700

     virtio-gpu: splitting one extended mode guest fb into n-scanouts

> I find the terminology we use for ScanoutTexture much clearer. It uses 
> backing_{width, height} instead, which indicates quite clearly that 
> the usual x/y/w/h are for the sub-region to be shown.
yeah agreed. Then dmabuf->width/height should be changed to 
dmabuf->backing_width/height and dmabuf->width/height will be replacing 
dmabuf->scanout_width/scanout_height. I guess this is what you meant, right?
> I think we should have a preliminary commit that renames 
> scanout_{width, height}.
>
> Please give some help/hints on how to actually test this code too.

So this patch is just to make things look consistent in the code level. 
Having offset (0,0) in this function call for all different scanouts 
didn't look right to me. This code change won't make anything done 
differently though. So no test is applicable.

>
> Thanks!
>
>
>     ---
>      ui/gtk-egl.c     | 3 ++-
>      ui/gtk-gl-area.c | 3 ++-
>      2 files changed, 4 insertions(+), 2 deletions(-)
>
>     diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
>     index 19130041bc..e99e3b0d8c 100644
>     --- a/ui/gtk-egl.c
>     +++ b/ui/gtk-egl.c
>     @@ -257,7 +257,8 @@ void
>     gd_egl_scanout_dmabuf(DisplayChangeListener *dcl,
>
>          gd_egl_scanout_texture(dcl, dmabuf->texture,
>                                 dmabuf->y0_top, dmabuf->width,
>     dmabuf->height,
>     -                           0, 0, dmabuf->width, dmabuf->height);
>     +                           dmabuf->x, dmabuf->y,
>     dmabuf->scanout_width,
>     +                           dmabuf->scanout_height);
>
>          if (dmabuf->allow_fences) {
>              vc->gfx.guest_fb.dmabuf = dmabuf;
>     diff --git a/ui/gtk-gl-area.c b/ui/gtk-gl-area.c
>     index c384a1516b..1605818bd1 100644
>     --- a/ui/gtk-gl-area.c
>     +++ b/ui/gtk-gl-area.c
>     @@ -299,7 +299,8 @@ void
>     gd_gl_area_scanout_dmabuf(DisplayChangeListener *dcl,
>
>          gd_gl_area_scanout_texture(dcl, dmabuf->texture,
>                                     dmabuf->y0_top, dmabuf->width,
>     dmabuf->height,
>     -                               0, 0, dmabuf->width, dmabuf->height);
>     +                               dmabuf->x, dmabuf->y,
>     dmabuf->scanout_width,
>     +                               dmabuf->scanout_height);
>
>          if (dmabuf->allow_fences) {
>              vc->gfx.guest_fb.dmabuf = dmabuf;
>     -- 
>     2.34.1
>
>
>
>
> -- 
> Marc-André Lureau


  reply	other threads:[~2023-06-26 19:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-21 21:31 [PATCH] ui/gtk: set the area of the scanout texture correctly Dongwon Kim
2023-06-26 11:56 ` Marc-André Lureau
2023-06-26 19:49   ` Kim, Dongwon [this message]
2023-07-04 16:07     ` Marc-André Lureau
2023-07-05 23:17       ` Kim, Dongwon

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=6556daf6-a3a3-132d-df2c-2914c6bb2e47@intel.com \
    --to=dongwon.kim@intel.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vivek.kasireddy@intel.com \
    /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).