[Spice-devel] [RFC PATCH v2 00/20] Monitor ID rework

[Gerd Hoffmann]

On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> On Thu, 2018-08-23 at 22:42 +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > "we only support" seems to just state the use cases before adding
> > > vGPU but we are trying to support vGPU cases.
> > > If even we decide that for vGPU cards we always have monitor_id == 0
> > 
> > Yes, we want this for sure.  One channel per display.
> 
> For sure? This deserves a justification.

That is the way modern display architectures (including wayland) are
working.  One framebuffer per display.  Not one huge framebuffer
covering all heads, then defining rectangles for each display, like qxl
handles multihead on linux (with xorg).

And the qxl way of doing multihead on linux starts to cause problems:
https://bugzilla.redhat.com/show_bug.cgi?id=1611141

> > Except when the device is
> > qxl, because qxl has a channel-id field somewhere (in qxl rom IIRC)
> > which the guest can read.
> 
> Really? Can you describe how the guest could read that? Thanks.

It's QXLRom->id (see /usr/include/spice-1/spice/qxl_dev.h).

> > And it is not limited to vGPU.  Try place two emulated display devices
> > into one guest (not using qxl).  You'll face the very same issue.
> > 
> > Placing both channel_id and monitor_id into the messages isn't going to
> > solve this.
> 
> No, the way I solve this is by having a hash table on the server, which
> maps (channel_id, monitor_id) -> guest_output_id.
> 
> The reason for using (channel_id, monitor_id) is that it is the only
> unambiguous unique identifier of a monitor on the server.

I'd rather try to get rid of monitor_id and just not support setups
with both qxl multihead (linux/xorg style) and multiple display devices
at the same time.

> The guest_output_id is sent to the server from the streaming agent and
> it is the xrandr output id.

xrandr output id doesn't look like a clever choice to me.
What do you do in windows guests?
How do you handle wayland?

Also: why handle this in the server in the first place?  Isn't it
sufficient if the guest agent knows which output is which channel id?

> Therefore we obviously have it only for
> streamed monitors. For other, old-style monitors, we still fall back to
> channel_id + monitor_id.

If you must change the protocol for that (and I'm not convinced yet it
is actually needed) I'd try to fix this for real and cover both stream
display channels and classic display channels.  Otherwise it will be
just band-aid again and I wouldn't surprised if it breaks again rather
sooner than later.

cheers,
  Gerd