Bug 114763

Summary:	Epson inkjet status doesn´t work
Product:	[Unmaintained] kdeprint	Reporter:	Michael Stather <kontakt>
Component:	general	Assignee:	KDEPrint Devel Mailinglist <kde-print-devel>
Status:	CLOSED NOT A BUG
Severity:	normal	CC:	jlayt
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

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.