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
