[Spice-devel] Fail to create a printing channel

[Alon Levy]

On Fri, Mar 23, 2012 at 05:08:34AM +0000, Charles.Tsai-蔡清海-研究發展部 wrote:
> 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?

For vdagent, what you have is:
 qemu virtio serial bus pci device
 qemu virtio serial port named "com.redhat.spice.0"
 guest virtio serial pci driver
 guest vdservice.exe
 guest vdagent.exe

Guest startup:
 loads virtio serial pci driver.
 -> creates a device file for named "com.redhat.spice.0"
 starts vdservice.exe
 -> opens the file "com.redhat.spice.0"
 starts vdagent.exe

So for the printer driver I imagined you would have a printer driver,
vdprint.sys, that would do the same as vdservice.exe, i.e.

Setup:
 virtio serial bus
 virtio serial port "com.redhat.print.0"
 guest virtio serial pci driver
 guest vdprinter driver (needs to make sure this loads after virtio)

Startup:
 load virtio serial pci driver
 load vdprinter driver

Alon
> 
> 
> -----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"