[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