On Fri, 2018-08-24 at 17:21 +0200, Gerd Hoffmann wrote: > On Fri, Aug 24, 2018 at 03:38:07PM +0200, Lukáš Hrázký wrote: > > On Fri, 2018-08-24 at 14:25 +0200, Gerd Hoffmann wrote: > > > 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). > > > > Ok, that makes some sense. You do however need some synchronization > > mechanism between the different framebuffers? (Imagine a video playing > > across two displays) > > The linux kernel kms drivers support atomic page flips for both > displays, and wayland actually uses that. Ok, what about the SPICE case? If we use one surface per display, we also need some sort of synchronization mechanism. Now I'm mostly guessing here, but from what I understand, we could send the frames of multiple monitors in sync over a single display channel, but if we use multiple channels, they are not synchronized and would arrive rather arbitrarily on the client? Cheers, Lukas _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel