qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] spicevmv chardev, guest agents and paravirtual mouse


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] spicevmv chardev, guest agents and paravirtual mouse
Date: Thu, 13 Jan 2011 09:52:00 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Red Hat/3.1.7-3.el6_0 Thunderbird/3.1.7

  Hi,

There isn't much spice-specific stuff in there. The clipboard bits
for example should work unmodified with vnc, one would just have to
hack up a vnc extention to tunnel the agent protocol over vnc (and vnc
client support of course).

VNC already supports copy/paste as part of the protocol so can the agent
protocol be terminated in QEMU such that the server can make use of the
standard protocol extensions?

Should be doable too, didn't look at the vnc extension in detail though.

Also related: paravirtual mouse. I'd suggest to go for something new,
based on virtio-serial, doing just the mouse and nothing else.

I'd agree. I think we want something that actually terminates in the
kernel for Linux guests since then we can expose it as an evdev device.
No special X driver would be needed.

Doesn't have to terminate in the kernel, you can feed the linux input subsystem via uinput (vdagent-linux actually does that btw.), X will get the events via evdev and everything works fine in the singlehead case. I think you need a X driver to handle multihead though.

Is this something that makes sense for Spice in the future?

Yes. Supporting multihead is a requirement for spice though. Having the initial implementation not support it would be fine, but we need at least a plan how to handle this case.

For instance, Spice makes use of a 1-off protocol whereas something like
virt-agent uses an established RPC protocol (XML-RPC). I'm not tied to
using any particular protocol, but I think it's very important to use a
standardized, well specified protocol.

If that is a hard requirement it means we'll have to design something new for the agent, take care that it fulfills the spice requirements, then switch over for new deployments. Of course we'll have to maintain current vdagent for backward compatibility.

Depending on the design we might be able to translate between the current vdagent and new agent protocol. Being able to do that would be quite helpful for the transition of course.

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]