[sane-devel] Sane and HAL

[abel deuring]

Hi Johannes,
> Hello,
> 
> On Jan 3 20:40 abel deuring wrote (shortened):
>>>https://bugzilla.novell.com/show_bug.cgi?id=160899#c20
>>So the Suse team is already doing basically the same as I proposed.
>>Seems that I am a bit too late ;) But I think it makes sense to add
>>information like the sane backend(s) that are "useful" for a
>>specific scanner to the data in the fdi file.
> 
> Of course you are not late because currently all what we do

I was just joking ;)

> is to use udev->HAL->resmgr to set access permissions.
> For this it is currently sufficient for us to mark
> a HAL device as a "scanner".
> 
> What is needed for the future is an agreement which HAL keys
> with which possible values must/should/can be added to a HAL
> device which is a "scanner" so that applications know which keys
> they must/should/can query and which values HAL may return.

Indeed. Sorry, I should have mentioned the following earlier in this
list: I started already a discussion about useful keys on the HAL
list. The result so far would give an entry for a scanner in the fdi
file like so:

  <device>
    <match key="usb.vendor_id" int="0x043d">
      <match key="usb.product_id" int="0x007c">
        <append key="info.capabilities"
                type="strlist">scanner</append>
        <append key="scanner.vendor" type="strlist">Lexmark</append>
        <append key="scanner.model" type="strlist">X1140</append>
        <append key="scanner.api" type="strlist">sane</append>
        <append key="scanner.sane.backend"
                type="strlist">lexmark</append>
        <append key="scanner.sane.supportstatus"
                type="strlist">untested</append>
        <merge key="scanner.sane.is_supported"
               type="bool">true</merge>
      </match>
    </match>
  </device>

scanner.vendor and scanner.model are obvious, I think;
scanner.api is intended to allow for other APIs than Sane;
scanner.sane is a sub-namespace for Sane;
scanner.sane.backend lists, well, backends for this scanner
scanner.sane.is_supported is set to false for the devices in
unsupported.desc

As you see, most keys can have multiple values; this is hard to
avoid, because we have several cases, where different scanners share
the same ID. If we want to reduce this for a "real" entry, we will
need a HAL callout that lets the backend open the device.

The scanner.sane.backend key is a strlist to allow things as you
mention at the end of your mail: For some scanners, more than one
backend may be available. And if a user installs, as is your
example, iscan and the backends of the Sane project, we can assume
that s/he wants to have the option to select these backends. In this
case, a frontend must simply ask the user, which is the right one ;)

With this data, the output from lshal (i.e., everything HAL "knows"
about the scanner) looks like this (some line breaks added by the
mail client):

udi = '/org/freedesktop/Hal/devices/usb_device_4c5_10e0_noserial_if0'
  info.udi =
'/org/freedesktop/Hal/devices/usb_device_4c5_10e0_noserial_if0'
(string)
  scanner.sane.supportstatus = {'good'} (string list)
  scanner.sane.backend = {'fujitsu'} (string list)
  scanner.sane.is_supported = true  (bool)
  scanner.api = {'sane'} (string list)
  scanner.model = {'fi-5120C'} (string list)
  scanner.vendor = {'Fujitsu'} (string list)
  info.capabilities = {'scanner'} (string list)
  linux.subsystem = 'usb'  (string)
  linux.hotplug_type = 1  (0x1)  (int)
  info.product = 'USB Vendor Specific Interface'  (string)
  usb.interface.protocol = 255  (0xff)  (int)
  usb.interface.subclass = 255  (0xff)  (int)
  usb.interface.class = 255  (0xff)  (int)
  usb.interface.number = 0  (0x0)  (int)
  usb.linux.sysfs_path =
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'  (string)
  usb.configuration_value = 1  (0x1)  (int)
  usb.num_configurations = 1  (0x1)  (int)
  usb.num_interfaces = 1  (0x1)  (int)
  usb.device_class = 0  (0x0)  (int)
  usb.device_subclass = 0  (0x0)  (int)
  usb.device_protocol = 0  (0x0)  (int)
  usb.vendor_id = 1221  (0x4c5)  (int)
  usb.product_id = 4320  (0x10e0)  (int)
  usb.vendor = 'Fujitsu, Ltd'  (string)
  usb.product = 'USB Vendor Specific Interface'  (string)
  usb.device_revision_bcd = 256  (0x100)  (int)
  usb.max_power = 98  (0x62)  (int)
  usb.num_ports = 0  (0x0)  (int)
  usb.linux.device_number = 2  (0x2)  (int)
  usb.speed_bcd = 4608  (0x1200)  (int)
  usb.version_bcd = 512  (0x200)  (int)
  usb.is_self_powered = true  (bool)
  usb.can_wake_up = false  (bool)
  usb.bus_number = 1  (0x1)  (int)
  info.bus = 'usb'  (string)
  info.parent =
'/org/freedesktop/Hal/devices/usb_device_4c5_10e0_noserial'  (string)
  linux.sysfs_path_device =
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'  (string)
  linux.sysfs_path =
'/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'  (string)

>>A simple solution would be to restart hald
> 
> No! (As far as I know.)
> Reason:
> Stopping and restarting the comlpete HAL service may cause that
> all those zillions of actions are re-done which happened since
> HAL was running (e.g. umount and mount of whatever hotpluggable
> storage devices which may interrupt an ongoing file transfer)
> because HAL is not only there for scanners but for whatever
> arbitrary (unexpected) other stuff.

Ouch, yes, this sounds reasonable. On the other hand, I noticed that
I needed to restart hald in order to test the fdi file generated
from the *desc files. But let's leave the details to the HAL
developers. Douglas Adams' SEP concept (Somebody Elses Problem) is
from time to time quite useful ;)

>>>My personal opinion is that I do not like it when my computer
>>>launches whatever program it thinks to be useful for me
>>>automatically (perhaps I don't want to use any graphical
>>>frontend at all or I prefer xscanimage).
>>I agree -- but the automatic start of an application seems to become
>>quite fashionable: When I plug in a USB memory stick, KDE starts a
>>file browser.
> 
> Thanks to remind me why I do no longer use any desktop at all
> since a longer time - I use only a windowmanager.

;)

>>What I forgot to mention in my first mail: I asked also on the HAL
>>mailing list for comments about HAL support by Sane
>>(http://lists.freedesktop.org/archives/hal/2006-December/006826.html).
>> Today, David Zeuthen writes over there: "Parallel port (and serial
>>port) support isn't really in HAL". So we should probably put
>>parport support aside for the moment.
> 
> Yes.
> When HAL is not required it doesn't hurt if it is not supported
> for some kind of connections (i.e. I think it is perfectly
> sufficient when HAL supports only USB scanners).

Right. And we can the parport stuff, when/if HAL will support
parport devices.

> By the way:
> "HAL support in SANE" versus "SANE support in HAL":
> 
> Wouldn't it be even better to have a fdi file for scanners
> in the HAL package so that HAL knows on its own which devices
> are a scanner and for which there is support via SANE and/or
> via whatever external backend?
> Then whatever software installation tools could ask HAL
> which software must be installed to get this hardware running.
> I.e. the user would not have to know that there is a package
> SANE (or whatever external backend) required to get his
> hardware running.
> 
> But this results an update problem:
> When SANE is updated, the fdi file for scanners in HAL
> would be outdated and at the moment I have no good idea how
> during installation of SANE the fdi file for scanners in HAL
> could be updated - except to simply overwrite it via RPM
> postinstall script - but then SANE may overwrite info about
> non-SANE software in the original fdi file from HAL.

The problem is that the most recent *desc files are in the Sane CVS
repository (or on the "private" homepages of the various backends);
a "more or less recent" snapshot is in the official Sane tar balls.
If an fdi file is added to the hal-info package, we mostly have
additional bureaucracy: Somebody must run the fdi generator script,
send the result to the HAL folks, and they must update the file in
their source code repository.

I think it is better to keep the file in the Sane package. The
configure script could get a new option "--with-fdi-file" (and some
related options: It is hard to make a final decision, if unsupported
devices and cameras should be included), so we leave the decision to
people who install Sane, if they want the file or not.

And you and your colleagues who maintain packages for Debian,
Ubuntu, Fedora etc might also have different opinions, which
package(s) should contain the scanner fdi file, and how often it
should updated etc.

Regarding possible conflicts with scanner data from other sources: I
think that this can never be completely avoided in the "highly
distributed" world of free software. One option would be to
"reserve" a file name and file location for the fdi file that comes
from the sane-backends package. That's something I need to ask the
folks working on HAL.

> Another question is how can various hardware manufacturers
> provide various fdi files for their scanners?
> 
> Having multiple fdi files for scanners may result a problem
> with multiple entries for the same piece of hardware.
> I don't know if HAL can deal with it but I fear there
> are problems, see for example
> https://bugzilla.novell.com/show_bug.cgi?id=205669

This is indeed a funny case of pure redundancy. But HAL itself
should not become confused by this -- and callouts and applications
who want to use the possibly duplicated data should simply be
prepared for it. For my -- admittedly very fresh -- impression, HAL has

> Think about a fdi file from Epson Avasys for their scanners
> which is included in their driver and the same scanners
> are also already listed in the HAL or SANE fdi file(s).

I hope that my proposal for the "scanner namespace" can deal with
this case -- except of course for possible file name/location
conflicts. But install scripts that intend to "play nice" should be
able to avoid them.

cheers
Abel