Bug 114763 - Epson inkjet status doesn´t work
Summary: Epson inkjet status doesn´t work
Status: CLOSED NOT A BUG
Alias: None
Product: kdeprint
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KDEPrint Devel Mailinglist
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-20 15:38 UTC by Michael Stather
Modified: 2008-12-31 19:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Stather 2005-10-20 15:38:37 UTC
Version:           Unbekannt (using KDE 3.4.91 (beta1, >= 20050910) Level "a" , SUSE 10.0.42)
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.13.2-2-default

I´ve an Epson C86 connected over USB.
When I run the "epson inkjet" tools in the "printer" pop-down menu of the printer menu in kdeprint, and select an operation e.g. "show ink level" I get an error:

Cannot open /Stylus C86 read/write: No such file or directory
Comment 1 Toby Dickenson 2006-08-13 17:36:40 UTC
Confirmed here in kubuntu. This appears to happen if the cups DeviceURI is usb://EPSON/xxxxx.

This feature does work if the the DeviceURI is manually changed to a /dev/ path.
Comment 2 Kurt Pfeifle 2007-01-09 02:16:54 UTC
This is not a KDEPrint bug. It is in the external "escputil" utility (to which KDEPrint only provides a GUI frontend).

Maybe escputil does not support the non-"/dev/usb/lpX" paths supported by more recent versions of CUPS.
Comment 3 Ian Hollander 2008-01-20 09:12:12 UTC
I really enjoy using and seeing the way kdeprint has progressed over the years. It has made printer setup and administration infinity easier. 

I do have disagree with passing "higher level" path information to helper apps. It seem like a lot of extra work/overhead for a special purpose applications to need to parse HAL device properties (AFAIK) just to get back to a device's raw file path. If this "higher level" path is from HAL, it is missing a udi. This would cause the look-up for a unique "raw" path to fail when there were two or more identical printers plugged into the same machine/cups server which is common in a business environ.

My point is that it be more unix-like behavior for helper apps like escputil to be able to focus on getting consistent info from various hardware instead of worrying about figuring out the device's path first.

-Ian

Comment 4 John Layt 2008-12-31 19:09:56 UTC
Closing old Resolved status bug.