* move comment about ring to the proper file, vdi_port.h
* introduce enums for EVENT indices (0,1 for Virtio, 0 for PCI)
* move fill_events to cpp (leave the single lines inline).
This patch is a little dirty due to EOL convertion to windows format.
+ add pci_vdi_port with PCIVDIPort taken from last commit before
changing to virtio-serial (a17ccbf323)
+ move handle_error to VDIPort (identical in VIRTIOVDIPort and PCIVDIPort)
+ make VDService create first a virtio, then init, the pci, then init,
stopping when the first init succeeds, and reporting to log which was
created.
introduce VDIPort::get_num_events and VDIPort::fill_events,
change VDService::_events to be dynamically allocated
document _events contents: STATIC events, then vdi_port, then agent.
Given that all clipboard handling is async, it is possible to for
example receive a request for clipboard data from the client
while the agent no longer owns the clipboard (ie a
VD_AGENT_CLIPBOARD_RELEASE message is in transit to the client).
Thus it is necessary to keep track of our notion of clipboard ownership
and check received clipboard messages (both from other apps on the client
machine and from the agent) to see if they match our notion and if not
drop, or in case were a counter message is expected nack the clipboard
message.(citing hansg)
clean ups: capability checks, return values
Currently we send a VD_AGENT_CLIPBOARD_RELEASE when we receive a
VD_AGENT_CLIPBOARD_REQUEST with a type which we do not support. This is not
correct, as this means given up clipboard ownership while we may be able
to answer requests with different types. The correct response is to
nack the request by sending a VD_AGENT_CLIPBOARD (data) message with a type
of VD_AGENT_CLIPBOARD_NONE.(citing hansg)
-enable the clipboard support
-support the GRAB/REQUEST/DATA/RELEASE verbs in both ways.
-pasting clipboard data is now "only-by-demand" from both sides (client and agent), whose behavior is symmetric.
-client and agent don't read or send the contents of the clipboard unnecessarily (e.g. copy, internal paste, repeating paste, focus change)
-bonus (no cost): support image cut & paste, currently only with win client
The configuration is received from Spice client.
The main usage of this option is for disabling display features in order to accelerate Spice performance over limited network connections.
replaced vdiport device by virtio-serial device which is also an easy
to use stream between guest and host but is already in qemu.
* VDIPortBuffer split off from VDIPort
* use setupapi to get device path
* setupapi.lib dependency added, magic GUID instead of a magic filename
* retry several times to open device, fixes startup race between driver
initialization and service start on boot.
* limit writes to device, a limitation of current windows driver.
* virtio-serial uses overlapped structure and events for async read/write
instead of vdi_port special event.
