[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
Hello, On Nov 9 18:39 Wilhelm wrote (shortened): Am 09.11.2010 17:47, schrieb Johannes Meixner: 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 Of course it is not scanbd's fault! 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. Now it looks promising! In particular because udev rules for very most scanners do already exist (a libsane.rules udev rules file from SANE plus generic udev rules like acl.rules) it should be relatively easy to enhance this to send additionally a singal to scanbd. According to http://scanbd.svn.sourceforge.net/viewvc/scanbd/trunk/Makefile?revision=23view=markup LDFLAGS += -lconfuse -lsane -lpthread -ldbus-1 -lhal -lhal-storage it seems it links with HAL libraries in any case so that I got the idea that it actually needs HAL in any case. Because HAL is deprecated, would you mind to change it so that it does no longer link with HAL so that it would compile as is for current Linux distributions? If you like to provide readymade RPMs for the usual current Linux distributions for the usual hardware architectures, I would like to suggest to have a look at the openSUSE build service: https://build.opensuse.org/ It is open and free to our greatest possible extent. All you need to do is to register yourself before you can use it. The only non-free issue is that we (i.e. Novell/openSUSE) do not support building of packages as an anonymous user. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
Hello, Am 10.11.2010 10:02, schrieb Johannes Meixner: Hello, On Nov 9 18:39 Wilhelm wrote (shortened): Am 09.11.2010 17:47, schrieb Johannes Meixner: 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 Of course it is not scanbd's fault! 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. Now it looks promising! In particular because udev rules for very most scanners do already exist (a libsane.rules udev rules file from SANE plus generic udev rules like acl.rules) it should be relatively easy to enhance this to send additionally a singal to scanbd. According to http://scanbd.svn.sourceforge.net/viewvc/scanbd/trunk/Makefile?revision=23view=markup LDFLAGS += -lconfuse -lsane -lpthread -ldbus-1 -lhal -lhal-storage it seems it links with HAL libraries in any case so that I got the idea that it actually needs HAL in any case. Because HAL is deprecated, would you mind to change it so that it does no longer link with HAL so that it would compile as is for current Linux distributions? Sure, I can make this optional. If you like to provide readymade RPMs for the usual current Linux distributions for the usual hardware architectures, I would like to suggest to have a look at the openSUSE build service: https://build.opensuse.org/ Thanks, I will have a look. It is open and free to our greatest possible extent. All you need to do is to register yourself before you can use it. The only non-free issue is that we (i.e. Novell/openSUSE) do not support building of packages as an anonymous user. Kind Regards Johannes Meixner -- Wilhelm
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
Wilhelm- This looks very promising! allan 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 to detect new scanners or scanners that vanished (usb plugoff) 2) scanbd uses dbus to sendout signals if it performs an action (scans and emails an image e.g). This can be used by desktop-applications. 3) scanbd uses a dbus-interface to expose methods to perform actions (this too can be used by desktop applications) 4) scanbd interacts nicely with saned: it stops polling the scanner buttons if the scanner-device must be used by saned. 5) scanbd can poll arbitrary number of scanner 6) flexible configuration This is a very early release of the piece of software - be warned. You can get it from: http://scanbd.svn.sourceforge.net/viewvc/scanbd/ Comments are very welcome! Am 05.11.2010 21:52, schrieb Mikael Nordenberg: Hi list. I've tried really hard to find information about how to detect if the button on my scanner is pressed. I've got a ScanSnap S1500, which is supported by the fujitsu backend, and works as expected using for example scanimage. The scanner itself only has one backlit button titled scan. If I press it, it starts to blink for a couple of seconds and then goes back to normal (which is constant lit). If I type scanimage --help I'm presented with numerous sensor options, including the following: ? ? --scan[=(yes|no)] [no] [hardware] ? ? ? ? Scan button Typing scanimage --scan results in: scanimage: unrecognized option '--scan' (None of the other sensor options is recognised either.) I've tried to access the scanner via saned using the network protocol, but the scan-option (#83) always responds false, even if I press and hold the scan button. Is this model not supported when detecting buttons, or am I doing something completely wrong? Best regards, Mikael -- 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 -- 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
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
Am 09.11.2010 15:02, schrieb m. allan noah: Wilhelm- This looks very promising! Thank you! Well, I posted it 2 years ago with minimal feedback - sadly. But we use it with our customers very frequently. allan 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 to detect new scanners or scanners that vanished (usb plugoff) 2) scanbd uses dbus to sendout signals if it performs an action (scans and emails an image e.g). This can be used by desktop-applications. 3) scanbd uses a dbus-interface to expose methods to perform actions (this too can be used by desktop applications) 4) scanbd interacts nicely with saned: it stops polling the scanner buttons if the scanner-device must be used by saned. 5) scanbd can poll arbitrary number of scanner 6) flexible configuration This is a very early release of the piece of software - be warned. You can get it from: http://scanbd.svn.sourceforge.net/viewvc/scanbd/ Comments are very welcome! Am 05.11.2010 21:52, schrieb Mikael Nordenberg: Hi list. I've tried really hard to find information about how to detect if the button on my scanner is pressed. I've got a ScanSnap S1500, which is supported by the fujitsu backend, and works as expected using for example scanimage. The scanner itself only has one backlit button titled scan. If I press it, it starts to blink for a couple of seconds and then goes back to normal (which is constant lit). If I type scanimage --help I'm presented with numerous sensor options, including the following: --scan[=(yes|no)] [no] [hardware] Scan button Typing scanimage --scan results in: scanimage: unrecognized option '--scan' (None of the other sensor options is recognised either.) I've tried to access the scanner via saned using the network protocol, but the scan-option (#83) always responds false, even if I press and hold the scan button. Is this model not supported when detecting buttons, or am I doing something completely wrong? Best regards, Mikael -- 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 -- 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 -- Wilhelm
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
What is the license? allan On Tue, Nov 9, 2010 at 9:33 AM, Wilhelm wilhelm.meier at fh-kl.de wrote: Am 09.11.2010 15:02, schrieb m. allan noah: Wilhelm- This looks very promising! Thank you! Well, I posted it 2 years ago with minimal feedback - sadly. But we use it with our customers very frequently. allan 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 to detect new scanners or scanners that vanished (usb plugoff) 2) scanbd uses dbus to sendout signals if it performs an action (scans and emails an image e.g). This can be used by desktop-applications. 3) scanbd uses a dbus-interface to expose methods to perform actions (this too can be used by desktop applications) 4) scanbd interacts nicely with saned: it stops polling the scanner buttons if the scanner-device must be used by saned. 5) scanbd can poll arbitrary number of scanner 6) flexible configuration This is a very early release of the piece of software - be warned. You can get it from: http://scanbd.svn.sourceforge.net/viewvc/scanbd/ Comments are very welcome! Am 05.11.2010 21:52, schrieb Mikael Nordenberg: Hi list. I've tried really hard to find information about how to detect if the button on my scanner is pressed. I've got a ScanSnap S1500, which is supported by the fujitsu backend, and works as expected using for example scanimage. The scanner itself only has one backlit button titled scan. If I press it, it starts to blink for a couple of seconds and then goes back to normal (which is constant lit). If I type scanimage --help I'm presented with numerous sensor options, including the following: ? ? --scan[=(yes|no)] [no] [hardware] ? ? ? ? Scan button Typing scanimage --scan results in: scanimage: unrecognized option '--scan' (None of the other sensor options is recognised either.) I've tried to access the scanner via saned using the network protocol, but the scan-option (#83) always responds false, even if I press and hold the scan button. Is this model not supported when detecting buttons, or am I doing something completely wrong? Best regards, Mikael -- 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 -- 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 -- Wilhelm -- The truth is an offense, but not a sin
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
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
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
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
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
FYI: scanbd (scanner button daemon) can be used in such a case: 1) scanbd uses hal dbus-interface to detect new scanners or scanners that vanished (usb plugoff) 2) scanbd uses dbus to sendout signals if it performs an action (scans and emails an image e.g). This can be used by desktop-applications. 3) scanbd uses a dbus-interface to expose methods to perform actions (this too can be used by desktop applications) 4) scanbd interacts nicely with saned: it stops polling the scanner buttons if the scanner-device must be used by saned. 5) scanbd can poll arbitrary number of scanner 6) flexible configuration This is a very early release of the piece of software - be warned. You can get it from: http://scanbd.svn.sourceforge.net/viewvc/scanbd/ Comments are very welcome! Am 05.11.2010 21:52, schrieb Mikael Nordenberg: Hi list. I've tried really hard to find information about how to detect if the button on my scanner is pressed. I've got a ScanSnap S1500, which is supported by the fujitsu backend, and works as expected using for example scanimage. The scanner itself only has one backlit button titled scan. If I press it, it starts to blink for a couple of seconds and then goes back to normal (which is constant lit). If I type scanimage --help I'm presented with numerous sensor options, including the following: --scan[=(yes|no)] [no] [hardware] Scan button Typing scanimage --scan results in: scanimage: unrecognized option '--scan' (None of the other sensor options is recognised either.) I've tried to access the scanner via saned using the network protocol, but the scan-option (#83) always responds false, even if I press and hold the scan button. Is this model not supported when detecting buttons, or am I doing something completely wrong? Best regards, Mikael -- 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 -- Wilhelm
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
Hi list. I've tried really hard to find information about how to detect if the button on my scanner is pressed. I've got a ScanSnap S1500, which is supported by the fujitsu backend, and works as expected using for example scanimage. The scanner itself only has one backlit button titled scan. If I press it, it starts to blink for a couple of seconds and then goes back to normal (which is constant lit). If I type scanimage --help I'm presented with numerous sensor options, including the following: --scan[=(yes|no)] [no] [hardware] Scan button Typing scanimage --scan results in: scanimage: unrecognized option '--scan' (None of the other sensor options is recognised either.) I've tried to access the scanner via saned using the network protocol, but the scan-option (#83) always responds false, even if I press and hold the scan button. Is this model not supported when detecting buttons, or am I doing something completely wrong? Best regards, Mikael -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20101105/2f5626f3/attachment.htm
[sane-devel] Detect scan button on ScanSnap S1500 (sane-fujitsu backend)
On Fri, Nov 5, 2010 at 4:52 PM, Mikael Nordenberg mikael at ikanos.se wrote: Is this model not supported when detecting buttons, or am I doing something completely wrong? Fortunately, it's the latter. Scanimage is not smart enough to monitor the buttons exposed by the driver and perform an action when they are pressed. Instead, you need a daemon which does this. There are a couple of them in our old 'experimental' cvs tree, but they are not widely used. One of these days someone will come forward with enough time to make one of these a more permanent addition to the sane-backends package. allan -- The truth is an offense, but not a sin
