+++ This bug was initially created as a clone of Bug #580604 +++ --- Additional comment from tao on 2010-04-08 11:47:02 EDT --- Event posted on 2010-04-08 08:42 PDT by woodard Description of problem: Ink or toner levels are not reported until you first print a test page. The printer is quite capable of providing that information via snmp and possibly through other means. (I've done printers for years.) Then when it displays the levels, the levels are wrong How reproducible: Steps to Reproduce: Actual results: Expected results: Additional info: This event sent from IssueTracker by woodard [LLNL (desktop)] issue 738883 --- Additional comment from woodard on 2010-04-08 11:48:00 EDT --- Created an attachment (id=405338) photo of printer's console --- Additional comment from woodard on 2010-04-08 11:48:33 EDT --- Created an attachment (id=405339) from system-config-printer --- Additional comment from twaugh on 2010-04-08 12:42:10 EDT --- (In reply to comment #1) > Description of problem: > Ink or toner levels are not reported until you first print a test page. This is sort of by design with CUPS. The reporting of ink levels is in the backends, and the backends aren't run unless to process a job. In future we could do it as part of the PostScript autoconfiguration which CUPS now supports. I've filed that as bug #580634. > The printer is quite capable of providing that information via snmp and possibly > through other means. (I've done printers for years.) CUPS uses the SNMP Printer MIB to obtain supply levels. > Then when it displays the levels, the levels are wrong I'd like to see what the printer is actually reporting. Please run 'cupsctl -U root LogLevel=debug2' to turn on verbose logging, clear out the error log file with 'su -c "/sbin/service cups restartlog"', then send a print job. Afterwards you can turn off debug logging with 'cupsctl -U root --no-debug-logging'. Please attach the /var/log/cups/error_log file. --- Additional comment from woodard on 2010-04-08 15:21:45 EDT --- Created an attachment (id=405385) the requested error log two print jobs. --- Additional comment from woodard on 2010-04-08 15:26:51 EDT --- Also note on the mac the supply levels look pretty close to what is on the console. I don't know how they are getting their data. Back when I was working with printer mibs quite a lot, I found tons of errors in the implementations. --- Additional comment from jpopelka on 2010-04-09 04:02:02 EDT --- From the error_log: d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.1 = 97 d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.2 = 53 d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.3 = 48 d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.4 = 62 D [08/Apr/2010:14:11:30 -0500] [Job 3] ATTR: marker-levels=15,24,24,31 D [08/Apr/2010:14:13:46 -0500] [Job 4] ATTR: marker-names="black ink C4906A","yellow ink C4909A","magenta ink C4908A","cyan ink C4907A" --- Additional comment from twaugh on 2010-04-09 05:28:35 EDT --- I think I can see what's going on -- the printer is filling in a percentage when it should be filling in a level. Just to check, let's see what the prtMarkerSuppliesMaxCapacity values are: snmpwalk -Os -c public -v1 192.168.1.100 1.3.6.1.2.1.43.11.1.1.8 (you may need to install net-snmp-utils for that) --- Additional comment from twaugh on 2010-04-09 05:52:46 EDT --- Here's how I got that long SNMP number: by digging through cups/backend/backend-private.h: /* * OID constants... */ /* Host MIB */ #define CUPS_OID_mib2 1,3,6,1,2,1 [...] /* Printer MIB */ #define CUPS_OID_printmib CUPS_OID_mib2,43 [...] #define CUPS_OID_prtMarkerSupplies CUPS_OID_printmib,11 #define CUPS_OID_prtMarkerSuppliesTable CUPS_OID_prtMarkerSupplies,1 #define CUPS_OID_prtMarkerSuppliesEntry CUPS_OID_prtMarkerSuppliesTable,1 [...] #define CUPS_OID_prtMarkerSuppliesMaxCapacity CUPS_OID_prtMarkerSuppliesEntry,8 #define CUPS_OID_prtMarkerSuppliesLevel CUPS_OID_prtMarkerSuppliesEntry,9 They are expressed with commas "," instead of "." in the header file because they are used to initialise arrays, like: static const int prtMarkerSuppliesEntry[] = { CUPS_OID_prtMarkerSuppliesEntry, -1 }; /* Supplies OID */ --- Additional comment from tao on 2010-04-12 12:45:15 EDT --- Event posted on 2010-04-12 09:45 PDT by woodard [ben@snog Desktop]$ snmpwalk -Os -c public -v1 192.168.1.100 1.3.6.1.2.1.43.11.1.1.8 mib-2.43.11.1.1.8.1.1 = INTEGER: 607 mib-2.43.11.1.1.8.1.2 = INTEGER: 220 mib-2.43.11.1.1.8.1.3 = INTEGER: 200 mib-2.43.11.1.1.8.1.4 = INTEGER: 200 [ben@snog Desktop]$ This event sent from IssueTracker by woodard issue 738883 --- Additional comment from twaugh on 2010-04-12 12:54:09 EDT --- Yes, the printer is filling in the wrong value in the levels fields. d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.1 = 97 This is the black ink level. It is saying it is at 97 units with a capacity of 607, so about 15%. d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.2 = 53 Next, this is 53 units out of 220. d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.3 = 48 48 out of 200. d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.4 = 62 62 out of 200. D [08/Apr/2010:14:11:30 -0500] [Job 3] ATTR: marker-levels=15,24,24,31 So these percentages are correct. The printer is reporting incorrect numbers. --- Additional comment from woodard on 2010-04-12 15:48:06 EDT --- Current installed firmware version: Firmware Version DLM1FN0924AR matches the current firmware version on: http://h10025.www1.hp.com/ewfrf/wc/softwareList?os=228&lc=en&dlc=en&cc=us&swfsequence=1&product=3752459〈=en When I was working on printers all the time, this kind of thing was EXTREMELY common. You just need a quirk to work around it. Yeah, I know it is buggy but there is nothing else you can do. You stand on principle and you can report it to the vendor and maybe if you are lucky they might fix it. However, in my experience that almost never happens. The problem is that they spend all of their time and money on new product engineering and no time on current product engineering. Therefore, once it has been sold they rarely fix things.
Reported upstream with patch.
Upstream fix used in: cups-1.4.3-8.fc12 hplip-3.10.5-4.fc12
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping