[Spice-devel] Fail to create a printing channel

Thu Mar 22 22:08:34 PDT 2012

Alon,

In Windows, driver name is provided by the device driver. In this case , "com.redhat.print.0" is the device visible to application.
Because device "com.redhat.print.0" is created by the Qemu which is in Linux, how the Linux passes the driver information to Windows
So that Windows application can open it.

When I observed the trace of the spice server, I found vdagent seems to be created after Windows viritio driver is loaded. 
In other words, the creation of vdagent device seems to be triggered by the Windows OS other than from the qemu command line.
By the same token, "vdprint" should be created after "com.redhat.print.0" is loaded by Windows OS.

So far, I am still looking at the link between "vdprint" and "com.redhat.print.0". It looks like the virioserial driver must be modified.
Otherwise, how the Windows application can see such a device?

-----Original Message-----
From: Alon Levy [mailto:alevy at redhat.com] 
Sent: Thursday, March 22, 2012 10:22 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-devel at lists.freedesktop.org
Subject: Re: Fail to create a printing channel

On Thu, Mar 22, 2012 at 09:55:45PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Alon,
> 
> I did all of what you mentioned before. Nothing is missed in my checklist.
> Function "spice_server_char_device_add_interface" in fact is not called at all.
> Qemu somehow is blocked somewhere. For now, I still do not know the root cause.
> 

OK. So nothing comes to mind. Where is it stuck?

> 
> -----Original Message-----
> From: Alon Levy [mailto:alevy at redhat.com]
> Sent: Thursday, March 22, 2012 9:47 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: spice-devel at lists.freedesktop.org
> Subject: Re: Fail to create a printing channel
> 
> On Thu, Mar 22, 2012 at 07:34:38PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Alon,
> 
> Or anyone else on the list..
> 
> > 
> > 	I am running the following script to create the printing channel based on the virtio device framework.
> > 	When the VM is launched, it seems to block somewhere in Qemu.
> > 
> > 	If I remove the following two lines, the VM can be launched without any problem.		
> > 	The following two lines basically are used to create the printing channel between the host and guest.
> > 
> > 	-chardev spicevmc,id=vdprint,name=vdprint \
> > 	-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
> > 
> > 	Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any 	function in Qemu I need to change so as to create additional channel within the Virtio device?
> > 
> > 	Let me know if I made anything wrong with my Qemu's command options. Thanks.
> 
> How it works right now, and it's probably not how we want it to be, is that there is a function qemu calls to get the allowed list of names by spice-server. That function is implemented by spice-server, so you would need to add the "vdprint" string to it.
> 
> diff --git a/server/reds.c b/server/reds.c index c54d30c..bb75624 
> 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -3364,6 +3364,7 @@ SPICE_GNUC_VISIBLE void 
> spice_server_char_device_wakeup(SpiceCharDeviceInstance*
>  #define SUBTYPE_VDAGENT "vdagent"
>  #define SUBTYPE_SMARTCARD "smartcard"
>  #define SUBTYPE_USBREDIR "usbredir"
> +#define SUBTYPE_PRINTER "printer"
>  
>  const char *spice_server_char_device_recognized_subtypes_list[] = {
>      SUBTYPE_VDAGENT,
> @@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
>      SUBTYPE_SMARTCARD,
>  #endif
>      SUBTYPE_USBREDIR,
> +    SUBTYPE_PRINTER,
>      NULL,
>  };
> 
> Then you need to tell spice what to do when spice_server_char_device_add_interface is called with this subtype (subtype == 'name' parameter to the chardev. Another thing that should be changed).
> 
> You could basically just use another spicevmc_device_connect call. You 
> will need to add the channel to the spice.proto (again, this should be 
> changed so adding generic channels doesn't require this - something 
> like having a generic channel subtype, and having a message that tells 
> the client which channel this is - will be a little ugly since getting 
> a channel list won't be enough for the client to know what channels 
> are available, but it's not too bad - anyway off topic)
> 
> For now you can just change the spice-protocol/spice/enums.h file directly instead of recreating it:
> 
> U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff diff 
> --git a/spice/enums.h b/spice/enums.h index d2dbfd0..9f54ac0 100644
> --- a/spice/enums.h
> +++ b/spice/enums.h
> @@ -330,6 +330,7 @@ enum {
>      SPICE_CHANNEL_TUNNEL,
>      SPICE_CHANNEL_SMARTCARD,
>      SPICE_CHANNEL_USBREDIR,
> +    SPICE_CHANNEL_PRINTER,
>  
>      SPICE_END_CHANNEL
>  };
> 
> @@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
>          }
>      }
>  #endif
> +    /* all other channels use the generic spicevmc channel */
>      else if (strcmp(char_device->subtype, SUBTYPE_USBREDIR) == 0) {
>          spicevmc_device_connect(char_device, SPICE_CHANNEL_USBREDIR);
>      }
> +    else if (strcmp(char_device->subtype, SUBTYPE_PRINTER) == 0) {
> +        spicevmc_device_connect(char_device, SPICE_CHANNEL_PRINTER);
> +    }
>      return 0;
>  }
> 
> Hope you can understand my not very collected response.
> 
> Bonus points for sending patches to fix the raised issues, or starting a discussion on how to exactly.
> 
> Alon
> 
> > ==================================
> > 
> > #!/bin/sh
> > 
> > ARGS="-localtime -spice port=5900,disable-ticketing \ -drive 
> > file=/opt/virt/user/Win7_64.cow \ -vga qxl \ -device 
> > virtio-serial-pci,multifunction=on \ -chardev 
> > spicevmc,id=vdagent,id=vdagent,name=vdagent \ -device
> > virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ -usbdevice 
> > tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \ 
> > -chardev spicevmc,id=vdprint,name=vdprint \ -device 
> > virtserialport,chardev=vdprint,name=com.redhat.print.0"