[Spice-devel] Access local network printer from guest OS
Alon Levy
alevy at redhat.com
Tue Mar 13 04:08:44 PDT 2012
On Tue, Mar 13, 2012 at 06:32:55PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Thanks. I got it now. How come the code is still there.
Because the same code base is for guests using the new virtserialport
and the old vdi_port. That device is still in RHEL 5.
> I believe that CreateFile API fails definitely because there is no such a device in the system.
>
>
> -----Original Message-----
> From: Alon Levy [mailto:alevy at redhat.com]
> Sent: Tuesday, March 13, 2012 6:17 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: spice-devel at lists.freedesktop.org
> Subject: Re: [Spice-devel] Access local network printer from guest OS
>
> On Tue, Mar 13, 2012 at 05:32:13PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Alon,
> >
> > Yes, I did see these. But I think this device is no longer used by the service.
> > That is why I want to clarify my puzzle.
> >
>
> Charles, the puzzle is simple: it isn't being used anymore. You don't create the device, vdagent fails to CreateFile, and moves on to use the virtio serial port.
>
> >
> > -----Original Message-----
> > From: Alon Levy [mailto:alevy at redhat.com]
> > Sent: Tuesday, March 13, 2012 5:27 PM
> > To: Charles.Tsai-蔡清海-研究發展部
> > Cc: spice-devel at lists.freedesktop.org
> > Subject: Re: [Spice-devel] Access local network printer from guest OS
> >
> > On Tue, Mar 13, 2012 at 04:09:56PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > Alon,
> > >
> > > Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.
> > >
> >
> > win32-vdagent alon (master)$ git grep VDI_PORT_DEV_NAME
> > vdservice/pci_vdi_port.cpp:#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
> > vdservice/pci_vdi_port.cpp: _handle = CreateFile(VDI_PORT_DEV_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,
> >
> > looking at git://anongit.freedesktop.org/spice/win32/vd_agent
> > >
> > >
> > > -----Original Message-----
> > > From: Alon Levy [mailto:alevy at redhat.com]
> > > Sent: Tuesday, March 13, 2012 4:06 PM
> > > To: Charles.Tsai-蔡清海-研究發展部
> > > Cc: spice-devel at lists.freedesktop.org
> > > Subject: Re: [Spice-devel] Access local network printer from guest
> > > OS
> > >
> > > On Tue, Mar 13, 2012 at 03:06:17PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > Alon,
> > > >
> > > > I am reading the source code of the vdservice for Windows guest OS. "vdservice" if fact is a proxy software between Windows application and VirIO serial driver.
> > > > I was suppressed to find that " vdservice" open two Windows kernel driver. In Windows, I only find one VirtIO PCI driver. Why " vdservice" can open two kernel drivers?
> > > > Do I miss something or something wrong with the implementation? Can you tell me why?
> > > >
> > > > You can find the following device logical names from pci_vdi_port.cpp and virtio_vdi_port.cpp.
> > > >
> > > > #define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
> > > > #define VIOSERIAL_PORT_PATH L"\\\\.\\Global\\com.redhat.spice.0"
> > > >
> > > > I can imagine that device "\\\\.\\Global\\com.redhat.spice.0" is created from Qemu command line. But where is the device "\\\\.\\VDIPort" created from?
> > > > Why there are two interfaces are exposed to Windows guest OS?
> > > >
> > >
> > > Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.
> > >
> > > In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.
> > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Alon Levy [mailto:alevy at redhat.com]
> > > > Sent: Monday, March 12, 2012 6:08 PM
> > > > To: Charles.Tsai-蔡清海-研究發展部
> > > > Cc: spice-devel at lists.freedesktop.org
> > > > Subject: Re: [Spice-devel] Access local network printer from guest
> > > > OS
> > > >
> > > > On Mon, Mar 12, 2012 at 05:51:32PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > > Alon,
> > > > >
> > > > > Here is a little bit confusion to me and you might be able to clear my puzzle.
> > > > >
> > > > > If launching a VM by adding the following options can create a separate VirIO for virtual printer driver, how the Qemu maps this logical channel to printing channel?
> > > > > In other words, Windows guest OS writes the data to "com.redhat.spice.printer.0" channel through the VirIO API, why the captured printing raw data can be seen in printing channel in spice server?
> > > > >
> > > > > -device virtio-serial,multifunction=on -chardev
> > > > > spicevmc,name= printagent,id=printagent -device virtserialport,chardev=
> > > > > printagent,name= com.redhat.spice.printer.0
> > > > >
> > > > >
> > > >
> > > > spicevmc chardev would be created once for every -chardev spicevmc command line, and it will be registered via spice_server_add_interface, see spice-qemu-char.c for details. The actual implementation for the printagent subtype would like in spiceserver, but it would open a channel, see:
> > > > spice/server/reds.c: spice_server_char_device_add_interface
> > > > spicevmc_device_connect
> > > >
> > > > Alon
> > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Alon Levy [mailto:alevy at redhat.com]
> > > > > Sent: Monday, March 12, 2012 3:17 PM
> > > > > To: Charles.Tsai-蔡清海-研究發展部
> > > > > Cc: spice-devel at lists.freedesktop.org
> > > > > Subject: Re: [Spice-devel] Access local network printer from
> > > > > guest OS
> > > > >
> > > > > On Mon, Mar 12, 2012 at 10:16:37AM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > > > Alon,
> > > > > >
> > > > > > Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alon Levy [mailto:alevy at redhat.com]
> > > > > > Sent: Saturday, March 10, 2012 6:35 PM
> > > > > > To: Charles.Tsai-蔡清海-研究發展部
> > > > > > Cc: spice-devel at lists.freedesktop.org
> > > > > > Subject: Re: [Spice-devel] Access local network printer from
> > > > > > guest OS
> > > > > >
> > > > > > On Sat, Mar 10, 2012 at 10:58:27AM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > > > > Alon,
> > > > > > >
> > > > > > > I am implementing the code for the printing redirection for spice client. In the windows client, I know how to do it. Basically, I just follow the footprint of the playback channel. However, I still have a question regarding how my virtual printer driver delivers the printing raw data to SPICE server.
> > > > > > >
> > > > > >
> > > > > > Why are you copying the playback channel and not one of the red_channel converted channels, like inputs? playback is actually special, it has a bitset of possible pending messages, same for the record channel, while all other channels use a pipe (they can have multiple same type pending messages).
> > > > > >
> > > > > > > In your previous mail you said,
> > > > > > >
> > > > > > > > The first device is the virtio-serial bus (pci device), the chardev is
> > > > > > > > that spicevmc chardev, id is whatever you like, name is taken from a
> > > > > > > > list of possible names, see below. The third is the port device (needs
> > > > > > > > to be created after the chardev, the parameters are processed by order
> > > > > > > > given in the command line from left to right), the name is the guest
> > > > > > > > visible device created, I don't rememer exactly the device name in
> > > > > > > > windows but something like
> > > > > > > \\.\vportfoo-com.redhat.spice.0
> > > > > > >
> > > > > > >
> > > > > > > Do you mean that we need to create another virtual PCI port device in the guest and the virtual printer driver simply just send the printing raw data to that virtual PCI port device? If my understanding is correct, we need to use another vendor ID and product ID in order to create a new virtual PCI port device for virtual printer driver. Am I correct?
> > > > > > >
> > > > > >
> > > > > > You don't need a new PCI device, the virtio-serial-bus PCI device supports a number (don't know the limit) of different logical ports, i.e. different streams between the guest and the host.
> > > > > >
> > > > > >
> > > > > > Charles>>>>
> > > > > > This is what I thought after reading your suggestion. In Windows guest OS, the application refers to a logical PCI channel by a device name, for instance "\\\\.\\Global\\com.redhat.spice.0". But logical device name "\\\\.\\Global\\com.redhat.spice.0" is used by "spice agent" already. If we do not create another PCI logical channel for virtual printing device, how the virtual printer driver can talk to that device.
> > > > > >
> > > > >
> > > > > So we are talking about the same thing, I assumed you meant a different PCI device but from the above paragraph I understand you are talking about a virtserialport, not a different PCI device. Calling it a "PCI logical channel" is fine.
> > > > >
> > > > > > Can we do something as follows to create a logical device for
> > > > > > printer device
> > > > > >
> > > > > > -device virtio-serial,multifunction=on -chardev
> > > > > > spicevmc,name=vdagent,id=printagent -device
> > > > > > virtserialport,chardev=
> > > > > > printagent,name=com.redhat.spice.1
> > > > >
> > > > > Yes, but better to use a more descriptive name I guess, the
> > > > > com.redhat.spice.0 idea was not good enough. Maybe keep the "com.redhat.spice" part but add a printer namespace:
> > > > > "com.redhat.spice.printer.0"
> > > > >
> > > > > Would you have one per printer?
> > > > >
> > > > > >
> > > > > > In Windows guest OS, printer driver simply just opens the logical device named "com.redhat.spice.1". After the logical virtio device is opened, printer driver can write the printing raw data to the PCI logical channel by calling the VirtIO API.
> > > > > >
> > > > > > <<<Charles
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Lastly, I read the SPICE server code for USB redirect. I only found a generic code to handle the messages for char device. For the virtual printer driver, it seems to not be able to apply to this case, because
> > > > > > >
> > > > > > >
> > > > > > > 1. the virtual printer driver needs to know which device to talk in order to send the printing raw data to SPICE server.
> > > > > >
> > > > > > USB has the same problem - there can be a number of USB devices on the client, and all wanting to be exposed to the guest. What USB redirection does is create a spicevmc channel plus use a spicevmc chardev for each device. You could do the same thing.
> > > > > >
> > > > > > Charles>>>>
> > > > > > I see your points. How the virtual printing device opens the VirtIo device for the printing channel is the questions I tried to know.
> > > > > > Please see my above question.
> > > > > > <<<Charles
> > > > > >
> > > > > >
> > > > > >
> > > > > > > 2. SPICE server needs to pack the printing raw data in a right format and send it to the spice client.
> > > > > > >
> > > > > >
> > > > > > I'm not sure what the problem here is - if you use spicevmc you would not specify the format of the message passed in this channel via the spice.proto file, but instead pass it opaquely for the server, and only parse it in the guest/host and in the client. Actually I don't think you said what your plans are for the guest/host - how are you going to pass the data from the windows vm to the spice server? are you introducing a new component in the guest? a driver? a user space component that isn't a driver? will you be augmenting spice-vdagent or using something of your own? do you plan to release it under an open source license?
> > > > > >
> > > > > > Charles>>>>
> > > > > > So far, I am still testing the printer driver on a physical machine to prove my concept. Basically, it will be a virtual printer driver. This driver will capture the printing raw data and forward the captured raw data from VM to the spice client. Upon receiving the printing raw data, the spice client will print it from the local printer device.
> > > > >
> > > > > I see. This is totally one directional? And how would the spice client cope with it's own different local printer drivers? and how would you expose multiple available printers in the client to the guest?
> > > > >
> > > > > > <<<Charles
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Please let me know if I miss some points to the
> > > > > > > understanding of the SPICE protocol regarding the
> > > > > > > implementation of the printing redirection. Thanks
> > > > > > >
> > > > > > > Note that "printing redirection" is one-way communication that is initiated from Windows guest OS(VM) to spice client.
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Alon Levy [mailto:alevy at redhat.com]
> > > > > > > Sent: Monday, January 02, 2012 7:49 PM
> > > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > > Cc: spice-devel at lists.freedesktop.org; Alex Huang-黃必賢-工程部
> > > > > > > Subject: Re: [Spice-devel] Access local network printer from
> > > > > > > guest OS
> > > > > > >
> > > > > > > On Mon, Jan 02, 2012 at 07:08:23PM +0800, Charles.Tsai-蔡清海-工程部 wrote:
> > > > > > > > Alon,
> > > > > > > >
> > > > > > > > I have another question regarding the USB redirect for Windows client. In current spice release, the USB redirect only support for Linux client.
> > > > > > >
> > > > > > > Right, but this is a temporary situation, it will be supported in windows clients.
> > > > > > >
> > > > > > > > If we send the printing data through the "spicevmc channel" to the Windows client(not Linux), what is the corresponding channel(file and function) in client to receive the printing data?
> > > > > > >
> > > > > > > That would be the SPICE_CHANNEL_PRINTER you would define. Look at the usbredir channel as an example, or the smartcard channel. (but usbredir is better).
> > > > > > >
> > > > > > > > Is there a files in LINUX client for us to do the design reference?
> > > > > > >
> > > > > > > look at the usbredir implementation in the spice-gtk client.
> > > > > > > channel-usbredir.c.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Alon Levy [mailto:alevy at redhat.com]
> > > > > > > > Sent: Monday, January 02, 2012 6:19 PM
> > > > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > > > Cc: spice-devel at lists.freedesktop.org
> > > > > > > > Subject: Re: [Spice-devel] Access local network printer
> > > > > > > > from guest OS
> > > > > > > >
> > > > > > > > On Mon, Jan 02, 2012 at 10:06:34AM +0800, Charles.Tsai-蔡清海-工程部 wrote:
> > > > > > > > > Alon,
> > > > > > > > >
> > > > > > > > > Let me recap what you suggest in case that I missed your point.
> > > > > > > >
> > > > > > > > sure.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 1. Capturing the printing data from the virtual printer driver.
> > > > > > > > > 2. send the captured data to the " cifs/ipp server" for printing data.
> > > > > > > > > 3. send the printing data to VDI port driver(virtioserial driver).
> > > > > > > > > 4. Spicevmc(in spice server)receives the printing data from VDI port driver.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > In the above scenario, there is nothing to be changed in spice server. Here is my questions regarding this design.
> > > > > > > > >
> > > > > > > > > 1. Why cannot virtual printer driver send the captured data to the VDI port driver directly? The spice agent talks to the VDI port driver directly, doesn't it?
> > > > > > > > >
> > > > > > > > > The virtual printer driver I want to implement is the printer port monitor driver. It captures the printing data between user-mode print spooler and the kernel-mode port drivers that access I/O port hardware.
> > > > > > > >
> > > > > > > > I didn't understand your suggestion to be so specific to windows guests.
> > > > > > > > If you intend to write a windows guest printer port monitor driver (I assume it's a windows guest thing, right?) then of course you don't need an additional guest side anything, and you are correct to point this out.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 2. Which files or functions in virtioserial driver talks to "spicevmc channel"?
> > > > > > > > >
> > > > > > > > > This question is related to question 1. If I know the way how the virtioserial and the spicevmc talk, I can modify my design too.
> > > > > > > > >
> > > > > > > >
> > > > > > > > You create a virtioserial port, you create a chardev, and you tell qemu to connect the port to the chardev, all from the command line:
> > > > > > > > -device virtio-serial,multifunction=on -chardev
> > > > > > > > spicevmc,name=vdagent,id=vdagent -device
> > > > > > > > virtserialport,chardev=vdagent,name=com.redhat.spice.0
> > > > > > > >
> > > > > > > > The first device is the virtio-serial bus (pci device),
> > > > > > > > the chardev is that spicevmc chardev, id is whatever you
> > > > > > > > like, name is taken from a list of possible names, see
> > > > > > > > below. The third is the port device (needs to be created
> > > > > > > > after the chardev, the parameters are processed by order
> > > > > > > > given in the command line from left to right), the name is
> > > > > > > > the guest visible device created, I don't rememer exactly
> > > > > > > > the device name in windows but something like
> > > > > > > > \\.\vportfoo-com.redhat.spice.0
> > > > > > > >
> > > > > > > >
> > > > > > > > Adding a fourth SUBTYPE (there are currently three -
> > > > > > > > VDAGENT, SMARTCARD,
> > > > > > > > USBREDIR) is something like this (and yes, it looks like it might be nice to make it a switch):
> > > > > > > >
> > > > > > > > diff --git a/server/reds.c b/server/reds.c index
> > > > > > > > acd8495..102c254
> > > > > > > > 100644
> > > > > > > > --- a/server/reds.c
> > > > > > > > +++ b/server/reds.c
> > > > > > > > @@ -3261,6 +3261,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,
> > > > > > > > @@ -3268,6 +3269,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
> > > > > > > > SUBTYPE_SMARTCARD,
> > > > > > > > #endif
> > > > > > > > SUBTYPE_USBREDIR,
> > > > > > > > + SUBTYPE_PRINTER,
> > > > > > > > NULL,
> > > > > > > > };
> > > > > > > >
> > > > > > > > @@ -3300,6 +3302,8 @@ static int spice_server_char_device_add_interface(SpiceServer *s, #endif
> > > > > > > > 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;
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > > Defining SPICE_CHANNEL_PRINTER is done via the codegen stuff, you just update spice.proto and run something to produce an updated enums.h.
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Alon Levy [mailto:alevy at redhat.com]
> > > > > > > > > Sent: Sunday, January 01, 2012 10:19 PM
> > > > > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > > > > Cc: spice-devel at lists.freedesktop.org
> > > > > > > > > Subject: Re: [Spice-devel] Access local network printer
> > > > > > > > > from guest OS
> > > > > > > > >
> > > > > > > > > On Sun, Jan 01, 2012 at 09:08:52PM +0800, Charles.Tsai-蔡清海-工程部 wrote:
> > > > > > > > > > Hi Alon,
> > > > > > > > > >
> > > > > > > > > > Your information is extremely valuable for us. I think adding one additional channel is a good solution.
> > > > > > > > > > Because I haven't programmed QEMU before, I have a question regarding creating a virtual printer device.
> > > > > > > > > > In spice agent, the way that the SPICE agent talks to the SPICE server is through a virtual serial port device.
> > > > > > > > > > For the virtual printer device, do I need to create a
> > > > > > > > > > similar virtual I/O for the printer? To send the printing data to the SPICE server from guest OS, the virtual printer device driver will write the printing data to the virtual I/O like a real hardware device. In QEMU, can I find any information about this?
> > > > > > > > > > Thanks.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I am not sure how good the idea of creating a virtual printer is. I see two options, each not optimal:
> > > > > > > > > 1. expose the real printer.
> > > > > > > > > + all features of real printer are avaliable
> > > > > > > > > - guest has to have real printer drivers (so each new client or new
> > > > > > > > > printer on client side requires guest driver installation). This is
> > > > > > > > > not neccessarily hard/bad.
> > > > > > > > > 2. expose a fixed printer (this is what you are proposing)
> > > > > > > > > - subset / fixed set of features.
> > > > > > > > > + no new driver to install, only one time driver install.
> > > > > > > > >
> > > > > > > > > We have previously intended the tunnel channel to provide the printer remoting. But you don't have to expose a whole network tunnel, you could implement a cifs/ipp server with printing services. That could be implemented as a guest daemon talking over a virtioserial port and a spicevmc channel to the client, which means you won't have to change qemu at all, but you would have to add a guest feature (so needs to be implemented and installed for every guest os you want to support). I suppose such a service could also be implemented at the qemu level, and still use a spicevmc channel so no spice server changes either way. I'm not sure what kind of virtual printer you have in mind.
> > > > > > > > >
> > > > > > > > > I haven't actually answer you so far:
> > > > > > > > > - no, you don't need to create a new virtual I/O channel, virtioserial
> > > > > > > > > is just the virtual I/O you need.
> > > > > > > > >
> > > > > > > > > HTH
> > > > > > > > > Alon
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Alon Levy [mailto:alevy at redhat.com]
> > > > > > > > > > Sent: Sunday, January 01, 2012 7:45 PM
> > > > > > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > > > > > Cc: spice-devel at lists.freedesktop.org
> > > > > > > > > > Subject: Re: [Spice-devel] Access local network
> > > > > > > > > > printer from guest OS
> > > > > > > > > >
> > > > > > > > > > On Sun, Jan 01, 2012 at 10:41:14AM +0800, Charles.Tsai-蔡清海-工程部 wrote:
> > > > > > > > > > > All,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > We planned to implement the software to access the local network printer
> > > > > > > > > > > from the guest OS over the SPICE. I did see someone post a message before
> > > > > > > > > > > talking about the implementation of the network redirect before. But the
> > > > > > > > > > > solution seems to be too complicated for us. Here is my design ideas to
> > > > > > > > > > > implement the access of the local network printer from the guest OS.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 1. Implemented a virtual printer driver in the guest OS.
> > > > > > > > > > >
> > > > > > > > > > > 2. Intercept the printing data from the virtual printer driver and
> > > > > > > > > > > forward it to the spice agent.
> > > > > > > > > > >
> > > > > > > > > > > 3. Deliver the printing data from the spice agent through the
> > > > > > > > > > > .$B!H.(Bmain channel.$B!I.(B
> > > > > > > > > > >
> > > > > > > > > > > 4. Spice client receives the printing data and set it to the local
> > > > > > > > > > > network printer.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Based on my design ideas, I have a couple of questions.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 1. Currently, main channel is used by spice agent for enchaining the
> > > > > > > > > > > user experience. Can I expand it to delivered printing data? Any pros and
> > > > > > > > > > > cons?
> > > > > > > > > > >
> > > > > > > > > > > 2. How easily it is to expand one additional channel for priming
> > > > > > > > > > > data if .$B!H.(Bmain channel.$B!I.(B is not a good approach to send
> > > > > > > > > > > printing data?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I would suggest going with adding an additional channel rather then adding messages to main channel. imo the existance of agent data in the main channel is not a good thing and shouldn't be taken as an example of how to do things.
> > > > > > > > > >
> > > > > > > > > > To add a new channel you basically need to:
> > > > > > > > > > 1. add the channel to spice.proto (in spice repository) There are two options here - you can use an opaque channel, and by opaque I mean that the messages it contains are Data messages, no additional information is in them and you have to do parsing "yourself", without the code generation done from spice.proto. If you want to use the code generator then you can take any other channel message as an example. You will then need to update the spice-protocol headers as well, common/messages.h 2. implement server side - the steps are:
> > > > > > > > > > create the new channel. Follow the inputs channel as a good example.
> > > > > > > > > > (server/inputs_channel.c:inputs_init)
> > > > > > > > > > advertise the new channel. This is taken care of by calling
> > > > > > > > > > reds_register_channel.
> > > > > > > > > > you will need to do work based on some call backs from either
> > > > > > > > > > direction:
> > > > > > > > > > qemu initiated (guest did something to the virtual printer device)
> > > > > > > > > > client initiated (callback set during channel creation, in inputs
> > > > > > > > > > it is inputs_channel_handle_parsed) 3. client side implementation:
> > > > > > > > > > you should be working on the spice-gtk client, it is in it's own repository. You will have to make sure the changes (if any) you do to the common subdirectory are copied over since it has it's own copy. Haven't worked on spice-gtk but it looks like again starting from some existing channel like gtk/channel-inputs could be a good idea.
> > > > > > > > > >
> > > > > > > > > > HTH,
> > > > > > > > > > Alon
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Spice-devel mailing list
> > > > > > > > > > > Spice-devel at lists.freedesktop.org
> > > > > > > > > > > http://lists.freedesktop.org/mailman/listinfo/spice-
> > > > > > > > > > > de
> > > > > > > > > > > ve
> > > > > > > > > > > l
> > > > > > > > > >
More information about the Spice-devel
mailing list