Talk:HPLIP

Incompatibility with the LaserJet 1320 (and possibly others)
I just put Gentoo back on one of my boxes today after spending a while with Kubuntu, and ran into major difficulty getting my LaserJet 1320 working with it again. hp-setup's test page comes through, but nothing else works after that...keep running into printer communication errors (code 5012, IIRC). There's lots of discussion in the Gentoo forums and elsewhere, but no fixes. I tried downloading a PPD from HP's website, but they don't seem to have a clue what those are anymore.

I eventually stumbled across a clue that suggested using Foomatic to generate a PPD, and then configure CUPS with that. Kernel USB printing support needs to be enabled, but once you have that in place, printing once again works great. Slightly more complete documentation is on my blog:

https://alfter.us/wp/2015/03/23/gentoo-linux-hplip-and-the-hp-laserjet-1320-dont-mix/

--Salfter (talk) 03:56, 24 March 2015 (UTC)

Verbosity
can we tone down the verbosity of this page, and turn up the functionality? we should note qt4 use flag is required for the hplip GUI. lpadmin group?

or for noobs that think they're super elite

666threesixes666 (talk) 21:07, 21 May 2014 (UTC)


 * I think it has always been simply assumed qt4 (or gtk) use flags have always been required for GUI interfaces. However, most of us command line junkies know this and instinctively avoid enabling the QT/GTK USE flags when needed.  So I don't know if this QT/GTK USE flag is a problem -- I could be wrong though?  (For example, us command line junkies will commonly use app-portage/euses tools; "# euses qt4" responds with "net-print/hplip:qt4 - Enable graphical interface using Qt 4")  If I'm not mistaken; I think HP's perspective of support for HPLIP, HP support prefers or requires users to require building HPLIP with the QT4 (or QT/GTK) GUI for end user support to be even considered.  (Mine and likely other minimalists' perception is, HPLIP GUI tools shouldn't be required for merrily operating a printer under Linux.)  Since I've migrated to a box with a  i7-3770K CPU @ 3.50GHz x4 with x4 Threads, 32GB RAM, NVIDIA GTX 670; I don't have much problem anymore restricting all of my builds from using QT4, albeit I never use the QT front-ends!  On my older Intel Pentium 3, the older boxes still run slow when using most Python or when building something using QT.  Probably similar results with any mobile or minimal platforms.  --Roger (talk) 23:08, 21 May 2014 (UTC)


 * Nowadays, I only print one or two documents every two months or so. I also now remember when the printer is off and CUPS sends a job and fails, CUPS will automatically suspend the printer for that specific printer requiring the user to resume printing for that specific printer before being able to print again.  (ie. CUPS Front End: Maintenance > Resume)  --Roger (talk) 23:08, 21 May 2014 (UTC)


 * As far as Sane scanner plug-in, I've had no problems for awhile here. But then again, I haven't manually upgraded the plug-in for awhile.  Once the binary library becomes incompatible with the newer HPLIP versions, breakage can easily occur at any time!  So I (or we) have to continually be weary of this occurring at anytime and need to be on our toes. :-/ --Roger (talk) 23:08, 21 May 2014 (UTC)

HPLIP Binary Upgrade
PROBLEM: The HPLIP ebuild itself does not upgrade the binary plugin(s) when the ebuild is upgraded. A symptom of this problem, you may get segfaults when starting XSane. (i.e. The HP LaserJet M1522nf requires a binary plugin for using the scanning feature.)

My Edit: -- SOLUTION: The following upgrade instructions should upgrade the Sane plugin file "/usr/lib64/sane/libsane-hpaio.so*". (hp-setup also upgrades the plugin?) --

Billie's Change: ++ SOLUTION: Following the upgrade instructions should take care of this as hp-setup tries to upgrade the plugin.

Within English Grammar, your statement lacks sense unless you are implying the upgrading of the binary (scanner/xsane) plugin is now upgraded while installing the package. (ie. Scripted now within the EBuild file?) If so, you should also say so for clarification. Albeit, I wasn't aware of this move, as I am already CC'ed on a few HPLIP bugs. Additionally, one of the reasons for specifying the "/usr/lib64/sane/libsane-hpaio.so*", is so that users know where the binary plugin file for xsane is installed for HPLIP and can manually check that their binary plugin for xsane has been updated, instead of depending explicitly upon the hplip utilities. (Funny though, I diff'ed the =net-print/hplip-3.13.9 and =net-print/hplip-3.14.1, and found those files to be different while still having the same 1.0 version, even noted within the library itself when searching using strings/hexedit!)


 * This is some good information not normally known by users of HPLIP, or those trying to troubleshoot HPLIP. I would suggest at least a brief mention as you & I have made above about the binary driver location, so when hp-set is suspected as to failing to upgrade the binary components, users can easily locate these specific binary files to ensure an upgrade took place.  In other words, when hp-setup is issued, the debug output is seemingly sparse at times.  Albeit, I don't know much about the binary scanner plugin either, and only tracked this upgrade problem down after a year or so.

I already recognize I may not even have had this bug properly corrected and documented initially, as downgrading to =net-print/hplip-3.13.9, and merrily running xsane afterwards still results in a device not found, without manually deleting and adding the fax/scanning device again. And as such, the binary plugin maynot be upgraded upon the next upgrade. If I'm not mistaken, HP developers' official stance on this (per their bug pages and support) is to manually delete all print/fax quenes and manually recreate the print/fax quenes after each upgrade or downgrade. Sort of defeats the purpose of so-called "upgrades", reverting back to MS Windows' early style of difficult package management! (Hence, the reason I stated "hp-upgrade -i 192.168.1.27" for upgrading the binary plugin... but now doesn't appear to be working... sigh!)


 * Having to recreate the printer/fax quenes requires also re-editing the PPD files to force my specific model to use "LanguageLevel 2", as it always defaults to Level 3, a known problem with my M1522nf printer to print a mess of random chars. (Not a fun issue when you need to get something out within an hour, and run a day late.  This bug, HP seems to have refused to fix, and many distros ie. Ubuntu hack the quenes to ignore the PPD specified value and use their own.  As such, users of these distros are usually completely unaware of this bug.)  Linux package upgrade process is known for it's streamlined package upgrade process, and recreating the quenes should be unnecessary.  However, you've made some good additional points and I will relax a little, as we know things aren't always perfect.  Main issue, I don't want this bug or known issue deleted, as I use this Gentoo Wiki when I have reoccurring problems with this M1522nf printer/scanner.  Others likely do so too.

I've just looked over the =net-print/hplip-3.14.1 ebuild file, and see nothing within it upgrading the binary plugin for the scanner/xsane file. And per HP developers' previous statements, the binary plugin require manual upgrading, requiring the deletion and recreation of the print/fax/scanner queues.


 * Yup. That's what I've always assumed from monitored bugs.  Good write-up here.

SOLUTION: Following the upgrade instructions should take care of this as hp-setup tries to upgrade the plugin. If there are still problems hplip comes with hp-plugin which can be used fro installing the plugin. As a last resort one can download the plugin from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ and install it manually.

So others can have an easier time, might be just best to state for a SOLUTION, "After upgrading HPLIP to a newer version; users must run hp-setup, delete, and recreate the printer/fax quenes. Without recreating these quenes, the upgrading of the binary xsane scanner plugin maybe skipped and not upgraded." I think this is more to the point of what we've previously discussed and concluded. Think having users go to openprinting.org for a manual install of hplip might significantly discourage users, as distributions should have their packagers handle this process automatically. But for all I know, you may have heard of some users having success, with such things as a binary printer driver, as I only have the binary xsane scanner driver to worry about and I don't think I've ever attempted a manual install outside of Gentoo's EBuild. Now I do recall, using hp-setup to download the binary component, and manually executing the downloaded binary component and having it upgrade/install itself. But again, in my opinion, this manual install process usually creates unowned files within the root filesystem and not easily later uninstalled or lost.

Disabling Infinality?
++

I'm stumped. Can somebody elaborate on this? I wasn't aware there was a Infinality switch. A little research shows there is an Infinality package, and disabling it sometimes provides better results. ---Roger (talk) 01:54, 1 February 2014 (UTC)