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
