[Spice-devel] [protocol RFC 0/2] RANDR support via QXLHead + SpiceHead
Alon Levy
alevy at redhat.com
Tue May 8 03:08:36 PDT 2012
On Mon, May 07, 2012 at 03:31:23PM -0600, Noel Van Hook wrote:
> How far away is a multi-head solution, do you think?
> It sounds like most of the work is in the client and the X driver?
> Noel
>
I guess a month of real life I hope.
> On Mon, May 7, 2012 at 12:28 AM, Alon Levy <alevy at redhat.com> wrote:
> > Hi,
> >
> > Currently we support multiple monitors by having:
> > single pci = single display channel = single client window
> >
> > The RANDR architecture doesn't lend itself to this, but on the other hand it
> > makes it very easy to have an alternative scheme:
> > single pci = single display channel = multiple client windows
> >
> > RANDR introduces a concept of a CRTC and an OUTPUT. The CRTC scansout a
> > portion of the framebuffer onto one or more OUTPUTs. I propose having a 1:1 CRTC:OUTPUT correspondence and introducing two new commands, one on PCI and one for the protocol:
> > QXLHead = (id, x, y, width, height)
> > SpiceHead = (id, x, y, width, height)
> >
> > 1. Guest enables a new monitor:
> > 2. Guest pushes QXLHead command to command ring
> > 3. Server sends SpiceHead message on the ring's display channel.
> > 4. Client creates a window out of [x, y, width, height] scanning out of the primary surface (there is one associated primary with the display channel)
> >
> > Some other notes:
> > a. To disable a monitor, send (id, 0, 0, 0, 0) (So there remain invalid range of
> > values {(id, x, y, width, height) | max(x, y, width, height)!=0 and min(width,
> > height) = 0})
> > b. Guest keeps track of the head id.
> > c. No idea if this is easy / natural for a WDDM driver, if not we will keep having multiple display channels there, or have to extend the concept of primary to have a number of primary surfaces. Another option is to extend the QXLHead/SpiceHead to have a surface id argument. But I suggest to postpone this to when we actually work on the WDDM driver (unless someone wants to look at it now).
> > d. Improvements from this method are:
> > single vram bar for multiple heads, single ram bar - more efficient memory allocation
> > single display channel means single glz dictionary, single image cache, again more efficient.
> > limit of 4 monitors is lifted (the limit of four display channels remains)
> > implementation for guest is trivial:
> > keep track of enclosing size of primary and resize it as needed
> > issue a QXLHead for each output enabled / disabled (corresponds with crtc since we keep a 1:1 relation in the driver).
> >
> > I have a proof of concept driver, but needs some work yet. I want to get input on this scheme, it is also very related to application remoting, but I haven't given it thought so far.
> >
> > Alon Levy (2):
> > qxl_dev: dynamic head support on single display channel
> > protocol: add SPICE_DISPLAY_CAP_HEAD
> >
> > spice/protocol.h | 4 ++++
> > spice/qxl_dev.h | 12 ++++++++++++
> > 2 files changed, 16 insertions(+)
> >
> > --
> > 1.7.10.1
> >
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
> --
> Noel Van Hook - Intelligraphics, Inc
> 522 Cooper Ave N
> Red Lodge, MT 59068
> Noel.Van.Hook at Intelligraphics.com (425) 770-5561
More information about the Spice-devel
mailing list