From: "Lukáš Hrázký" <lhrazky@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
Jonathon Jongsma <jjongsma@redhat.com>
Cc: 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 14:55:39 +0200 [thread overview]
Message-ID: <1539262539.16655.99.camel@redhat.com> (raw)
In-Reply-To: <20181010103704.jqgfp3kiaiqu4hzt@sirius.home.kraxel.org>
Hi Gerd,
On Wed, 2018-10-10 at 12:37 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > + * Sets the hardware (e.g. PCI) path of the graphics device
> > > represented by this QXL interface instance.
> >
> > So, this comment suggests that the caller might be able to provide a
> > path that is not a PCI path. But the implementation below (mostly the
> > debug output, I suppose...) assumes a PCI path. Do we need to support
> > non-PCI paths?
>
> Certainly not for the initial revision, maybe never.
>
> But thanks to the "pci/" prefix we should be able to add support for
> other paths later in case it turns out we need it.
>
> > > + * Returns: The actual SPICE server monitor_id associated with the
> > > display
> >
> > 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.
>
> IIRC the plan was to ditch the global monior_id idea and use the
> (channel_id, display_id) tuple everywhere ...
Not sure what exactly you mean here by "global monitor_id". Not sure
about "use the (channel_id, display_id)" either, it doesn't seem quite
correct.
The plan was (and still is) to limit the use cases to the following
two:
* Legacy QXL on linux with multiple monitors per display channel, but
only this single display channel. Multiple display channels are not
supported in this case, so no streaming etc.
* Limit the number of monitors per display channel to one for all other
cases.
With these limitations, the display_id = channel_id + monitor_id
formula that is used on the client remains unique. With one more
condition, that I think I should add, and that is that monitor_id is
always 0 for the multiple display channel case. It seems it may come up
that the monitor_id could be non-zero, e.g. for the virtio-gpu case...
So the IDs used are:
monitors_config server -> client:
(channel_id, monitor_id)
monitors_config client -> server and possibly server -> vd_agent:
display_id
I hope it's clear like this :)
Cheers,
Lukas
> cheers,
> Gerd
>
next prev parent reply other threads:[~2018-10-11 12:55 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ý [this message]
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ý
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=1539262539.16655.99.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).