Alon,
Our Windows client code is based on 0.10.1 release and that is, I believe, the
latest one.
"spice-gtk" is running in LINUX and I believe it is not applicable to Windows
platform.
Please refer to the following trace to understand what I said. As you can see,
printing channel is register
On Mon, Apr 02, 2012 at 07:44:46AM +, Charles.Tsai-蔡清海-研究發展部 wrote:
> Alon,
>
> In spice client, the creation of the channel is based on
> "init->num_of_channels" that is returned from the spice server.
> Please see the following function to create the spice channel from the
>
Alon,
In spice client, the creation of the channel is based on
"init->num_of_channels" that is returned from the spice server.
Please see the following function to create the spice channel from the
client
void RedClient::handle_channels(RedPeer::InMessage* message)
{
Spice
Alon,
It is a bug that I modified for printing channel. BTW, can a spice channel be
brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel
might be brought up based on a configuration policy. I would like to know
On Thu, Mar 29, 2012 at 09:42:32AM +, Charles.Tsai-蔡清海-研究發展部 wrote:
> Alon,
>
> Forget my previous mail. When I dig into the vdservice, I found there was one
> bug to check the overlay I/O status after calling the VirtIO write function.
> After I fixed the bug, I can see more printing raw dat
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one
bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now.
Although I still find some issues, hopefully I can fix it
Alon,
My printer driver can write the printing raw data into virtIO driver. But I
cannot see the found the printing raw data in the spice server. For the
vdagent, I found the following code segment which is a callback to read the
data from the vdi_port. Do I need to add a similar code to read t
