qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Lukáš Hrázký" <lhrazky@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jonathon Jongsma <jjongsma@redhat.com>,
	spice-devel@lists.freedesktop.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Spice-devel] [RFC PATCH spice 1/2] QXL interface: add functions to identify monitors in the guest
Date: Thu, 11 Oct 2018 15:12:21 +0200	[thread overview]
Message-ID: <1539263541.16655.110.camel@redhat.com> (raw)
In-Reply-To: <20181011122757.gsynkctea7reqnik@sirius.home.kraxel.org>

On Thu, 2018-10-11 at 14:27 +0200, Gerd Hoffmann wrote:
> > > So, if I remember correctly, Gerd recommended returning this value from
> > > the function. But I think it needs more explanation here. What exactly
> > > is a "monitor_id" supposed to represent? It is not used in your follow-
> > > up qemu patch so it's hard to tell.
> > 
> > It's supposed to be the actual monitor_id that we use in SPICE to
> > identify the monitors. I've just spent quite some time looking up where
> > the monitor_id actually comes from, and it's actually set all the way
> > down in the driver (either xf86-video-qxl or the KMS driver in the
> > kernel) and passed through the monitors_config functions to SPICE
> > server.
> 
> How does all this monitors_config work currently in case multiple
> display channels are present?
> 
> There is the QXLInterface->client_monitors_config() callback.
> 
> There is the spice_qxl_monitors_config_async() function.
> 
> Both are linked to a display channel.  The server/client messages go
> through the main channel though ...

Not really, it actually is like this:

       display channel
server --------------> client


        main channel
client --------------> server

So the monitors_configs go each on its own display channel to the
client, the client puts it all together and sends back an aggregated
list on the main channel.

> So what happens if a message from the client arrives?  Is that
> broadcasted as-is to all display channels?  The current qemu code
> (interface_client_monitors_config in spice-display.c, which is used with
> virtio-gpu) simply uses the head as index into the array, so it looks
> like spice-server doesn't do any filtering here (like only filling in
> the monitors which belong to the display channel).

Correct, the spice server doesn't do any filtering and sends the whole
monitors_config to all the interfaces...

> spice_qxl_monitors_config_async() is never called with virtio-gpu,
> except when opengl is enabled.  In that case qemu simply sets
> QXLMonitorsConfig->count to 1 and fills in QXLMonitorsConfig->head[0]
> (see qemu_spice_gl_monitor_config in spice-display.c).

As a side note, I have no idea about opengl. I got a slight impression
from some earlier conversation that this is actually not used, but I
don't really know.

My wild guess at this moment is, that if you don't call
spice_qxl_monitors_config_async() with virtio-gpu, meaning you don't
send any monitors config, a simple one containing a single monitor for
the surface is created somewhere along the way.

> Which would be
> ok in case spice-server merges the configs from all channels before
> sending it off to the client.  Not sure this actually happens ...

A bit differently, as I said, but the configs are merged on the client,
which should be an equivalent outcome.

> > Interstingly enough, that seems to be the ID we want to have in the
> > device_display_id attribute.  I expect (still need to look that up, I'm
> > out of time right now) that for virtio-gpu the ID is a bit different,
> 
> Keep in mind that multiple display devices don't really work right now,
> and possibly we need to fix not only spice but qemu too.

What exactly do you mean by multiple devices not working?

> > And yeah, I didn't use the id in the QEMU patches, as I didn't know
> > how, I expect Gerd to have some grand plans for it :)
> 
> IIRC the latest plan was to just keep things as is, plan with one
> channel per monitor for all future things, and just not support
> one-qxl-device-multihead in combination with multiple display channels.
> 
> Is that correct?

Correct.

> I don't think we need the monitors_id in qemu then, qemu can simply use
> the channel_id (except for the legacy qxl case).

Ok. Given the fact that the monitor_ids actually come from the driver,
QEMU should actually know them already, right? No need to pass them
back anyway? (except for the virtio-gpu case, which doesn't send
monitors_config and so a single monitor_id = 0 is deduced in spice
server)

Cheers,
Lukas

> cheers,
>   Gerd
> 

  parent reply	other threads:[~2018-10-11 13:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09 13:10 [Qemu-devel] [RFC PATCH spice/qemu 0/2] QXL interface to set monitor ID Lukáš Hrázký
2018-10-09 13:10 ` [Qemu-devel] [RFC PATCH spice 1/2] QXL interface: add functions to identify monitors in the guest Lukáš Hrázký
2018-10-09 19:33   ` [Qemu-devel] [Spice-devel] " Jonathon Jongsma
2018-10-10 10:37     ` Gerd Hoffmann
2018-10-11 12:55       ` Lukáš Hrázký
2018-10-11 13:20         ` Gerd Hoffmann
2018-10-11 13:31           ` Lukáš Hrázký
2018-10-11 13:45             ` Gerd Hoffmann
2018-10-10 16:36     ` Lukáš Hrázký
2018-10-11 12:27       ` Gerd Hoffmann
2018-10-11 13:07         ` Frediano Ziglio
2018-10-11 13:12         ` Lukáš Hrázký [this message]
2018-10-11 13:43           ` Gerd Hoffmann
2018-10-11 14:30             ` Lukáš Hrázký
2018-10-11 15:09               ` Gerd Hoffmann
2018-10-11 15:37                 ` Lukáš Hrázký
2018-10-12  9:27                   ` Gerd Hoffmann
2018-10-12  9:54                     ` Lukáš Hrázký
2018-10-12 10:15                     ` Frediano Ziglio
2018-10-12 10:42                       ` Gerd Hoffmann
2018-10-12 10:46                         ` Frediano Ziglio
2018-10-12 11:05                           ` Gerd Hoffmann
2018-10-09 13:10 ` [Qemu-devel] [RFC PATCH qemu 2/2] spice: set PCI path and device display ID in QXL interface Lukáš Hrázký

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=1539263541.16655.110.camel@redhat.com \
    --to=lhrazky@redhat.com \
    --cc=jjongsma@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=spice-devel@lists.freedesktop.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).