Thanks. Otherwise, I cannot get it when I read Windows service code. -----Original Message----- From: Alon Levy [mailto:al...@redhat.com] Sent: Tuesday, March 13, 2012 7:09 PM To: Charles.Tsai-蔡清海-研究發展部 Cc: spice-devel@lists.freedesktop.org Subject: Re: [Spice-devel] Access local network printer from guest OS
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:al...@redhat.com] > Sent: Tuesday, March 13, 2012 6:17 PM > To: Charles.Tsai-蔡清海-研究發展部 > Cc: spice-devel@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:al...@redhat.com] > > Sent: Tuesday, March 13, 2012 5:27 PM > > To: Charles.Tsai-蔡清海-研究發展部 > > Cc: spice-devel@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:al...@redhat.com] > > > Sent: Tuesday, March 13, 2012 4:06 PM > > > To: Charles.Tsai-蔡清海-研究發展部 > > > Cc: spice-devel@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:al...@redhat.com] > > > > Sent: Monday, March 12, 2012 6:08 PM > > > > To: Charles.Tsai-蔡清海-研究發展部 > > > > Cc: spice-devel@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:al...@redhat.com] > > > > > Sent: Monday, March 12, 2012 3:17 PM > > > > > To: Charles.Tsai-蔡清海-研究發展部 > > > > > Cc: spice-devel@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:al...@redhat.com] > > > > > > Sent: Saturday, March 10, 2012 6:35 PM > > > > > > To: Charles.Tsai-蔡清海-研究發展部 > > > > > > Cc: spice-devel@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:al...@redhat.com] > > > > > > > Sent: Monday, January 02, 2012 7:49 PM > > > > > > > To: Charles.Tsai-蔡清海-工程部 > > > > > > > Cc: spice-devel@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:al...@redhat.com] > > > > > > > > Sent: Monday, January 02, 2012 6:19 PM > > > > > > > > To: Charles.Tsai-蔡清海-工程部 > > > > > > > > Cc: spice-devel@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:al...@redhat.com] > > > > > > > > > Sent: Sunday, January 01, 2012 10:19 PM > > > > > > > > > To: Charles.Tsai-蔡清海-工程部 > > > > > > > > > Cc: spice-devel@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:al...@redhat.com] > > > > > > > > > > Sent: Sunday, January 01, 2012 7:45 PM > > > > > > > > > > To: Charles.Tsai-蔡清海-工程部 > > > > > > > > > > Cc: spice-devel@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@lists.freedesktop.org > > > > > > > > > > > http://lists.freedesktop.org/mailman/listinfo/spic > > > > > > > > > > > e- > > > > > > > > > > > de > > > > > > > > > > > ve > > > > > > > > > > > l > > > > > > > > > > _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
