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/spice-de > > > > > > > > > > ve > > > > > > > > > > l > > > > > > > > > _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
