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

[m. allan noah]

Yes- Wilhelm and I have been discussing this off list. It appears that
we can get scanbd to be very useful, even without desktop integration
via hal.

allan

On Tue, Nov 9, 2010 at 12:39 PM, Wilhelm <wilhelm.meier at fh-kl.de> wrote:
> 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
>
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>             to sane-devel-request at lists.alioth.debian.org
>



-- 
"The truth is an offense, but not a sin"