[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] Canon CanoScan 9000F (similar to 8800F) supported by sane?
Am Mo, 06 Sep 2010 22:55:55 CEST schrieb Gernot Hassenpflug: Hi, quick message only: 9000F is working, only needs 9600dpi resolution in TPU mode implemented correctly, other than that all resolutions work. Code will be sent for checking committing as soon as final checks are done. Cannot give estimate before available from CVS but in 1 week I should be able to supply test code to interested parties who do not want to wait. The newest packages for Opensuse 11.2 are: http://download.opensuse.org/repositories/graphics/openSUSE_11.2/ xsane-0.997-12.2.i586 sane-backends-autoconfig-1.0.21-38.1.i586 sane-backends-1.0.21-38.1.i586 My question is, if the 9000F drivers are finished in the meantime? Which sane version is needed? Al
[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
