after recent round of updates(installed 04/03/22): previously working HP5590 scanner recognised by USB system, but xsane and hp-uiscan hang when trying to find a scanner. skanlite identifies scanner correctly but hangs when asked to scan. When run as root(briefly !!!) the system works as advertised. N.B All sane related libraries present. All hplip libraries and hplip-gui present and working.
Hi, thank you for reporting the issue! It would be great if you could provide the list of packages which were installed/upgraded in that recent round of updates. Because if you have installed CUPS as well on your PC, the latest update started to recommend ipp-usb package which can support devices capable of IPP-over-USB without a driver. If you have such a device, then ipp-usb conflicts with hplip and it is recommended to remove hplip[2] and let sane-airscan (SANE backend which provides support for eSCL and WSD protocols) to work with the device. If the device supports IPP-over-USB and eSCL or WSD protocols, then ipp-usb enables the USB device on localhost as a network scanner, and sane-airscan will recognize it during xsane/simple-scan sessions. Would you mind attaching output of 'lsusb -v' and files from /var/log/ipp-usb as attachments in this ticket? Additionally, please follow the steps[1] and attach the requested logs as attachments at this ticket. [1] https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-problems/#_debugging_scanner_discovery [2] https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_hp_usb_printerscanner_doesnt_work_due_a_conflict_on_usb_port
Created attachment 1865128 [details] nearest to requested info In an effort to actually get some work done I did a completelty vanilla upgrade to F35 yesterday. The good news is that everything including the scanner now work perfectly out of the box. The bad news is that I don't have all the info you requested available. My best effort is attached as a pdf
(In reply to Zdenek Dohnal from comment #1) > Would you mind attaching output of 'lsusb -v' and files from ^ '-v' parameter is needed to find out whether the device supports IPP-over-USB, the output you've provided is from default `lsusb`. Please provide the verbose output of lsusb. I see libsane-hpaio installed - is ipp-usb installed as well? If it is not, it will be installed with next CUPS upgrade or during generic dnf upgrade and the issue will reappear.
Created attachment 1865157 [details] check for ipp and lusb -v This is my best shot. NOTE that the system has been upgradeded to F35 without intervention, so any stuff installed by default by the upgrade process will be showing up.
`lsusb -v` does not generate any output regarding the device if the device is not plugged in and turned on. Once you plug it in and turn on, run `scanimage -L` and post output here.
Created attachment 1865208 [details] requested info Here's what would have been in the lsusb o/p if I'd thought you would be interested in the specific characteristics of the device -- my bad. Plus the o/p from scanimage -L
FWIW I've had the same problem with HP OfficeJet 6950 (wouldn't do anything anymore on Linux after a recent update, but works fine on Windows), but uninstalling hplip and reconfiguring my scanning software to use scanimage as frontend fixed it. Only potential problem is that now the fax functionality is not recognized on Linux anymore...it doesn't show up in my Printer Settings. I don't usually need that but might be useful in the future; any ideas?
(In reply to wscg45 from comment #6) > Created attachment 1865208 [details] > requested info > > Here's what would have been in the lsusb o/p if I'd thought you would be > interested in the specific characteristics of the device -- my bad. Plus the > o/p from scanimage -L Thank you for the information! Hmm... I see there are good news and bad news - good news are the device is supported in sane-backends itself, by hp5590 backend, and you don't need hplip and its proprietary plugin for scanning. Bad news (at least for me) are the device doesn't support IPP-over-USB, so ipp-usb shouldn't be in the game at all, so either ipp-usb does something it shouldn't, or something else causes the issue. Do you want to dig further, try to set your PC for the issue to reappear and further debug, or are you okay with the current situation and don't want to pursue the reason why it didn't work?
Hi Christian, thank you for letting me know! Did you use the fax with hplip in the past? Did it work for you? If we should further debug/setup fax, we should know whether the fax actually worked in the past and have a way how to test. If you can test the fax (IIRC you would be the second person I've heard about that he uses fax - the first was fax related project upstream), then we can see whether the device supports IPP Fax out - driverless version for fax, available in cups-filters package as driverless-fax binary.
Hi Zdenek Since my system now works fine under F35 and I was going to upgrade to 35 as a routine matter soon anyway, I don't think I feel very inclined to revert to F34 for the purpose of the present investigation. However, I am troubled by the fact that exactly the same software environment drives the scanner seamlessly (as it should) when the libraries and applications are F35 versions and as it did until very recently when they were F34 versions, but suddenly an update set to F34 causes this conflict and stops things working. Apart from straightfoward intellectual curiosity, I'm troubled by the thought that the potential exists for a similar infelicity to occur with the update stream for F35. Should that occur you may rest assured that I'll re-open this question and be available to investigate until the matter is resolved. However, I am tempted to suggest that the problem must lie in either ipp-usb, or sane-backends-drivers-scanners and that perhaps there might be some mileage in looking at the differences between the F34 and F34 versions of these libraries and/or in the way that they are utilised during the aquisition process for the scanner.. If that's a stupid suggestion then I appologise unreservedly in advance !
Just an adendum to my last comment. Is there any information to be gained from the fact that when the system was malfunctioning and refusing to run any scanner application as "user" it was possible (if risky) to run xsane successfully when the invoking user was root. This feels to me like a perms problem, does it not ?
Hi Zdenek, I have used fax in the past and I also have a way to test it, but I'm not sure whether I ever sent a fax from Linux...it definitely works directly from the printer/fax machine and also from my router, though. It would be nice to get this to work, because the only way to send fax purely electronically right now for me is through the router and the router only allows sending one scanned page at a time and does it in abysmal quality, while Fedora (e.g. xsane) allows setting higher LPI and sending multiple pages. No rush, though, as I don't expect needing this functionality right away. So far I tried using efax directly since xsane didn't work (it successfully put the files in queue but nothing more happened): 'efax -d /dev/bus/usb/003/007 -t xxxxxxxxxxxx transfer/test2/testfax*' where the x'es are the target fax number (it works) and the /dev/... address is where my printer is according to lsusb. This is probably not correct, as I get a 'can't open serial port /dev/bus/usb/003/007: Permission denied' error and I haven't set up any IPP Fax out yet; the images to be faxed are recognized correctly as being in the right format (G3), however. How do I set up this IPP Fax out?
FEDORA-2022-016b7d39db has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-016b7d39db
(In reply to wscg45 from comment #10) > Hi Zdenek > Since my system now works fine under F35 and I was going to upgrade to 35 as > a routine matter soon anyway, I don't think I feel very inclined to revert > to F34 for the purpose of the present investigation. Ok, I understand that. > > However, I am troubled by the fact that exactly the same software > environment drives the scanner seamlessly (as it should) when the libraries > and applications are F35 versions and as it did until very recently when > they were F34 versions, but suddenly an update set to F34 causes this > conflict and stops things working. Actually I had a similar problem in F35 last week and libusb1 update to its testing version helped me there, so there could be other packages in the game. > > Apart from straightfoward intellectual curiosity, I'm troubled by the > thought that the potential exists for a similar infelicity to occur with the > update stream for F35. Should that occur you may rest assured that I'll > re-open this question and be available to investigate until the matter is > resolved. Thank you for that! I'll revert the recommendation of ipp-usb for F35 and F34 for now, hopefully it will help others affected by the issue on stable releases. (In reply to wscg45 from comment #11) > Just an adendum to my last comment. Is there any information to be gained > from the fact that when the system was malfunctioning and refusing to run > any scanner application as "user" it was possible (if risky) to run xsane > successfully when the invoking user was root. This feels to me like a perms > problem, does it not ? Yes, it can be connected - but your scanner doesn't support IPP-over-USB at all, so ipp-usb shouldn't even start (ipp-usb is started only if the connected device matches udev rule for IPP-over-USB which is not the case for your device according to lsusb output you've provided). My guess there was a clash in 'libusb'? But for more info we would have needed a setup where we can reproduce the issue...
FEDORA-2022-352f2e3280 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-352f2e3280
(In reply to Christian F. from comment #12) > Hi Zdenek, > > I have used fax in the past and I also have a way to test it, but I'm not > sure whether I ever sent a fax from Linux...it definitely works directly > from the printer/fax machine and also from my router, though. I'm not a fax expert, but IMO if you send document from the printer/fax itself, you will not be affected by the hplip removal. If you're interested, it would be great if you found out whether fax worked via hplip itself - ipp-usb is only recommended, you can remove it with ease for testing purposes. > > It would be nice to get this to work, because the only way to send fax > purely electronically right now for me is through the router and the router > only allows sending one scanned page at a time and does it in abysmal > quality, while Fedora (e.g. xsane) allows setting higher LPI and sending > multiple pages. Actually I don't know how fax is supposed to work in xsane... I was able to get into 'fax' tool, put postscript file there, but I don't know any receiver's number... > > No rush, though, as I don't expect needing this functionality right away. > So far I tried using efax directly since xsane didn't work (it successfully > put the files in queue but nothing more happened): 'efax -d > /dev/bus/usb/003/007 -t xxxxxxxxxxxx transfer/test2/testfax*' where the x'es > are the target fax number (it works) and the /dev/... address is where my > printer is according to lsusb. This is probably not correct, as I get a > 'can't open serial port /dev/bus/usb/003/007: Permission denied' error and I > haven't set up any IPP Fax out yet; the images to be faxed are recognized > correctly as being in the right format (G3), however. How do I set up this > IPP Fax out? According to [1] IPP Fax Out should have a resource part of uri 'ipp/faxout', so you should be able to create a permanent queue for USB device advertised by ipp-usb (with default settings): $ lpadmin -p <queue_name> -v ipp://localhost:60000/ipp/faxout -m driverless-fax:ipp://localhost:60000/ipp/faxout -E I'm only guessing here - I haven't used fax at all yet and I don't have a USB device capable of sending fax and supporting IPP-over-USB at the same time. I was only able to verify that normal printing via a permanent queue based on virtual printer created by ipp-usb worked, but based on how original 'driverless:' driver works (you can supply it a device uri and it generates a driver created from communication with the device specified by the provided uri) and based on the GSOC idea description [2] it should work. Then you can send a fax via classic 'lp' command: $ lp -d <queue_name> -o phone=<fax_phone_number> <file> Maybe the queue will be available in xsane as well and will work as before. [1] https://lpc.events/event/7/contributions/748/attachments/681/1244/LPC_20_IPP_FaxOut-A_New_Reality.pdf [2] https://openprinting.github.io/gsoc2020/11-ipp-fax-out/
Hi Zdenek, I tried your instructions but that actually produced an error on my printer/fax itself right after it started dialing the fax number (error code 0XB822687E), which never happened before. The fax queue was set up as a fax queue (visible as such in Settings, as well), but I had to restart the printer to make it work again; upon restart it wanted to print the pages I had told it to fax. Since I am short on time right now and definitely need the machine to work for the next two weeks I'd rather not conduct more experiments for now, but in about two weeks I might have more time. I don't want to block this issue so it can be closed AFAIAC; once I have more time I may open another issue. Thanks.
FEDORA-2022-352f2e3280 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-352f2e3280` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-352f2e3280 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-016b7d39db has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-016b7d39db` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-016b7d39db See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Christian, it would be great if you reported the issue with fax at https://github.com/OpenPrinting/cups-filters - driverless-fax backend is from the project, so they can have more info about how it should be used. I'm sorry I can't help much regarding driverless fax via USB, since I don't have a device with it :( . I've come up with instruction based on the links I'd shared, but I couldn't find further information about it - maybe the way how it works has changed.
Note for the update: The update removes the recommendation of ipp-usb - it is not able to remove ipp-usb itself, so users effected by the issue have to remove ipp-usb manually if you don't want to migrate to it yet. The new update will make sure ipp-usb won't be brought in with next CUPS update, if user removed ipp-usb in the past.
FEDORA-2022-016b7d39db has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-352f2e3280 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.