Alon,
Let me recap what you suggest in case that I missed your point.
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.
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.
-----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-devel
>
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
