Hi, > But there is no concept of an additional surface in the guest driver. > RANDR 1.2 (and I think the same for 1.3, 1.4, since we don't have per > CRTC pixmaps) has a single screen wide pixmap. A screen is one per X > server, so there is just one even if you have multiple heads. And the > CRTCs scan out of it. To copy the RANDR docs diagram (removed the double > output): > > > ┌─────────────────────────────────┐ > ┏━━━━━━━┳───────────────┐ ╔════════╗ > ┃ 1 ┃ │ ║ A ║ > ┃ ┏━━━╋━━━━━━━━━━━━━━━┫ ║ ║ > ┣━━━╋━━━┛ ┃ ╚════════╝ > │ ┃ 2 ┃─────────────────┐ > │ ┃ ┃ ╔═══════════════════╗ > │ ┃ ┃ ║ ║ > │ ┗━━━━━━━━━━━━━━━━━━━┫ ║ B ║ > └───────────────────────┘ ║ ║ > ┌──────┐ ┏━━━━┓ ╔══════╗ ║ ║ > │screen│ ┃CRTC┃ ║output║ ╚═══════════════════╝ > └──────┘ ┗━━━━┛ ╚══════╝ > > So if we were to create an additional surface we will have to issue copy > commands for it from the primary surface. I don't think you have to copy. You have both width and stride fields for surfaces. stride doesn't need to be width * depth, you can add padding. Which allows you to allocate a large pixmap in device memory, then create multiple surfaces which each representing parts of your large pixmap. The approach still has its drawbacks: Rendering ops need some extra math, and you can't submit rendering ops for invisible regions of your large pixmap. The biggest issue are overlapping crts I suspect. They would lead to overlapping surfaces. Ouch. I guess Izik had windows guests in mind which would probably deal fine with the multiple surfaces approach, given that the windows monitor layout dialog box allows alot less to do compared to xrandr ... cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel