> > > 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. Yes, sure. Should look very simliar as most of the qxl device operations map directly to spice display channel messages. > 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. Yes. Not sure what the state of mm timer is. In the past that was used to sync between display channel and sound channel, dunno whenever that is still the case. > Also, in another email you suggested using virtio-gpu instead of QXL > for wayland. Is virtio-gpu the modern successor of QXL? It is a newer display device with a newer design. So some of the issues qxl has are gone. virtio-gpu doesn't provide any 2d ops, but they are increasingly unused by modern guests aynway. virtio-gpu can optionally offers 3d support, there is a mesa driver for it. > If so, why not just use that for wayland and leave QXL for xorg only? That certainly is an option. Also note that wayland on qxl works fine in single-head mode. > (The only issue I can see is if someone wants to switch xorg/wayland > sessions.) xorg works on virtio-gpu, including multihead support with the help of vdagent. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel