Bug 335674

oneukum@oenone:~> scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).
oneukum@oenone:~> cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: ATA      Model: IBM-DTTA-351010  Rev: T56O
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: HL-DT-ST Model: DVD-RAM GSA-H50L Rev: 1.00
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: SAMSUNG HD403LJ  Rev: CT10
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD740ADFD-00 Rev: 21.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 01 Lun: 00
  Vendor: PIONEER  Model: DVD-ROM DVD-303  Rev: 1.09
  Type:   CD-ROM                           ANSI  SCSI revision: 02
Host: scsi5 Channel: 00 Id: 00 Lun: 00
  Vendor:          Model: Scanner 636A4    Rev: 1.50
  Type:   Scanner                          ANSI  SCSI revision: 02
oneukum@oenone:~> ll /dev/sg5
crw-r----- 1 root disk 21, 5 22. Okt 15:11 /dev/sg5

Created attachment 179711 [details]
yast2 log

oenone:/home/oliver # hwinfo --scanner
22: SCSI 600.0: 10c04 Scanner
  [Created at scsi.1561]
  Unique ID: 9IX0.tzaGPR0_7p8
  SysFS ID: /class/scsi_generic/sg5
  SysFS BusID: 6:0:0:0
  Hardware Class: scanner
  Model: "Scanner 636A4"
  Device: "Scanner 636A4"
  Revision: "1.50"
  Device File: /dev/sg5
  Device Number: char 21:5
  Config Status: cfg=new, avail=yes, need=no, active=unknown

34: USB 00.0: 10c00 Scanner
  [Created at usb.122]
  UDI: /org/freedesktop/Hal/devices/usb_device_5da_99_noserial_if0
  Unique ID: DHyf.RrixO09E+o1
  Parent ID: 2UT6.4uPzupm_EOA
  SysFS ID: /devices/pci0000:00/0000:00:02.2/usb1/1-3/1-3.4/1-3.4:1.0
  SysFS BusID: 1-3.4:1.0
  Hardware Class: scanner
  Model: "Microtek ScanMaker X6"
  Hotplug: USB
  Vendor: usb 0x05da "Microtek"
  Device: usb 0x0099 "ScanMaker X6"
  Driver: "microtekX6"
  Driver Modules: "microtek"
  Speed: 12 Mbps
  Module Alias: "usb:v05DAp0099d0000dcFFdsc03dp00ic00isc00ip00"
  Driver Info #0:
    Driver Status: microtek is active
    Driver Activation Cmd: "modprobe microtek"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #31 (Hub)

Oliver,
can you activate the "set -x" line in
/usr/lib/YaST2/bin/test_and_set_scanner_access_permissions
and then attach its stdout and stderr output as text/plain
attachments to this bug.

What I see from your YaST log:

It is detected as
"SCSI scanner ' Scanner 636A4 1.50' at /dev/sg5"

You selected the model "Microtek", "ScanMaker X6" with the driver "microtek2".

The "microtek2" line was activated in /etc/sane.d/dll.conf

The driver recognized the scanner and it is shown in YaST like
microtek2 | Microtek ScanMaker X6USB at microtek2:/dev/sg5

Finally this command is executed by YaST:

/usr/lib/YaST2/bin/test_and_set_scanner_access_permissions \
 'microtek2:/dev/sg5;unknown;'

which should "do the right thing" - which is nothing in your case
because according to comment #1 and comment #3 you scanner
shows up as SCSI type "scanner" so that the default entry
for SCSI scanners in /etc/hal/fdi/policy/10osvendor/70-scanner.fdi
--------------------------------------------------------------------
 <match key="info.category" string="scsi_generic">
  <match key="@info.parent:scsi.type" string="scanner">
   <append key="info.capabilities" type="strlist">scanner</append>
  </match>
 </match>
--------------------------------------------------------------------
should trigger the udev/HAL/hal-resmgr machinery which should
set an appropriate ACL on the scanner's device file.

Please check that you have such an entry.

If yes, the question is why the udev/HAL/hal-resmgr machinery
is not doing what it should do...

Please attach also a full "lshal" output.

Try if it helps to restart HAL with the scanner switched on.

If not, try if it helps to reboot with the scanner switched on.

/etc/hal/fdi/policy/10osvendor/70-scanner.fdi:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>

    <match key="info.category" string="scsi_generic">
      <match key="@info.parent:scsi.type" string="scanner">
        <append key="info.capabilities" type="strlist">scanner</append>
      </match>
    </match>

    <match key="info.bus" string="usb_device">
      <match key="usb_device.vendor_id" int="0x03f0">
        <match key="usb_device.product_id" int="0x0101">
          <append key="info.capabilities" type="strlist">scanner</append>
        </match>
      </match>
    </match>

Created attachment 180993 [details]
lshal

Created attachment 180999 [details]
/usr/lib/YaST2/bin/test_and_set_scanner_access_permissions > /tmp/stdout 2> /tmp/stderr

stdout is empty

Rebooting makes no difference.

I found out that the scanner no longer reliably works. I suggest you close the report until I can make sure it isn't caused by hardware failure.

OK, the hub is to blame. The scanner is fully functional. The bug is valid.

Hub?
Do you have a SCSI hub?

Is it connected via SCSI or via USB or perhaps via both?
Comment #3 confuses me.
From the YaST log it looks as if it is connected via SCSI
but comment #3 indicates that it is connected via USB.

Please grep for its USB vendor and model IDs in your
/etc/hal/fdi/policy/10osvendor/70-scanner.fdi
and
/etc/hal/fdi/policy/10osvendor/80-scanner.fdi

In my /etc/hal/fdi/policy/10osvendor/70-scanner.fdi I have
---------------------------------------------------------------------
 <match key="info.bus" string="usb_device">
  <match key="usb_device.vendor_id" int="0x05da">
   <match key="usb_device.product_id" int="0x0099">
    <append key="info.capabilities" type="strlist">scanner</append>
   </match>
  </match>
 </match>
---------------------------------------------------------------------
which matches to the output in comment #3.

In the lshal output in attachment #180993 [details] it is only listed
as USB scanner but not as SCSI scanner.

Therefore the udev/HAL/hal-resmgr magic should set up the
right permissions via ACL for the USB device file
/dev/bus/usb/*/*
but nothing can happen for SCSI because HAL doesn't
recognize it as a SCSI scanner.

If you like to use it via SCSI, I assume it is a problem like
https://bugzilla.novell.com/show_bug.cgi?id=226044
(see how one can use udevmonitor to debug such issues)
and/or
https://bugzilla.novell.com/show_bug.cgi?id=218393#c25
and further comments.

OK, we are probably suffering from miscommunication.

There's a small number of USB scanners which are not talked to via libusb. They talk an unusual protocol which is a derivative of usb storage. Therefore they have their own kernel driver which registers with the SCSI subsystem.

User space should treat them as SCSI scanners.

These are their device ids:

	{ USB_DEVICE(0x4ce, 0x0300) },
	{ USB_DEVICE(0x5da, 0x0094) },
	{ USB_DEVICE(0x5da, 0x0099) },
	{ USB_DEVICE(0x5da, 0x009a) },
	{ USB_DEVICE(0x5da, 0x00a0) },
	{ USB_DEVICE(0x5da, 0x00a3) },
	{ USB_DEVICE(0x5da, 0x80a3) },
	{ USB_DEVICE(0x5da, 0x80ac) },
	{ USB_DEVICE(0x5da, 0x00b6) },

Forgot to remove needinfo

Many thanks for the explanation in comment #14!

As far as I see this means the current udev/HAL/hal-resmgr magic
cannot work for those USB devices which are not accessed via
/dev/bus/usb/*/* but via /dev/sg*

I assume it worked for you in the past when we had
the ugly hack "/etc/init.d/sane-dev", see
https://bugzilla.novell.com/show_bug.cgi?id=218393#c26
how you could re-enable it again.

For next openSUSE version I try to cover even those special
devices by the udev/HAL/hal-resmgr magic.

As far as I see the problem is how to find out via HAL
which SCSI device file such an USB device actually uses
so that hal-resmgr could set the appropriate ACL for the
correct SCSI device file.

I try to fix it for openSUSE 11.0 , see bug #337766

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