[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#995322: closed by Brian Potkin <claremont102@gmail.com> (Re: Bug#995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working)



On Thu 30 Sep 2021 at 08:57:13 +0200, Giacomo Mulas wrote:

> On Wed, 29 Sep 2021, Debian Bug Tracking System wrote:
>
> > #995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working
> >
> > It has been closed by Brian Potkin <claremont102@gmail.com>.
> >
> > Much of your time would have been saved by reading the Release
> > Notes. Please submit another report if you feel the documentation
> > is inadequate.
>
> Indeed it is. As I said, ipp-usb got automatically installed upon upgrading
> to bullseye, together with tons of other packages. The only piece of
> information I was shown was the NEWS.Debian file of ipp-usb (together with
> dozens of other messages). The only thing it says is "Existing or newly
> created queues on a USB connection for IPP-over-USB
> capable devices using vendor drivers will not work while the ipp-usb
> service is activated and managing the connection."
> This is only about printing, no clue about other functions of the same
> device.

ipp-usb is a recommended package for cups-daemon and libsane1. That
the NEWS file does not mention scanning is a fair point. Does the
addotion of a third paragrapgh allay your concern?

If so, I woud suggest subnitting a report against ipp-usb. The change
is not extensive and could make it into a bullseye point release.

-------------------------------------------------------------------

ipp-usb uses the IPP-over-USB protocol to allow the setting up of a
driverless print queue for most USB connected modern multi-function
and a few modern USB-only devices. The default is to auto-setup the
queue with cups-browsed.

Existing or newly created queues on a USB connection for IPP-over-USB
capable devices using vendor drivers will not work while the ipp-usb
service is activated and managing the connection.

The same protocol also allows discovery of modern scanner devices via
libsane1. Oncve again, vendor drivers will not work while the ipp-usb
service is activated and managing the connection.

Details are at

https://wiki.debian.org/CUPSDriverlessPrinting

-------------------------------------------------------------------

BTW, Xsane should have given you two backends to access. hpaio will
not work bit escl should. I guess that was not the case. That is a bug
in escl and why the wiko points to sane-airscan as an alternative.

> Only _after_ discovering that ipp-usb was preventing xsane to
> connect to the scanner I looked at
> https://wiki.debian.org/CUPSDriverlessPrinting
> and found this warning in there:
> "Note that IPP-over-USB reserves the USB interface connection with the
> printer/scanner exclusively for itself and communication with a
> printer/scanner device by software that does not operate using the
> IPP-over-USB protocol becomes impossible while ipp-usb is running.  This is
> a consequence of the design of USB communication.  It is not a bug in
> ipp-usb.  (omissis) Communicating with a USB connected scanner via classic
> SANE backends such as libsane-hpaio, sane-pixma or sane-epson2 also becomes
> impossible with the ipp-usb daemon active and running."
>
> Had I seen _this_ warning in the release notes, _then_ this would have got
> some alarm ringing and I would not have wasted hours tracking this.
>
> So, please: do include the above warning, in full, in the release notes of
> ipp-usb.

I think that duplicating in the Release Notes what is on the wiki is not
the way to go, but you could submit a bug against the release-notes
pseudo-package.

> Also, it would be helpful to add at least a "Suggests" to install also the
> package sane-airscan along with it, since this will restore most
> multifunction devices to properly work again as scanners when ipp-usb is
> running.

That would be for the libsane1 maintainer to consider. Note that he has
already declined to make sane-airscan a Recommends:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971658

Cheers,

Brian.


Reply to: