Bug 976813

Created attachment 674196 [details]
Yast Error when testing scan

Error mesg on 13.2 and leap 42.1

We (i.e. openSUSE) do not provide the scanner driver
"epkowa" that you use, cf.
https://bugzilla.suse.com/show_bug.cgi?id=975881#c1

But you change somethings in the kernel and/or some libraries. So you have made some bugs somewhere. This as nothing to do with the driver I use which ahs not changed for years !

(In reply to Johannes Meixner from comment #2)
> We (i.e. openSUSE) do not provide the scanner driver
> "epkowa" that you use, cf.
> https://bugzilla.suse.com/show_bug.cgi?id=975881#c1

You don't read the bug report.
The bug report has nothing to do with the scanner hardware nor the scanner driver.
The bug report is relative to a bug in 13.2

Yes - lower level stuff always changes.

It is one problem of proprietary third-party drivers
that they are not adapted to changes in lower level stuff
and then third-party software may suddenly fail.

I wonder how you come to the conclusion that it is
we (i.e. openSUSE) who made some bugs somewhere
because usually we do not make the software but
we primarily distribute free software as is.

What is the full output of
  lsusb
and
  lsusb -t
on your computer where the scanner is connected?

Stop thinking your own assumtions
are the only possible truth.

I read what you wrote.

(In reply to Johannes Meixner from comment #5)
> Yes - lower level stuff always changes.
> 
> .........
> 
> What is the full output of
>   lsusb
> and
>   lsusb -t
> on your computer where the scanner is connected?

See  attachment

Created attachment 674723 [details]
response lsusb command  and current config

In your attachment#674723 [details]
lsusb_rtesult.txt contains (excerpt):
-----------------------------------------------------------------------------
# lsusb
...
Bus 003 Device 009: ID 04b8:0130 Seiko Epson Corp. GT-X770 [Perfection V500]
...

# lsusb -t
...
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 2: Dev 9, If 0, Class=Vendor Specific Class, Driver=, 480M
...
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
...
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
-----------------------------------------------------------------------------

You scanner is connected at a USB bus/port where the
kernel module/driver "xhci_hcd" (a.k.a. "USB 3") is used.

There are currently isues when the xhci kernel module
is used for USB ports where the scanner is connected.

Only "lsusb -t" will tell you what kernel module/driver
is actually used for the USB bus and port where
your scanner is connected to.

Neither the color nor what the port/connector is
labeled on the computer is reliable regarding what
kernel driver is used for the port/connector.

For example my testing machine has 4 USB connectors,
two labeled with the "super speed" USB logo (a.k.a. USB 3)
and two labeled with the normal USB logo (a.k.a. USB 2)
but for all 4 ports xhci is used.

Furthermore all USB connectors on my testing machine have
same dark color. Also the "super speed" (USB 3) labeled
connectors are basically black. Their color is "very dark"
but not "100% black" and neither blue (USB 3.0) nor
teal blue (USB 3.1), cf.
https://en.wikipedia.org/wiki/USB#Colors

Only "lsusb -t" output shows what kernel driver is
actually used.

Regarding "USB 2" versus "USB 3" see
http://lists.alioth.debian.org/pipermail/sane-devel/2015-December/034197.html
and
http://lists.alioth.debian.org/pipermail/sane-devel/2015-December/034207.html

See also
https://bugzilla.opensuse.org/show_bug.cgi?id=955079#c2
and
https://bugzilla.opensuse.org/show_bug.cgi?id=856794
in particular
https://bugzilla.opensuse.org/show_bug.cgi?id=856794#c50

Finally see
http://bugzilla.opensuse.org/show_bug.cgi?id=975866
for possible workarounds by using an appropriate version
of the sane-backends software that may (hopefully) work
with your currently used "xhci_hcd" driver from your
currently installed kerenel.

Alternatively:

If possible connect scanners at a traditional "USB 2" port.

It seems your computer also has USB ports where it seems
traditional "USB 2" kernel modules/drivers are used
(from your "lsusb -t" output):
-------------------------------------------------------------------------
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
...
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
-------------------------------------------------------------------------

I would expect "Driver=ehci_hci" not "Driver=ehci-pci"
but I am not at all a kernel expert to know details.

If those USB ports have connectors at the outside of
your computer so that you could connect the scanner
at such a USB 2 port, then the scanner should probably
"just work".

*** This bug has been marked as a duplicate of bug 856794 ***

*** Bug 975881 has been marked as a duplicate of this bug. ***

FYI:

I asked on the SANE upstream sane-devel@lists.alioth.debian.org list
whether or not changing the installed sane-backends RPM package
could make a difference whether or not the third-party "epkowa" driver
works with the xhci_hcd kernel module.

See
http://lists.alioth.debian.org/pipermail/sane-devel/2016-April/034524.html
excerpt:
---------------------------------------------------------------------------
Johannes Meixner writes:

> [...]
> Now I wonder if the "epkowa" backend could be also affected by the
> current sane-backends 1.0.25 "Workaround for USB3 problems in Linux
> kernel" that seems to no longer work with newest kernels, cf.
> http://lists.alioth.debian.org/pipermail/sane-devel/2016-January/034254.html
>
> In other words, I wonder if the "epkowa" backend uses the
> sane-backends USB code or if the "epkowa" backend implements USB
> communication on its own.

The epkowa backend uses its own *copy* of the sanei_usb code.  There was
a minor fix for USB 3.0 connected scanners in 2.30.1 (dated 2014-12-03).
That same fix was applied to sane-backends on 2014-12-10.

Please note that iscan does *not* actively track changes to the
sane-backends version of the sanei_usb code.  Also, iscan-2.30.1 is the
most recent version.

> In the end I like to understand if a version change of the installed
> sane-backends software on the user's computer could make a difference
> whether or not the "epkowa" backend works with the xhci_hcd kernel
> module.

That is rather unlikely but not impossible as it may depend on what
other backends do during their sane_init() and sane_get_devices().  If
all other backends are disabled, changing the version of the installed
sane-backends should not make a difference.  That is because the dll
backend doesn't do anything USB related itself.

Hope this helps,

Olaf Meeuwissen, LPIC-2       FLOSS Engineer -- EPSON AVASYS CORPORATION
---------------------------------------------------------------------------

This means that in contrast to
https://bugzilla.opensuse.org/show_bug.cgi?id=975866#c2
where an upgrade to sane-backends version 1.0.25 made
the sane-backends driver "plustek" work with xhci_hcd
it is rather unlikely that another sane-backends version
makes the third-party "epkowa" driver work with xhci_hcd.

The only way - as far as I understand it - how a different
sane-backends version could even make the "epkowa" driver
work with xhci_hcd is when sane-backends drivers are also
enabled in /etc/sane.d/dll.conf - for example either the
sane-backends driver epson or alternatively epson2.

But this is basically only blind guess.

In the end when there are issues with third-party drivers
nobody - except the authors of the third-party software - can provide
real help and support because nobody - except the authors - know how
their software really works.

In this case you can only contact those wherefrom you got the
third-party software for any kind of real help and support.

See "Third-Party Scanner Drivers" in
https://en.opensuse.org/SDB:Configuring_Scanners

Thank you very much for your deep search.

As english is not really my mother language, I have some a question before I dig into your answers and all the links.

If I have understood, it is possible that my problem come from the proprietary driver which don't like that I am using usb 3 connector for connecting my scanner.

In that way I have found a more recent laptop with only usb 3.0 connectors and the scanner is not seen at all (from yast point of view : The driver does not find any scanner).

But my initial attempt was on a laptop with only usb2 connector ( on OS 13.2 )
What drives me crazy about that is it is running on 13.1 on that old laptop. But that seems to be an old story.

Thank you again.

The root cause are differences in the USB "behaviour" in the kernel
when the kernel driver xhci_hcd is used for the USB bus that
belongs to the USB connector where the scanner is connected.

Depending on the hardware
(e.g. older computer with pure traditional USB2 hardware
 versus newer computer with current USB3 capable hardware)
different kernel drivers are used for USB.

In openSUSE 13.1 the kernel version is 3.11.

In openSUSE 13.2 the kernel version is 3.16.

In openSUSE Leap 42.1 the kernel version is 4.1.

Depending on the kernel version the kernel driver xhci_hcd
(that is used for USB3 capable hardware) behaves different
so that scanner drivers work or may fail depending on the
kernel version on USB3 capable hardware.

Regarding kernel modules/drivers for the plain USB
versus scanner driver for a particular USB scanner model
see "Basics" at
https://en.opensuse.org/SDB:Configuring_Scanners
(excerpt):
---------------------------------------------------------------------------
Regardless of the details, in general a stack consisting of various
layers must be functional in its entirety in order to enable users
to access a USB scanner from an application:

User
  |
Application (scanner user frontend)
  |
SANE backend (scanner driver)
  |
libusb (generic USB device access functions)
  |
USB kernel modules (plus udev triggered by USB scanner plug-in)
  |
USB hardware in the machine
  |
USB cable connection (additional USB hubs if necessary)
  |
Scanner

Only the parts "SANE backend (scanner driver)" and
"Application (scanner user frontend)" are what could
be called "the actual scanning software".

The operability of all lower layers is a precondition
for the operability of a higher layer.
---------------------------------------------------------------------------

For example for traditional USB2 hardware the kernel drivers
uhci_hcd or ehci_hcd are used and with those kernel drivers
all usual scanner drivers work.

In contrast for USB3 capable hardware the kernel driver xhci_hcd
is used and with that kernel driver the usual scanner drivers
sometimes work and sometimes fail, cf.
https://bugzilla.opensuse.org/show_bug.cgi?id=856794#c40
(excerpt):
---------------------------------------------------------------------------
There are computers where USB3 always "just works".

There are computers where USB3 fails under certain conditions.

Perhaps there are computers where USB3 always fails.
---------------------------------------------------------------------------

In your case it seems the "epkowa" scanner driver
fails when the xhci_hcd kernel driver is used.

It is crucial to understand that it does not matter
how a USB connector is labeled or colored at the computer
or what USB speed is listed for a USB connector at the computer.

All what matters is what kernel driver is used for the USB bus
that belongs to the USB connector where the scanner is connected.

To find out what kernel driver is used only the output of
# lsusb
together with the output of
# lsusb -t
provides the right information.

Created attachment 675204 [details]
redoing test on 3 different computers, More rigorously.

I have made the same tests on three different computer :

1°) A test on a test server running 13.2 ( no-name box  asus z97 motherboard )
I tested the scanner on one usb 2.0 motherboard connector, one usb 3.0 motherboard connector, one all_in_one 2"5 front interface on usb 3.0 connector. All tests succeed and the used driver is xhci_hcd.

2°) A test on a laptop running 13.2 ( ASUS G75VW )
I tested the scanner on all usb 3.0 connector. All test failed
The driver in use is ehci-pci.
The NVIDIA sound controller is recognize also as a scanner on the same bus.

3°) A test on a test laptop running 13.1 and 13.2  ( HP Pavillion DV9500 series )
I tested the scanner on one usb 2.0 connector. There is no usb 3.0 connectors.
All tests succeed and the used driver is ehci-pci.

I remark that on my laptop ( asus ) and on the hp laptop, this is the same driver which is in use.
The only difference I can see is that the sound controler ( NVIDIA GF114 HDMI Controller ) is on the same bus as the scanner, and respond to scanner discover command.

Two different driver ( xhci_hcd, ehci-pci ) are convenient for the scanner.
It seems that the ehci-pci is used because of the NVIDIA sound controller.

My thought is because the NVIDIA sound controller is on the same bus as the scanner and because it is detected as a scanner, this make the the scanner faulty.

Is it possible using specific rules on udev to tell the system to load the xhci_hcd driver in place of the ehci-pci driver for the scanner device.

Your new attachment#675204 [details]
seems to contradict your previous attachment#674723 [details]
where it had failed on a computer where xhci_hcd was used.

Now according to your new attachment#675204 [details]
it works on one computer with xhci_hcd
( cf. https://bugzilla.opensuse.org/show_bug.cgi?id=856794#c40 )
but now it fails on another computer with ehci-pci
so that now it seems this one is not a duplicate of bug 856794.

In your new attachment#675204 [details]
scanner_test_my_asus_13-2.txt contains (excerpts):
-----------------------------------------------------------------------------
# lsusb
...
Bus 002 Device 004: ID 0955:7002 NVidia Corp.
Bus 002 Device 007: ID 04b8:0130 Seiko Epson Corp. GT-X770 [Perfection V500]
...

# lsusb -t
...
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
        |__ Port 1: Dev 7, If 0, Class=Vendor Specific Class, Driver=, 480M
        |__ Port 5: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 480M
...

# sane-find-scanner
found USB scanner (vendor=0x0955 [Copyright (c) 2009 NVIDIA Corporation],
 product=0x7002 [NVIDIA stereo controller]) at libusb:002:004
found USB scanner (vendor=0x04b8 [EPSON], product=0x0130 [EPSON Scanner])
 at libusb:002:007
-----------------------------------------------------------------------------

That sane-find-scanner sometimes also reports non-scanners is normal.
Basically sane-find-scanner may report any "Vendor Specific Class"
USB device because scanners are "Vendor Specific Class" USB devices,
see "man sane-find-scanner" (excerpt):
  ...
  sane-find-scanner tries to scan for USB devices found
  by the USB library libusb (if available). There is no special
  USB class for scanners, so the heuristics used to distinguish
  scanners from other USB devices is not perfect.

I.e. that sane-find-scanner reports the NVIDIA USB device
is not a problem.

But that sane-find-scanner reports the NVIDIA USB device might
indicate that "scanimage" (which runs the actual scanner driver)
also gets confused (more precisely that also the actual scanner
driver "epkowa" gets somehow confused).

Regarding more detailed debugging see the section
"Trouble-Shooting (Debugging)" at
https://en.opensuse.org/SDB:Configuring_Scanners

I think it is possible to force the "epkowa" driver to recognise
and use a particular USB device - see "man sane-epkowa" - via
the "epkowa" driver config file /etc/sane.d/epkowa.conf
by replacing therein the general entry

  usb

with a device specific entry like

  usb 04b8 0130

so that (hopefully) the "epkowa" driver will no longer
try to use other USB devices like the NVIDIA USB device.

I found that information by some "googling" that led me to
http://man.cx/sane-epkowa%285%29
and
https://bbs.archlinux.org/viewtopic.php?id=182346

Again note that we (i.e. openSUSE) cannot support third-party drivers,
cf. comment#2.

In general in case of issues with third-party software
you must first and foremost ask those wherefrom you got
the third-party software for help and support.

Regarding comment#16 about using differnt USB kernel drivers:

I am neither a USB expert nor a kernel expert but according to
https://bugzilla.opensuse.org/show_bug.cgi?id=920067#c23
it seems in general it is not possible to use other USB
kernel drivers than those that are automatically used.

As far as I know nowadays USB3 capable hardware in the computer
is different compared to traditional USB2 hardware in the computer
so that for USB3 only xhci_hcd works but xhci_hcd does not work
for traditional USB2.

Note that I am talking about the USB3 chips versus USB2 chips
in the computer i.e. the hardware where the USB kernel drivers
are used for.

One can nevertheless connect a USB2 device to a USB3 connector.
Then the USB3 chips in the computer (with the xhci_hcd kernel driver)
are used for a USB2 device that is connected to a USB3 port,
cf. the section about "USB Speed" in
https://en.opensuse.org/SDB:Configuring_Scanners

I am installing a VM with OS 13.1 on my laptop ( on which I can't scan ) and see if it works.

I will give news as soon as possible.

Hello.
Here are the results to compare to the file (failed test) "scanner_test_my_asus_13-2.txt"
Same hardware
Successful tests done using virtualbox 5.0 and installing OS 13.1.
The Driver in  use is : ehci-pci

linux-vf6e:~ # 
linux-vf6e:~ # lsusb | sort
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 04b8:0130 Seiko Epson Corp. GT-X770 [Perfection V500]
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet
linux-vf6e:~ # lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/12p, 12M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/12p, 480M
    |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 480M
linux-vf6e:~ # grep -v '^#' /etc/sane.d/dll.conf
epkowa
linux-vf6e:~ # scanimage -L
device `epkowa:interpreter:001:005' is a Epson Perfection V500 flatbed scanner
linux-vf6e:~ # sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

found USB scanner (vendor=0x04b8 [EPSON], product=0x0130 [EPSON Scanner]) at libusb:001:005
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.
linux-vf6e:~ # scanimage -v -d epkowa:interpreter:001:005 -x 105 -y 148 --resolution 1200 > ./image.pnm
scanimage: rounded value of resolution from 1200 to 800
scanimage: scanning image of size 3304x4661 pixels at 24 bits/pixel
scanimage: acquiring RGB frame
scanimage: min/max graylevel value = 106/255
scanimage: read 46199832 bytes in total
linux-vf6e:~ #

This version of openSUSE changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or consider the bug still valid, please feel free to reopen this
bug against that version, or open a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime