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

[Wilhelm]

Hello,

Am 09.11.2010 17:47, schrieb 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.

yes, I know that!

But its not scanbd's fault: all (desktop or not) applications need some
kind of HW-notification.

For scanbd it's already there: send a signal and it will look for new
devices (not via hal, via libsane!). And that is the only purpose libhal
is used for! If hal isn't available, that dowsn't hurt: write a
udev-rule to send a signal to scanbd (or restart it ...)

Bottom line: scanbd may use libhal/dbus, but if hal isn't available, it
does not hurt: the only consequence is, that newly plugged scanners
aren't instantly detected. Then you can send a signal or restart it via
udev.


> 
> 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


-- 
Wilhelm