On Tue, 2018-08-28 at 15:46 +0200, Gerd Hoffmann wrote: > > > > 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? > > With a single channel it is easier to syncronize them, yes. > > Right now qxl has two types of surfaces. Primary (the actual display) > and non-primary (basically pixel data storage). Spice ops can (among > other 2d ops) blit data from one surface to another. So you can store > the content of a window in a surface, then blit it to primary to draw > the window. This was state of the art roughly 15 years ago, when qxl > was designed. > > These days nobody uses 2d ops any more. Compositors use the 3d engine > (or llvmpipe in case there is no 3d hardware) to render the desktop to a > framebuffer. Then they ask the gpu to flip to that framebuffer on the > next vblank interval. While the first framebuffer is shown they render > the next frame to second framebuffer, then flip again so the two > framebuffer swap roles. > > I think we can support this in spice/qxl this way: > > (1) Drop the concept of a "primary" surface (except for backward > compatibility of course). > (2) Allow to map any surface to any monitor (i.e. "please display > surface 17 on monitor 1"). > > Workflow would look like this then: > > (1) userspace creates a drm framebuffer > (2) qxl driver defines a surface for it. > (2) userspace renders into the framebuffer. > (3) userspace asks qxl to show that framebuffer. > (4) qxl will send updates for that framebuffer to spice-server. > (5) qxl will send monitor map request for that framebuffer to > spice-server. > > The same will work just fine for two monitors. And given that qxl will > first send the bulky updates for both framebuffers and then flip both > with a small map request command syncronization should not be a big > issue. If needed it should be possible to explicitly group the map > requests, or have a single message which sets the map for all monitors > of the channel. Ok, this is for the qemu <-> spice server interface. For the network protocol, spice server <-> client, there needs to be something too. That's mainly what I was referring to in the previous email. On a single channel, I think synchronization can work and may be easy. Inbetween channels, I think it will be a challenge. Also, in another email you suggested using virtio-gpu instead of QXL for wayland. Is virtio-gpu the modern successor of QXL? If so, why not just use that for wayland and leave QXL for xorg only? (The only issue I can see is if someone wants to switch xorg/wayland sessions.) > cheers, > Gerd > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel