[PATCH 0/2] Introduce printer subsystem and USB printer device

Ruien Zhang posted 2 patches 2 weeks ago
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20220113115659.72788-1-zhangruien@bytedance.com
Maintainers: Michael Roth <michael.roth@amd.com>, Paolo Bonzini <pbonzini@redhat.com>, Markus Armbruster <armbru@redhat.com>, Eric Blake <eblake@redhat.com>
MAINTAINERS                 |   7 +
docs/system/devices/usb.rst |   3 +
hw/usb/Kconfig              |   5 +
hw/usb/dev-printer.c        | 423 ++++++++++++++++++++++++++++++++++++++++++++
hw/usb/meson.build          |   1 +
hw/usb/trace-events         |  11 ++
include/hw/usb/printer.h    |  93 ++++++++++
include/printer/printer.h   |  42 +++++
meson.build                 |  12 +-
meson_options.txt           |   3 +
printer/builtin.c           |  61 +++++++
printer/meson.build         |  14 ++
printer/printer.c           | 191 ++++++++++++++++++++
printer/trace-events        |   5 +
printer/trace.h             |   1 +
qapi/meson.build            |   1 +
qapi/printer.json           |  47 +++++
qapi/qapi-schema.json       |   1 +
qemu-options.hx             |   8 +
softmmu/vl.c                |   4 +
20 files changed, 932 insertions(+), 1 deletion(-)
create mode 100644 hw/usb/dev-printer.c
create mode 100644 include/hw/usb/printer.h
create mode 100644 include/printer/printer.h
create mode 100644 printer/builtin.c
create mode 100644 printer/meson.build
create mode 100644 printer/printer.c
create mode 100644 printer/trace-events
create mode 100644 printer/trace.h
create mode 100644 qapi/printer.json

[PATCH 0/2] Introduce printer subsystem and USB printer device

Posted by Ruien Zhang 2 weeks ago
From: zhangruien <zhangruien@bytedance.com>

Currently, printer support in QEMU can generally be considered with these
approaches:

1) USB passthrough & redirection, with the limitation of flexibility and
   transport-specific issues that come along with.

2) Network reachability with network printers, which is also driver-specific,
   thus less friendly to small systems.

Driverless Printing [1] may or may not be network-dependent, the former is the
general case while the latter imposes less restraints on cloud environments, and
it doesn't necessarily mean that we have to follow the methods in 1) to achieve
this. Transport protocols targeted at devices such as USB printer class [2] with
the extension of IPP-over-USB [3] and many others can be integrated into QEMU,
presenting more flexibility and functionality.

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.

[1]: https://openprinting.github.io/driverless
[2]: https://www.usb.org/sites/default/files/usbprint11a021811.pdf
[3]: https://www.usb.org/document-library/ipp-protocol-10

zhangruien (2):
  printer: Introduce printer subsystem
  usb-printer: Introduce USB printer class

 MAINTAINERS                 |   7 +
 docs/system/devices/usb.rst |   3 +
 hw/usb/Kconfig              |   5 +
 hw/usb/dev-printer.c        | 423 ++++++++++++++++++++++++++++++++++++++++++++
 hw/usb/meson.build          |   1 +
 hw/usb/trace-events         |  11 ++
 include/hw/usb/printer.h    |  93 ++++++++++
 include/printer/printer.h   |  42 +++++
 meson.build                 |  12 +-
 meson_options.txt           |   3 +
 printer/builtin.c           |  61 +++++++
 printer/meson.build         |  14 ++
 printer/printer.c           | 191 ++++++++++++++++++++
 printer/trace-events        |   5 +
 printer/trace.h             |   1 +
 qapi/meson.build            |   1 +
 qapi/printer.json           |  47 +++++
 qapi/qapi-schema.json       |   1 +
 qemu-options.hx             |   8 +
 softmmu/vl.c                |   4 +
 20 files changed, 932 insertions(+), 1 deletion(-)
 create mode 100644 hw/usb/dev-printer.c
 create mode 100644 include/hw/usb/printer.h
 create mode 100644 include/printer/printer.h
 create mode 100644 printer/builtin.c
 create mode 100644 printer/meson.build
 create mode 100644 printer/printer.c
 create mode 100644 printer/trace-events
 create mode 100644 printer/trace.h
 create mode 100644 qapi/printer.json

-- 
2.11.0


Re: [PATCH 0/2] Introduce printer subsystem and USB printer device

Posted by Gerd Hoffmann 1 week, 6 days ago
  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?

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


Re: [PATCH 0/2] Introduce printer subsystem and USB printer device

Posted by Ruien Zhang 1 week, 5 days ago
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


Re: [PATCH 0/2] Introduce printer subsystem and USB printer device

Posted by Gerd Hoffmann 1 week, 3 days ago
  Hi,

> 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?

I'd suggest to implement the usb printer in the spice client then and
connect it to the virtual machine using the usb redirection protocol,
similar to the existing usb storage emulation for cdrom redirection.

take care,
  Gerd


Re: [PATCH 0/2] Introduce printer subsystem and USB printer device

Posted by Ruien Zhang 1 week, 6 days ago
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?
> 

Simply for the "potential" backend diversity. I have to admit that I 
haven't figured out another backend which would be commonly-seen either, 
which is also one part of the reason why the interfaces are not firming 
up right now.

> 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
> 

Indeed, the subsystem is an over-abstraction. The forwarding way is much 
neater, considering how things really work nowadays.

Anyway, thanks for the practical suggestion, it will be revised, along 
with other designs around the path I'm currently working on.

Regards,
Ruien