[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)

[Johannes Meixner]

Hello,

On Nov 9 09:02 m. allan noah wrote:
> Wilhelm- This looks very promising!
>
> On Sat, Nov 6, 2010 at 3:18 PM, Wilhelm <wilhelm.meier at fh-kl.de> wrote:
>> FYI:
>>
>> scanbd (scanner button daemon) can be used in such a case:
>>
>> 1) scanbd uses hal dbus-interface ...

If it really needs HAL, it is probably not very promising
because HAL is meanwhile deprecated.

See for example
http://en.wikipedia.org/wiki/HAL_%28software%29
----------------------------------------------------------------
As of 2009, distributions such as Ubuntu, Debian, and Fedora,
and projects such as GNOME and X.org are in the process
of deprecating HAL
...
Initially a new daemon DeviceKit was planned to replace
certain aspects of HAL, but in March 2009, DeviceKit was
deprecated in favor of adding the same code to
udev as a package: udev-extras
----------------------------------------------------------------
You may follow the links therein.

Also we (i.e. Novell/openSUSE) are in the same process, see
http://lists.opensuse.org/opensuse-factory/2010-01/msg00055.html
----------------------------------------------------------------
     Future Development of "hal" has been stopped.

Right, there is no future release planned. The project is dead
and the functionality replaced by a bunch of other projects.
...

         What is replacing it?

     udev-extras (merge between DeviceKit and udev)

There is no udev-extras. It was a temporary solution
and no such package exists anymore.
----------------------------------------------------------------

At least for me the whole stuff does not look very promising:
HAL deprecated -> DeviceKit deprecated -> udev-extras deprecated

Welcome to the hell of udev, HAL and its various replacements...

In the end from my point of view only plain udev is what
one can assume that it exists on an end-user's Linux system
but it does not provide a really stable user interface.

See
http://www.kernel.org/doc/#sys
----------------------------------------------------------------
The maintainers of sysfs do not believe in a stable API, and
change userspace-visible elements from release to release.
The rationale is that sysfs exports information from inside
the kernel to outside the kernel (what API doesn't?) and the
kernel internals change, thus sysfs changes to reflect it.
...
In reality, sysfs is treated as a private API exported for
the use of the "udev" program
----------------------------------------------------------------

You will learn the consequences when you make udev rules.
Those are not really stable (it is luck if they are stable
for some time) so that you may have to adapt them
from kernel release to release so that strictly speaking
a userspace application which needs udev rules depends
on a particular kernel release.

As far as I found out the root cause seems to be that udev
is actually meant as a kernel internal tool which is
maintained by kernel maintainers so that the udev rules
for kernel internal stuff (in particular for device drivers
in the kernel) are updated and maintained in compliance
to the particular kernel release.

As far as I know a userspace application which needs udev rules
seems to be currently some kind of misuse of the kernel internal
tool "udev".

But I am not at all a udev expert so that I could be wrong here.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex