Alon, Thanks. Your additional information will help me a lot when I debug the code. I don't expect my code to work without tracing and debugging the code.
-----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/spice-devel > > > > > > _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
