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
>
next prev 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 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.