On 1/14/22 5:32 PM, Gerd Hoffmann wrote:
> Hi,
>
>> This patchset introduces:
>>
>> 1) Skeleton of QEMU printer subsystem with a dummy builtin driver.
>>
>> 2) USB printer device emulation, with definitions in the extension of IPP-over-
>> USB [3].
>>
>> WIP:
>>
>> 1) QEMU printer subsystem interfaces, which will be finalized with a concrete
>> backend driver.
>>
>> 2) IPP-over-USB implementation.
>
> Hmm, I'm wondering what uses cases you have in mind and whenever
> it makes sense to introduce a printer subsystem?
I'm having an idea about the use case, let's discuss a bit more about it
here.
If I want to expose some Virtual Device Interfaces (VDI) on USB-IPP
printer device to remote desktop service like spice-server, is it
rational to register these interfaces to the printer subsystem which
will play as a middle layer? A concrete example is QXL virtual GPU with
VDI between QEMU and spice-server. What if other QEMU-emulated devices
also want to take part in the spice service routine? This can be
achieved naturally by the registered handlers in the subsystems, which
further exchange data with the underlying devices (USB-IPP printer here,
for example). Nevertheless, I totally agree that it is straightforward
to make devices like USB-IPP printer to be passed-through in local
environments, which prompts me to add the uri-option. But I want it to
be compatible with other use cases, like this one.
I'll give this idea a try.
>
> Having an ipp-over-usb device looks useful, but the only use case I can
> see is to allow guests access a network printer. I can't see the
> benefits of a printer subsystem, especially in a world where non-ipp
> printers are going extinct. We would most likely have just a single
> kind of printer backend, where the only job qemu will have is to
> forwarding requests and replies, maybe with some http header rewriting.
>
> Likewise usb would be the one and only device (parallel ports are long
> gone in printers). So the indirection added by a printer subsystem
> doesn't buy us anything because we just don't need that flexibility.
> I'd suggest to pass the url directly to the device instead:
>
> qemu -device usb-ipp-printer,url=ipp://hostname/ipp/printer
>
> take care,
> Gerd
>
Regards,
Ruien