Bug 218393

HAL seems to work correctly because my scanners are listed
as expected in in lshal:
---------------------------------------------------------------------------
caps:~ # sane-find-scanner -q
found USB scanner (vendor=0x04b8 [EPSON], product=0x010b [Perfection1240])
 at libusb:001:004
found USB scanner (vendor=0x04b8 [EPSON], product=0x0121 [EPSON Scanner])
 at libusb:001:003

caps:~ # lshal | grep -B20 'info.capabilities.*scanner' \
 | egrep 'linux.device_file|info.capabilities'
  linux.device_file = '/dev/bus/usb/001/004'  (string)
  info.capabilities = {'usbraw', 'scanner'} (string list)
  linux.device_file = '/dev/bus/usb/001/003'  (string)
  info.capabilities = {'usbraw', 'scanner'} (string list)
----------------------------------------------------------------------------

is this beta1 or beta1plus or beta2?

Beta1 (as shown in the "Version" entry).

please attach "lshal" output to the bug ;)

ludwig is back on monday.

Right now I updated to remgr from STABLE
and restarted the resmgr service.

caps:~ # rpm -q resmgr
resmgr-1.1.0_SVNr123-4

But I don't see any difference.
When I log in as normal user "johannes" on text console
I don't have scanner access and "/sbin/resmgr list" doesn't
show any devices (only "no devices available").
Even when I unplug and re-plug a scanner there is no difference.
The same after graphical login.

use
/usr/sbin/hal-resmgr --list

in 10.2. this will show the active devices.

caps:~ # ls /usr/sbin/hal-resmgr
/bin/ls: cannot access /usr/sbin/hal-resmgr: No such file or directory

caps:~ # rpm -q hal-resmgr
package hal-resmgr is not installed

Ahhh!

It seems it was simply not installed by default in the standard
installation for beta1.
According to
/mounts/dist/install/stable-x86/suse/setup/descr/*.pat
it seems to be now in the "base" patterns.

Nevertheless, after installing it and restarting hal and resmgr
it still doesn't work.

According to
/usr/share/doc/packages/hal-resmgr/README
I write the wrong entries into /etc/hal/fdi/policy/10osvendor/70-scanner.fdi
and /etc/hal/fdi/policy/10osvendor/80-scanner.fdi but I do it as
discussed in bug #160899 (I assume there is only the documentation
outdated).

Created attachment 104490 [details]
Output of "lshal"

Created attachment 104491 [details]
Content of 70-scanner.fdi

Created attachment 104492 [details]
Content of 80-scanner.fdi

Tried it even with an old-style entry in 80-scanner.fdi
according to /usr/share/doc/packages/hal-resmgr/README
------------------------------------------------------------------------------
    <match key="info.category" string="usbraw">
      <match key="@info.parent:usb_device.vendor_id" int="0x04b8">
        <match key="@info.parent:usb_device.product_id" int="0x010b">
          <merge key="resmgr.class" type="string">scanner</merge>
        </match>
      </match>
    </match>
------------------------------------------------------------------------------
and restart of resmgr and hal but again no scanner access as normal user.

the file from #11 should work. Problem with the other method is that hal reads files from /etc after the ones in /usr and the fdi file that matches for scanners is in /usr ... I moved all resmgr files to /etc now.

I do not understand what I must do because of comment #12.

My questions:

1.
Must I change back from
  <append key="info.capabilities" type="strlist">scanner</append>
to
  <merge key="resmgr.class" type="string">scanner</merge>
?

2.
I don't know about a fdi file for scanners in /usr/
I write only to /etc/
Which file for scanners in /usr/ do you mean?

you don't need to do anything, the fix/workaround is in hal-resmgr. setting info.capabilities is fine.

Updated hal-resmgr to version hal-resmgr-0.1_SVNr122-9 and it works.
But I had to re-plug two of my scanners to the USB.
One model worked without re-plug - strange magic.

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

It works perfectly for all my scanners with openSUSE beta2plus.

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

For your information:

It works somehow but does not work nice.

Meanwhile I have openSUSE 10.2 RC1 installed.
I configured my scanners with YaST which had to install
the package sane (because it was not installed by default).
I got no user access until I did a reboot.

My scanners are listed in
/etc/hal/fdi/policy/10osvendor/70-scanner.fdi
which is created when the package sane gets installed
(see comment #0).

Perhaps the HAL/hal-resmgr machinery is not triggered when
/etc/hal/fdi/policy/10osvendor/70-scanner.fdi
is created?

I tried to re-plug a scanner to the USB but this had no effect.
I did a reboot and now I have user access for my scanners.
It seems we have (at least in some cases) Windows behaviour.

looks like hal has some fdi file caching now and doesn't notice changes

For your information:

User access works perfectly for another new connected scanner
which is also listed in /etc/hal/fdi/policy/10osvendor/70-scanner.fdi
This file is never changed after it was created.
YaST writes only to 80-scanner.fdi, see comment #0.

I.e. the crucial difference seems to be whether or not the fdi file exists
during startup of the HAL machinery and according to comment #19 this means
to do a reboot when only one scanner is connected (which is the normal case).

The problem described since comment #19 should be avoided
because a scanner user frontend (which requires the package sane)
is now installed by default on all normal systems, see bug #224411

It works perfectly for me using openSUSE 10.2 RC4
default installation with Gnome.

More precisely:
It works perfectly only for those devices which are already listed in
/etc/hal/fdi/policy/10osvendor/70-scanner.fdi
The problem decribed in comment #19 still exists for devices which are
added by YaST to 80-scanner.fdi (i.e. which are not listed in 70-scanner.fdi).

I have this case fail in 10.2RC1:
Boot computer. Turn on SCSI scanner (HP 4P). Run rescan-scsi-bus.sh (nothing ever worked without this). Start yast to configure scanner - no problem with yast, auto-detection is fine, sane is correctly configured. No user access to this scanner is possible because /dev/sg* didn't get adjusted.
sane-find-scanner lists the scanner when run as root, but not otherwise.

This situation is very common, I don't think anyone has their SCSI scanners on 24/7. I didn't check whether a reboot will fix it because having to reboot for each scanner use isn't the done thing with Linux ;)

Is turning on a SCSI scanner after booting supposed to work somehow? Because it does with sane-dev, although I often have to run it twice on <=10.1.

While one can argue that an HP 4P belongs on the scrap heap, the same problem exists with film scanners, which on professional level have used SCSI until rather recently. At the cost of those devices I imagine people prefer them to work :)

I have yast logs but don't want to open a new bug before getting your opinion. Thanks!

Some more background info:

sane-dev still exists in the package sane as /usr/share/sane/sane-dev
so that it can be re-enabled if this works better than the current
HAL-based stuff. To re-enable sane-dev do
cp -p /usr/share/sane/sane-dev /etc/init.d/sane-dev
ln -s /etc/init.d/sane-dev /usr/sbin/rcsane-dev
insserv sane-dev
rcsane-dev start

By the way:
Right now I also had to do "rcsane-dev start" twice until my
SCSI processor "HP C6270A 3846" at /dev/sg0 (sane-find-scanner output)
was recognized and /dev/sg0 got appropriate permissions.
I know that this models falls asleep and needs a very long time
to wake up - perhaps this is the reason?

HP SCSI scanners are a bit special bcause (at least some of them)
do not show up as SCSI device with type "scanner" but with
type "processor" - see the sane-find-scanner output.
(As far as I know this is because those devices do not support
the standard SCSI command set for SCSI scanners).
Therefore 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>
----------------------------------------------------------------------
does not apply for SCSI processors and therefore YaST writes an
additonal special entry to
/etc/hal/fdi/policy/10osvendor/80-scanner.fdi
--------------------------------------------------------------------------
    <match key="info.category" string="scsi_generic">
      <match key="@info.parent:scsi.type" string="processor">
        <match key="@info.parent:scsi.vendor" string="HP">
          <append key="info.capabilities" type="strlist">scanner</append>
        </match>
      </match>
    </match>
--------------------------------------------------------------------------
which works at least for me (using openSUSE RC4) with the fixed
/usr/lib/YaST2/bin/test_and_set_scanner_access_permissions
according to https://bugzilla.novell.com/show_bug.cgi?id=223875#c6
but after the setup with YaST I had to reboot the system once.

I don't know if turning on a SCSI scanner after booting is supposed
to work. I hope HAL may notice the new appearing SCSI device and
then via the HAL fdi files /usr/sbin/hal-resmgr would be triggered
to set up an appropriate ACL for the device node - use for example
  getfacl /dev/sg0
to see the ACL for /dev/sg0.
I didn't test it because my "HP C6270A 3846" has no off/on switch and
I don't dare to re-plug its power supply while the system is running.

I have an umax scsi scanner at home. It has no power switch itself either, I power cycle it via a switch at the power socket since years. Didn't hurt so far.

For the log:

Regarding the problem described since comment #19:

I asked our HAL expert:
-------------------------------------------------------------------------
according to
https://bugzilla.novell.com/show_bug.cgi?id=218393#c19
and the subsequent comments, it seems HAL does not notice
when fdi files are changed during runtime.

For example the YaST scanner configuration adds entries to
/etc/hal/fdi/policy/10osvendor/80-scanner.fdi
to grant normal user access to scanners (via hal-resmgr).

How can I trigger HAL to notice a changed fdi file
or how can I let HAL re-process a particular fdi file?

Note that unplug and replug of the device is not possible
for SCSI scanners during runtime (and even for USB scanners
it would be not nice when the YaST scanner configuration
would have to tell the user that he must unplug and replug
the device to the USB).
-------------------------------------------------------------------------

His answer:
---------------------------------------------------------------------------
IIRC: there is currently no mechanism in HAL to detect a change in a
fdi-file  while HAL is running and apply this changes to a related
device which is already processed.

You can do this:
- remove and readd the device, hal should read the new fdi-file 

or:

- you can try to call (replace $device_UDI with the udi of your device):
  dbus-send --system --print-reply --dest=org.freedesktop.Hal \
  $device_UDI org.freedesktop.Hal.Device.Rescan

IMO some automatic magic would be not the best idea, because you can't say 
which device is effected by a change in a fdi-file and hence HAL need to 
reprocess _all_ devices. A restart of HAL or a manually triggered rescan 
should be much better in this case.
---------------------------------------------------------------------------

I will have a look at the "dbus-send" stuff - perhaps this may
lead to a solution for the next openSUSE version?

meanwhile I got a SCSI scanner (i.e. with SCSI type "scanner")
which is not recognized by HAL, see bug #226044
and therefore there cannot be resmgr access via hal-resmgr
for this device (after "chmod a+rw /dev/sg0" it works fine).

More information form the HAL expert:
----------------------------------------------------------------------------
HAL will apply the same fdi information it has read on startup.
There is currently no way of applying new fdi information
without restarting HAL. 

Watching the directories with Inotify is the way to go, yes.
Udev and D-Bus are already doing that for a long time.
----------------------------------------------------------------------------