Red Hat Bugzilla – Bug 124629
Duplexing does not work on HP Deskjet 6122 (PCL 3) connected via USB.
Last modified: 2007-11-30 17:10:43 EST
Description of problem: Selecting "Duplex test" from the "Printer
configuration" windows causes two separate sheets to come out with
writing only on one side, not a single sheet with writing on both sides.
Version-Release number of selected component (if applicable):
How reproducible: Always.
Steps to Reproduce:
1. Select System Tools > Print Manager.
2. Select Printer > Properties. Enter root password.
3. Select the printer, which is an HP Deskjet 6122 (PCL 3) connected
via the USB port.
4. Select Test > Duplex test.
Actual results: Two pages come out, one with a large number "1", and
the second with a large number "2".
Expected results: A single page should come out, with the numbers on
Created attachment 100650 [details]
Portion of /var/log/cups/error_log during the duplex test.
Although the last line says "Media tray empty!", there is plenty of paper in
the printer's only media tray, and it did print the job (but it used two sheets
instead of one).
Do you have duplex enabled in the driver options for that printer?
Created attachment 100670 [details]
Portion of /var/log/cups/error_log during the duplex test with duplex driver option on.
During the first test, "Double-Sided Printing" was set to "Printer Default."
As noted previously, two pages were printed, but no duplexing occurred.
I changed the "Double-Sided Printing" setting to "On (Flip on Long Edge)" and
applied the change. When I ran the duplex test for the second time, nothing
printed at all. I have attached the portion of the log from this second duplex
test. The "CUPS test page" would not print, either. I changed the
"Double-Sided Printing" option back to "Printer Default", and then "CUPS test
page" prints fine.
Could you please set LogLevel to debug2 (in /etc/cups/cupsd.conf) and
try again? By the way, the 'Media tray empty' message is a
red-herring, and is not causing this problem.
Created attachment 100887 [details]
Portion of /var/log/cups/error_log during the duplex test with duplex driver option on and LogLevel at debug2.
Sequence of events recorded in the attached log:
Booted Linux, set LogLevel to debug2, and rebooted.
17:54:09 Started "Printer configuration" tool.
17:55:19 Selected printer.
18:13:08 Set "Double-Sided Printing" to On (Flip on Long Edge).
18:15 Action > Apply
18:16 Test > Duplex Test (nothing printed).
I think the problem is that we don't have autodetect information for
Please attach the relevant 'class: PRINTER' section from
Created attachment 101919 [details]
"class: PRINTER" section from /etc/sysconfig/hwconf.
Created attachment 102107 [details]
Please replace /usr/share/foomatic/db/source/printer/HP-DeskJet_6122.xml with
this attachment, then remove and re-add the print queue. Does this help?
Well, I tried it two ways, and here is what happened:
1. I changed the driver setting to duplex (flip on long edge),
applied the change, then tried the duplex test from the menu. Nothing
2. I changed the driver setting back to printer default, applied the
changed, then tried the duplex test from the menu again. I got two
separate pages of output, but each was printed single-sided.
You must remove and re-add the queue. Changing the existing queue is
not sufficient. Please remove and then re-add the queue, and let me
know what behaviour you get. The intention is that the correct
printer model is detected, rather than 'Generic PCL3.'
Thank you. I created it as a "DeskJet 6122," and it duplexes fine, as
long as the driver setting is set to duplexing mode (if the driver's
duplex setting is set to "off," it prints separate pages). I think
that may have been the problem all along, since I originally created
the queue for a generic PCL 3 printer. I apologize for my ignorance.
When you added the printer did you have to tell the computer what
model the printer was, or did it work it out for itself? The change
is intended to make the right thing happen without unnecessary user
Did that work?
No. I just deleted and recreated the queue again, and took note of
what happened. After selecting the USB device, it prompted me for the
printer type. The combo box showed "Generic ...", and that is where I
originally selected PCL 3. To select the HP DeskJet 6122 model, I had
to change the combo box to "HP", then scroll down through the long
list to find DeskJet 6122.
Created attachment 102113 [details]
Please replace /usr/share/printconf/util/printconf_conf.py with this
Run system-config-printer from the command line and, when you go to add the
queue, there should be a message about the USB identification strings in the
terminal. What does that say?
I recreated the queue from the command line, and here is all the output:
[root@bunch util]# system-config-printer
/usr/bin/ptal-devid: Unable to open device "device"!
Syntax: /usr/bin/ptal-devid [<devname>] [-previous] [[<modifiers>]
<queries>]...Where <devname> may be one of:
Supported <modifiers> (for following <queries>):
-previous -- Gets previous string (must be first option)
-short -- Displays field values only
-long -- Displays leading field name through semicolon
-field <key> -- Queries specific field
-mfg -- Queries manufacturer fields
-mdl -- Queries model fields
-cmd -- Queries command set fields
-sern -- Queries serial number fields
Created attachment 102134 [details]
Please save this attachment as 'getusbprinterid.pl', and run (as root):
chmod a+x getusbprinterid.pl
What output does it give?
Created attachment 102148 [details]
Output from ./getusbprinterid.pl /dev/usb/lp0
Good, they're the strings I expected, and the ones that are in your
HP-DeskJet_6122.xml file. But system-config-printer put you at
'Generic' when choosing the model? How odd.
I just tested system-config-printer again, and what you just wrote is
Created attachment 102201 [details]
Please try replacing /usr/share/printconf/util/printconf_conf.py with this
attachment, removing /usr/share/printconf/util/printconf_conf.pyc and
/usr/share/printconf/util/printconf_conf.pyo if they exist, and trying again.
Does that give a message like 'Trying to match USB ...'?
I replaced printconf_conf.py with the attachment, then deleted
printconf_conf.pyo (printconf_conf.pyc did not exist, and still does
not). I then deleted and recreated the queue, but nothing appears to
have changed. It still does not recognize the printer, forcing me to
select it from the list. I saw no message like "Trying to match USB
...", and I also searched the error log for "trying"
(case-insensitive), but found nothing.
It won't be in the error_log but the terminal you ran
I recreated the queue again, this time using the
"system-config-printer" command, but absolutely no messages appeared
in the terminal window.
Please try fetching this package:
Install it with 'rpm -Fvh system-config-printer*0.6.107*.rpm'
Does that give better results?
When I clicked on the link, I received the following error:
You don't have permission to access /tim/tmp/124629/ on this server.
Apache/1.3.26 Server at www.cyberelk.net Port 80
Oops, sorry! Please use this URL instead:
Yes, that gave better results. My printer was automatically detected,
so I did not have to select it from the list. Furthermore, I enabled
the driver's duplexing option and then successfully ran a duplex test.
Thank you for keeping Linux up to par with this new printer of mine!