Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Immediately detach from devices with claimed but broken IPP over USB support #52

Closed
alexpevzner opened this issue May 9, 2022 · 2 comments
Closed

Immediately detach from devices with claimed but broken IPP over USB support #52

alexpevzner opened this issue May 9, 2022 · 2 comments

Comments

@alexpevzner
Copy link
Member

Some printers announce presence of the 7/1/4 interfaces, but IPP over USB doesn't work due to their firmware errors. At least two of such devices already known:

HP Inc. HP Laser MFP 135a
HP Inc. HP Laser 107a

The proposed solution from here:
https://bugs.launchpad.net/ubuntu/+source/ipp-usb/+bug/1970055

@tillkamppeter

Alexander, as ipp-usb starts to communicate with the printer as soon as it attaches to it, you could perhaps add a mechanism that somehow finds out whether the printer is actually driverless or not, and if not, unattach ipp-usb immediately to give way for classic access (CUPS backend or Printer Application).

Basically, I agree with the following comments:

  1. There will be possible race condition between failed attempt of the ipp-usb to initialize the device and CUPS attempt to claim the device. If device looks like taken by the ipp-usb, CUPS should retry within a some reasonable time
  2. Some visibility is required that ipp-usb has rejected the device due to initialization error, to simplify processing of users' bug reports. Should such a device still be advertised on Avahi on some special manner, so CUPS/sane-airscan will ignore it, but it still can be listed with avahi-browse?
alexpevzner added a commit that referenced this issue May 12, 2022
@alexpevzner
Detach from device, if it doesn't speak IPP over USB protocol (see #52)
a1bad7c 
    Some devices (so far, only HP-rebranded Samsung devices
    known to have such a defect) offer 7/1/4 interfaces, but
    actually provide no functionality behind these interfaces
    and respond with `HTTP 404 Not found` to all the HTTP
    requests sent to USB

    ipp-usb ignores such devices to let legacy/proprietary
    drivers a chance to work with them
alexpevzner added a commit that referenced this issue May 14, 2022
@alexpevzner
Added ipp-usb status command, for troubleshooting
0dae5a2 
    The `ipp-usb status` command prints actual status of all
    attached 7/1/4 devices. It is designed with a purpose to
    add some visibility in a case of troubleshooting. See also #52
@alexpevzner
Copy link
Member Author

Some visibility is required that ipp-usb has rejected the device due to initialization error, to simplify processing of users' bug reports. Should such a device still be advertised on Avahi on some special manner, so CUPS/sane-airscan will ignore it, but it still can be listed with avahi-browse?

My answer to myself here is the newly added ipp-usb status command, which prints actual status of all attached/recognized 7/1/4 devices, including those of them which are ignored by the ipp-usb either due to the explicit blacklisting, or because device initialization failed.

@alexpevzner
Copy link
Member Author

Done in 0.9.22

@alexpevzner alexpevzner mentioned this issue May 31, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@alexpevzner