On Mon, May 07, 2012 at 01:36:03PM +0300, Alon Levy wrote: > On Mon, May 07, 2012 at 01:28:58PM +0300, Alon Levy wrote: > > On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote: > > > 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. > > > > OK, sorry, this was exactly what I had in mind for the client side > > implementation of QXLHead, so I should have thought of it for the > > additional surfaces as well. > > > > > > > > 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 don't follow. Your suggestion if I understand is to have a new surface > > generated by the driver that uses the same image with different stride, > > width, and starting location (allowing it to be a rect within the > > primary surfaces) compared to the primary surfaces. The only problem is > > that I don't think we have any notion of shared surfaces for the client > > side - so you would still need to issue every rendering op twice (or do > > the copy I suggested) by the server (guest issues one draw copy, server > > issues two to client)? or we will need to expand the surface creation > > command to allow this relation (in which case it would be similar to > > QXLHead). My suggestion of QXLHead creates a shared bitmap > > surface on the client side, so doesn't have this drawback. Am I > > misunderstanding you? > > > > > > > > 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 ... > > Forgot to mention, from reading the WDDM related docs (Video > Presentation Network is the umbrella term, they have sources and Mean Video Present Network, VidPN - http://msdn.microsoft.com/en-us/library/windows/hardware/ff568500%28v=vs.85%29.aspx > targets, respectively crtc and output in RANDR speak), it isn't clear if > there can be a different surface for each source, but it is definitely a > surface, so just extending QXLHead with a surface id (and the flags > field Hans suggested can't hurt) would probably work. Or take your > suggestion (the way I understand it) and add flags to the same effect to > the SurfaceCreate message. > > > > > > > cheers, > > > Gerd > > > _______________________________________________ > > > Spice-devel mailing list > > > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > _______________________________________________ > > Spice-devel mailing list > > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel