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

[Alon Levy]

On Mon, May 07, 2012 at 02:16:09PM +0200, Marc-André Lureau wrote:
> 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?)..

Good point. Not sure - it's easy to ensure we send SpiceHead for a new
client before we send it the display mark. Actually there are a few
sequences:
Guest with agent, running before client connected:
 1. Guest started, has a single head. Guest running spice agent.
 2. Client connects with SPICE_DISPLAY_CAP_HEAD.
 3. Client sends monitor config set (VD_AGENT_MONITORS_CONFIG)
 4. Guest agent uses xrandr to set modes for each head:
  xrandr --newmode whichever mode the guest requires (this is on todo, to allow
  continuous resolution, ignore for now, doesn't affect the rest)
  xrandr --output qxl-<i> --mode <mode name for head i>
 5. <todo> guest replies with VD_AGENT_REPLY, but right now that's not
 in sync with the linux guest agent (windows agent is sync).
 6. Client sees VD_AGENT_REPLY, connects to display channel. Doesn't
 create any window until it receives DISPLAY MARK.
 7. <todo> Server sends CREATE PRIMARY, [new] QXL_HEAD x n, DISPLAY MARK
 (CREATE PRIMARY == SPICE_MSG_DISPLAY_SURFACE_CREATE with id 0)
  so client doesn't need to know in advance the number of heads, it just
  waits for the display mark.

For a change of resolution the situation is similar, we change the
current "create primary, display mark" to "create primary, create heads,
display mark".

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

Not sure where I picked that up. yeah, it does seem redundant to
monitor. Display is a channel, so it lost it's meaning as a monitor
synonym. I can rename head to monitor.

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

Same. RANDR will require all CRTCs to have the same depth as the screen.
Didn't gather there is the same limitation in VidPN (WDDM, Windows 7+).

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

Uh, I think not - we don't have multiple inputs for multiple display
channels right now, why change that? actually, didn't consider input
because there is no change. We already handle multiple monitors fine
with an agent and badly without.

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

Yes, I'd like to get spice-gtk going.

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

There SpiceMonitorsConfig is an agent level message. The server can
generate the same message I guess. It could replace the SpiceHead
message - so actually just reusing SpiceMonitorsConfig or similar. By
passing it as an agent message we "save" on adding a spice.proto
message. Though actually it doesn't work nicely, because it won't be in
sync with the display mark (since it's a different channel, hence
socket, hence out of sync). I guess I could just add a
SpiceMonitorsConfig to spice.proto, to DisplayChannel, and use that
instead of multiple SpiceMonitor (was SpiceHead) messages.

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

OK, sounds ok, I'll send revised patches with this proposal and we can
work on that. I can do the spice-gtk to, I need to learn some client :)

> 
> regards
> 
> -- 
> Marc-André Lureau