[sane-devel] using scanners unable to USB_AUTOSUSPEND
Hi all, recently I had problems with my old EPSON 1670 Scanner, because it doesn't support usb autosuspend that most distros enable by default in the linux kernel. That causes scanimage or other applications (e.g. like scanner button daemon scanbd) to freeze or even reading wrong values. If anyone is interested: I have put some hints in README.txt of scanbd. You can find it at http://scanbd.svn.sourceforge.net/viewvc/scanbd/trunk/doc/?sortby=rev HTH, -- Wilhelm
[sane-devel] using scanners unable to USB_AUTOSUSPEND
Hello,
On Jan 10 16:58 Wilhelm wrote (excerpt):
recently I had problems with my old EPSON 1670 Scanner, because it doesn't
support usb autosuspend that most distros enable by default in the linux
kernel. That causes scanimage or other applications (e.g. like scanner button
daemon scanbd) to freeze or even reading wrong values.
If I remember correctly a longer time ago the usb autosuspend issue
was discussed on this list.
As a consequence the sane-backends libsane.rules file for udev
(it is /etc/udev/rules.d/55-libsane.rules at least in openSUSE)
that is generated by tools/sane-desc.c in the sane-backends sources
contains:
---
# Epson Perfection 1670
ATTR{idVendor}==04b8, ATTR{idProduct}==011f, ... ENV{libsane_matched}=yes
...
# The following rule will disable USB autosuspend for the device
ENV{libsane_matched}==yes, RUN+=/bin/sh -c
'if test -e /sys/$env{DEVPATH}/power/control;
then echo on /sys/$env{DEVPATH}/power/control;
elif test -e /sys/$env{DEVPATH}/power/level;
then echo on /sys/$env{DEVPATH}/power/level; fi'
---
(the actual udev rules are single long lines - only wrapped here)
Accordingly - if your EPSON 1670 matches the idVendor/idProduct - it
should get ENV{libsane_matched}=yes and USB autosuspend should get
disabled for it.
Unfortunately things in udev/sysfs are unstable by design (udev/sysfs is
primarily meant as a helper tool to do kernel related stuff and not
a tool for application programs - sane-backends ia an application
from the kernel point of view) so that it depends on the kernel
and udev version whether or not udev rules actually work.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
[sane-devel] Perfection 610: cannot scan in color
The -y 297.18 (not --br-y) command works. Thanks for your help. On 01/08/2013 11:19 PM, Olaf Meeuwissen wrote: Evil Mr Henry writes: Basically, scanimage -v -d epson2:libusb:003:005 --format png outfile.png works, but scanimage -v --mode color -d epson2:libusb:003:005 --format png outfile.png throws the classic invalid argument Shouldn't that be --mode Color, with a capital C? (It is, in fact, an Epson Perfection 610 USB scanner.) This is a new computer; the scanner worked on my old computer in much the same setup. What version of sane backends and which backend did you use there? Running Mint (Ubuntu) 64bit, Sane 1.0.22-7ubuntu1 The following is the output after setting export SANE_DEBUG_EPSON2=255: scanimage -v --mode color -d epson2:libusb:003:005 --format png outfile.png I've gone through the log and it's clear from that that this is a bug in the epson2 backend. It fails to take into account the line distance when computing the maximum scan area, leading to a maximum that is too big. You can work around the issue by using --br-y 297.18 (i.e. 11.7 inches). Hope this helps,
[sane-devel] Perfection 610: cannot scan in color
Also, for anyone else with this problem, this works in XSane when I set the scan size to DIN A4 port. On 01/08/2013 11:19 PM, Olaf Meeuwissen wrote: Evil Mr Henry writes: Basically, scanimage -v -d epson2:libusb:003:005 --format png outfile.png works, but scanimage -v --mode color -d epson2:libusb:003:005 --format png outfile.png throws the classic invalid argument Shouldn't that be --mode Color, with a capital C? (It is, in fact, an Epson Perfection 610 USB scanner.) This is a new computer; the scanner worked on my old computer in much the same setup. What version of sane backends and which backend did you use there? Running Mint (Ubuntu) 64bit, Sane 1.0.22-7ubuntu1 The following is the output after setting export SANE_DEBUG_EPSON2=255: scanimage -v --mode color -d epson2:libusb:003:005 --format png outfile.png I've gone through the log and it's clear from that that this is a bug in the epson2 backend. It fails to take into account the line distance when computing the maximum scan area, leading to a maximum that is too big. You can work around the issue by using --br-y 297.18 (i.e. 11.7 inches). Hope this helps,
[sane-devel] Scanner Button Daemon [scanbd]: release 1.3
On Sun, 2013-01-06 at 15:25 -0500, Michael Watson wrote:
Thank you.
I have 1.3 working on archlinuxarm (systemd). Please find below
integration tweaks:
--
/usr/lib/systemd/system/scanbd.service
#Type=simple
# dbus
Type=dbus
I would recommend against changing the Type to dbus. That will
result in scanbm triggering starting of scanbd. It is not required
for scanbm that scanb is running. In my own copy I have removed the
BusName line from scanbd.service instead. It is superfluous.
--
/usr/lib/systemd/system/scanbm at .service
# required for systemctl enable scanbm@
[Install]
WantedBy=multi-user.target
No this is wrong! scanbm.socket should be enabled and started and
that triggers scanbm at .service when you use the scanner using the
net backend from the client application.
Scanbm.service should NOT have an install section.
#/etc/systemd/system/multi-user.target.wants/scanbm at .service -
/usr/lib/systemd/system/scanbm at .service
--
/etc/xinetd.d/sane
service sane-port
{
port= 6566
socket_type = stream
wait= no
user= saned
group = scanner
server = /usr/local/sbin/scanbm
#not sure if this is required
server_args = scanbm
# disabled by default!
disable = no
}
Using systemd with scanbm.socket should take care of handling the socket
on
port 6566. I don't even have (x)inetd installed. scanbm.socket does the
above
for you and tells systemd to start scanbm.service when you scan using
the
net backend from your application.
The above of course assumes a complete systemd that does replace
(x)inetd.
Does systemd on ArchLinux support socket activation?
Kind regards, Louis
