Bug 470959

I assume it does not only happen with xscanimage
but alos with xsane and scanimage so that it is
a general device I/O issue.

In the past any "error during device I/O"
has always been a lower-level USB issue
where I cannot help at all so that I close
it as "wontfix" which actually means "cantfix".
(Or I could close it with "worksforme" because
for me it works - but I don't have your model.)

For debugging have a look at
http://en.opensuse.org/SDB:Configuring_Scanners_from_SUSE_LINUX_9.2
in particular
"USB Cable Connection and Additional USB Hubs"
and
"USB Hardware + USB Kernel Modules + hotplug"
and
"Trouble-Shooting (Debugging)"

Setting the SANE_DEBUG_HPAIO environment variable
will display the following messages to stderr.
SANE_DEBUG_HPAIO=2 (error messages)
SANE_DEBUG_HPAIO=6 (error messages + device info)
SANE_DEBUG_HPAIO=8 (error messages + device info + sane api calls)

Also use "dmesg" to check for lower level USB errors.


What might help:

Often it helps to connet the scanner directly with
a short USB cable to the computer.
Additionally it may help to use explicitely the slower USB 1
(and not USB 2 which might be too fast for your hardware)
via unloading/loading appropriate kernel module(s).

(In reply to comment #1)
> I assume it does not only happen with xscanimage
> but alos with xsane and scanimage so that it is
> a general device I/O issue.

Yes, true. It's for sure no xscanimage thing but probably an hplip one.

> In the past any "error during device I/O"
> has always been a lower-level USB issue
> where I cannot help at all so that I close
> it as "wontfix" which actually means "cantfix".
> (Or I could close it with "worksforme" because
> for me it works - but I don't have your model.)

I don't get any error messages about low level usb issues with dmesg
or in /var/log/messages. The communication with the device works as I can successfully print using the hp backend.
I guess it's something to report for hplip upstream?

> Setting the SANE_DEBUG_HPAIO environment variable
> will display the following messages to stderr.
> SANE_DEBUG_HPAIO=2 (error messages)
> SANE_DEBUG_HPAIO=6 (error messages + device info)
> SANE_DEBUG_HPAIO=8 (error messages + device info + sane api calls)

[sanei_debug] Setting debug level of hpaio to 8.
[hpaio] sane_hpaio_init(): scan/sane/hpaio.c 1581
[hpaio] sane_hpaio_get_devices(local=0): scan/sane/hpaio.c 1600
[hpaio] sane_hpaio_open(/usb/Officejet_6300_series?serial=CN69DCH2GW04M4): scan/sane/hpaio.c 1635
[hpaio] device ID string=<MFG:HP;MDL:Officejet 6300 series;CMD:MLC,PCL,PML,DW-PCL,DESKJET,DYN;1284.4DL:4d,4e,1;CLS:PRINTER;DES:Q8066B;SN:CN69DCH2GW04M4;S:038000C484001021002c1800018c2880049;J:                    ;Z:0102,0503fac9015cc9,0600;BT:000000000000,4F66666963656A6574203633303020736572696573,0000008F,60;>: scan/sane/hpaio.c 1684
[hpaio] Model = Officejet_6300_series: scan/sane/hpaio.c 1692
[hpaio] Scanner type=SCL: scan/sane/hpaio.c 1774
[hpaio] failed to open pml channel: scan/sane/hpaio.c 674
[hpaio] sane_hpaio_exit(): scan/sane/hpaio.c 1594
 
> Often it helps to connet the scanner directly with
> a short USB cable to the computer.
> Additionally it may help to use explicitely the slower USB 1
> (and not USB 2 which might be too fast for your hardware)
> via unloading/loading appropriate kernel module(s).

It's already connected using a short USB cable directly to the internal USB hub and the other "devices" (printer, cardreader) work correctly.

I'll report that for hplip but wanted to add that information here as well.

When the other "devices" (printer => mainly output, cardreader => mainly
input when reading and mainy output when writing) work correctly
it looks more like a possible bug in the scanner driver.

Feel free to reopen this bug when you think I should also
have a look but probably the very best is to report it
directly upstream because you could answer their questions
much better than I could because I cannot reproduce it.

Please go to
http://hplipopensource.com/hplip-web/support.html
and follow the instructions there
(in particular provide a "hp-check -t" output).

Many Thanks!

This is the upstream report:
https://answers.launchpad.net/hplip/+question/59235

Argl!
How confusing and misleading the system's messages are!

In comment #0 there is in /var/log/messages
--------------------------------------------------------------
deviceuri=hp:/usb/Officejet_6300_series?serial=CN69DCH2GW04M4
--------------------------------------------------------------
which is a hp:/... DeviceURI which I expected to see.

In the hp-check.log in
https://answers.launchpad.net/hplip/+question/59235
there is near the end
----------------------------------------------------------------
Checking output of 'scanimage -L'...
device `hpaio:/usb/Officejet_6300_series?serial=CN69DCH2GW04M4'
is a Hewlett-Packard Officejet_6300_series all-in-one
--------------------------------------------------------------
which also look perfectly correct but actually one
has to additionally carefully check in hp-check.log for
------------------------------------------------------------
INSTALLED CUPS PRINTER QUEUES ...
warning: No queues found.
------------------------------------------------------------
which indicates that there is actually no hp:/... DeviceURI
queue set up.

I learned a lot here and perhaps I can somehow use it
in yast2-printer and in yast2-scanner (e.g. add a test
in yast2-scanner to check for a hp:/... DeviceURI queue).

I'm still confused since there was a cups queue actually as I was able to print and it used the hp backend. My old printers.conf:

<Printer officejet>
Info
Location
DeviceURI hp:/usb/Officejet_6300_series?serial=CN69DCH2GW04M4
State Idle
StateTime 1233344938
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

So my printer was correctly configured within cups but the device was apparently not set up within hplip so that the scanner function didn't work.

Currently I have no idea what the root cause might have been.
Only some guesses:

"old printers.conf"?
You do re-start the cupsd each time after you
manually changed any of its config files?
Compare
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
------------------------------------------------------------------------
General information on the command-line tools:
...
Do not edit the configuration files in /etc/cups/ manually
if suitable command-line tools are available for this purpose.
Reason:
The configuration files are not reloaded for every print job.
Rather, cupsd keeps much of the information in the main memory
and writes information back to the configuration files whenever
needed.
...
Never copy configuration files from other systems to your system
unless you know exactly what you are doing.
------------------------------------------------------------------------

A guess regarding HPLIP:
Whenever you launch a desktop system (KDE or Gnome)
/etc/xdg/autostart/hplip-systray.desktop
starts /usr/bin/hp-systray which runs daemon-like
in the background and perhaps this tool had some
old/outdated data so that scanner access failed for you?
Run
  ps auxw | egrep 'hp|python'
to see hp-systray processes.
Since HPLIP 2.8.4 the system daemon hpssd has been replaced
with hp-systray that loads as a user startup item in the
system tray in each user's desktop environment.

Another guess regarding HPLIP:
When you run in a non-POSIX and non-UTF8 locale,
HPLIP fails to "see" its hp:/... CUPS queues.
To see this, have a non-POSIX and non-UTF8 locale e.g. via
  export LANG=en_GB.iso885915; export LC_ALL=en_GB.iso885915
and then run "hp-toolbox".
Perhaps the root cause was whatever locale issue?

No idea. After hp-setup which changed printers.conf slightly and set up my scanner correctly hp-check still fails to see the cups queues:

---------------------------------
| INSTALLED CUPS PRINTER QUEUES |
---------------------------------

warning: No queues found.

This happens as root:

Hygiea:~ # echo $LANG
de_DE.UTF-8
Hygiea:~ # echo $LC_ALL

Hygiea:~ #

Now I fully understand the final ultimate root cause of the issue:
"Something seems to be somehow a bit messed up sometimes!"
;-)