> > 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. > Maybe you cut too much context. Who is "we" in the above sentence? Why "we want"? I remember the sentence: "You can either ask us to do something or tell us how you want it done. Not both. If you already know best how to do it, just do it yourself." Also about management there's a good article: https://www.linkedin.com/pulse/management-tell-people-what-you-want-done-how-do-edward-ted-bauer The fact that virtio-vga works that way does not mean is always the best solution. One of the issue is about opening new channels on the flight to avoid, not knowing in advance the number of monitor/outputs, having to allocate lot of DisplayChannels and, due to ticket restrictions, having and maintaining multiple TCP connections from client to server just in case. But probably we should just remove this restriction. > > (that is multiple DisplayChannels for each vGPU) we still have the > > issue of id matching with the agent which these patches are trying to > > deal with. > > Yes. *That* is the underlying problem. There is no guest-visible link > between display device and spice channel. Except when the device is > qxl, because qxl has a channel-id field somewhere (in qxl rom IIRC) > which the guest can read. > > 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. > Yes, we have 2 issues: a) display_id = channel_id ? channel_id : monitor_id formula (that can be solved with channel_id and monitor_id instead of using display_id); b) vdagent not knowing what a given display_id is. Yes, the patch series is trying to solve both issues making this discussion a bit verbose. > cheers, > Gerd > > Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel