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
