Red Hat Bugzilla – Bug 236720
Avoid using the hal backend whenever possible
Last modified: 2007-11-30 17:12:02 EST
Description of problem:
Epson Printer Tools used to work for FC3, FC4 and FC5, but is broken in latest,
fully updated FC6. Error message: unsupported connection type: hal.
The URL points to a discussion of a work-around - see the comment by a guy
called Peter Gordon.
Not sure I have chosen the correct component (above).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Enter Control Center
2. Choose Peripherals->Printers
3. Select Epson C46 printer queue.
4. Right-mouse and choose Epson Printer Tools menu.
5. Choose check ink level or whatever
6. Should then display ink levels for printer cartridges
Error message: unsupported connection type: hal
Should then display ink levels for printer cartridges.
Yes, there are a variety of reasons that using the HAL backend is undesirable.
What would be a good, future-proof, work-around?
Or does the HAL backend just need fixing?
For the ink-level issue, it needs to be done using a central mechanism in CUPS,
something like the COMMAND interface. In fact, gutenprint-cups provides a
COMMAND file for fetching ink levels, but I haven't managed to get it working yet.
For the HAL backend problems, there are several things to fix, not limited to:
1. hal-cups-utils should just avoid using the HAL backend if it can work out
which other backend should be used. It already does this for the hp backend,
but needs to also do it for USB devices.
2. I don't think we will get away with avoiding HAL for all devices, so we need
to fix it up for those devices that will need to use it. This involves making
sure that we actually retry if we don't see the device there, and managing
printer-state-reasons properly etc.
Would it be possible to use the escputil prog in gimp-print-utils, or has that
That's what the gutenprint-cups COMMAND driver is based on as far as I can see
from the code. But status readback doesn't seem to work from within the CUPS
USB backend, and that's the problem.
It's no good having loads of separate tools for this; it needs to be integrated
into a central mechanism.
Would creating a new queue that refers simply to the actual device node
(probably /dev/usb/lp0) be a likely work-around?
My user is happily using FC6 with everything up to date and working except this.
Overall, FC6 has been quite impressive :) It would be good press to be able to
provide him with an easy work-around.
Yes and no -- the USB backend forbids URIs that name a device node, and although
a file: URI will work you'll need to enable file: URIs first ('FileDevice yes').
Here's a work-around for those who are awaiting a fix for this:
Add this to your /etc/rc.local file or to a cron job file:
chmod o+rw /dev/usb/lp*
The above will allow normal users to do the commands below.
Use the following commands to do things to your Epson printer.
escputil -r /dev/usb/lp0 -i
will interrogate ink levels
escputil -r /dev/usb/lp0 -c
will clean your print head.
Note that this assumes your printer device is /dev/usb/lp0.
For KDE users, setting up an icon with this command in it is neat:
kdialog --title "Epson Ink Levels" --msgbox "$(escputil -r /dev/usb/lp0 -i)"
A bit bodgy, but better than being stuck :)
Incidentally the GUI would not allow me to do what it says in Comment #7 above.
Current hal-cups-utils package from updates-testing (0.6.8-1.fc6) now uses the
usb: backend when it can.
Fix in update: hal-cups-utils-0.6.9-1.fc6