[Spice-devel] [protocol RFC 0/2] RANDR support via QXLHead + SpiceHead

Marc-André Lureau marcandre.lureau at gmail.com
Mon May 7 05:16:09 PDT 2012


On Mon, May 7, 2012 at 8:28 AM, Alon Levy <alevy at redhat.com> wrote:
>  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)

I am a bit concerned about the display glitches that it may introduce,
the various order of the following events: init / capability ack,
primary surface creation, display mark, spice head messages (how
many?)..

We already have "display" and "monitor," do we need to introduce "head" ?

What will be the relation between "head"and "monitor" (for MonitorConfig etc.)

Are we going to have one more input/cursor channel per head? Probably
not, but it would be nice to specify. I guess the coordinate will need
to be adjusted to the respective heads. (ie some messages will be
relative to heads, other to primary surface: INPUTS_MOUSE_POSITION vs
CURSOR_MOVE).

 Would be great if the proposal would be first proven with a working
implementation before it's amended.


> 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.

Having a single SpiceHeadsConfig (similar to VDAgentMonitorsConfig)
could avoid the client wondering how many heads exists (enabled or
not)

Other than that, it sounds like a reasonable proposal to me. I could
work on the spice-gtk side if it can help you to get this ready
quickly.

regards

-- 
Marc-André Lureau


More information about the Spice-devel mailing list