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:[email protected]]
> Sent: Tuesday, March 13, 2012 4:06 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: [email protected]
> 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:[email protected]]
> > Sent: Monday, March 12, 2012 6:08 PM
> > To: Charles.Tsai-蔡清海-研究發展部
> > Cc: [email protected]
> > 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:[email protected]]
> > > Sent: Monday, March 12, 2012 3:17 PM
> > > To: Charles.Tsai-蔡清海-研究發展部
> > > Cc: [email protected]
> > > 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:[email protected]]
> > > > Sent: Saturday, March 10, 2012 6:35 PM
> > > > To: Charles.Tsai-蔡清海-研究發展部
> > > > Cc: [email protected]
> > > > 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:[email protected]]
> > > > > Sent: Monday, January 02, 2012 7:49 PM
> > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > Cc: [email protected]; 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:[email protected]]
> > > > > > Sent: Monday, January 02, 2012 6:19 PM
> > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > Cc: [email protected]
> > > > > > 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:[email protected]]
> > > > > > > Sent: Sunday, January 01, 2012 10:19 PM
> > > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > > Cc: [email protected]
> > > > > > > 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:[email protected]]
> > > > > > > > Sent: Sunday, January 01, 2012 7:45 PM
> > > > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > > > Cc: [email protected]
> > > > > > > > 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
> > > > > > > > > [email protected]
> > > > > > > > > http://lists.freedesktop.org/mailman/listinfo/spice-deve
> > > > > > > > > l
> > > > > > > >
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
