[sane-devel] sane_read: Invalid argument on Epson Perfection 1640SU
Henrik Lundberg writes:
> Hello,
Hi,
> I am trying to get an Epson Perfection 1640SU to work under Debian Etch.
> I'm using udev and the device file shows up as it should, and the epson
> and epkowa backends detects the scanner:
That's what I use as my primary development environment but I haven't
used the 1640 in ages.
> $ scanimage -L
> device `epson:libusb:002:002' is a Epson Perfection1640 flatbed scanner
> device `epkowa:libusb:002:002' is a Epson Perfection 1640 flatbed
> scanner
>
> However, when trying a default scan it fails:
>
> $ SANE_DEBUG_EPSON=128 scanimage -d epson 2> testscan.err
> P4
> # SANE data follows
> 424 585
Have you tried with the epkowa backend? Did that work?
> testscan.err is attached.
> In the error output i see a couple of lines reading '[epson] option:
> fatal error'.
Hmm, right from the beginning the scanner indicates a fatal error.
This keeps going on during all of the setup of the scanner. Then when
you start getting ready for a scan it disappears (status 12) only to
reappear when the backend initiates the scan (status b2, which also
indicates there's no more image data to be expected).
> [epson] Found valid EPSON scanner: 0x4b8/0x10a (vendorID/productID)
> [epson] reset()
> [epson] send buf, size = 2
> [epson] buf[0] 1b .
> [epson] buf[1] 40 @
> [epson] receive buf, expected = 1, got = 1
> [epson] buf[0] 06 .
> [epson] get_identity_information()
> [epson] send buf, size = 2
> [epson] buf[0] 1b .
> [epson] buf[1] 49 I
> [epson] receive buf, expected = 4, got = 4
> [epson] buf[0] 02 .
> [epson] buf[1] 92 .
> [epson] buf[2] 6a j
> [epson] buf[3] 00 .
> [epson] code 02
> [epson] status 92 <--- fatal error flag is set
> [epson] count 106
> {snip}
> [epson] SANE_START: Color: 0
> [epson] SANE_START: Resolution (x, y): (50, 50)
> [epson] SANE_START: Scan area(pixels) (x0, y0), (x1, y1): (0, 0), (424, 585)
> [epson] SANE_START: Data format: 1
> [epson] SANE_START: Halftone: 0
> [epson] SANE_START: Brightness: 0
> [epson] SANE_START: Gamma: 1
> [epson] SANE_START: Zoom (x, y): (100, 100)
> [epson] SANE_START: Color correction: 128
> [epson] SANE_START: Sharpness control: 0
> [epson] SANE_START: Scanning mode: 0
> [epson] SANE_START: Mirroring: 0
> [epson] SANE_START: Auto area segmentation: 1
> [epson] SANE_START: Threshold: 128
> [epson] SANE_START: Line counter: 255
> [epson] SANE_START: Option unit control: 0
> [epson] SANE_START: Film type: 0
> [epson] send buf, size = 2
> [epson] buf[0] 1b .
> [epson] buf[1] 47 G
> [epson] sane_get_parameters()
> [epson] Returning saved params structure
> [epson] Restoring parameters from saved parameters
> [epson] Preview = 0
> [epson] Resolution = 50
> [epson] get para 0x51dc80 0x51e750 tlx 0.00 tly 0.00 brx 215.84
> bry 297.179993 [mm]
> [epson] params.format = 0
> [epson] params.last_frame = 1
> [epson] params.bytes_per_line = 53
> [epson] params.pixels_per_line = 424
> [epson] params.lines = 585
> [epson] params.depth = 1
> [epson] sane_read: begin
> [epson] sane_read: begin scan1
> [epson] receive buf, expected = 6, got = 6
> [epson] buf[0] 02 .
> [epson] buf[1] b2 .
> [epson] buf[2] 00 .
> [epson] buf[3] 00 .
> [epson] buf[4] 00 .
> [epson] buf[5] 00 .
> [epson] fatal error - Status = b2
> Packages libsane and sane-utils are of version 1.0.18-3 and scanimage -V
> reports 1.0.18 as well.
>
> I hope that you may have an idea of what's wrong.
Unfortunately, I don't. However, the fact that the backend gets a
fatal error immediately after it has re-initialised the device might
indicate there is something wrong with the device. Maybe the lock is
on? Does it work on that other OS (assuming you have access so you
can check)?
Hope this helps,
--
Olaf Meeuwissen EPSON AVASYS Corporation, SE1
FSF Associate Member #1962 sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
Penguin's lib! -- I hack, therefore I am -- LPIC-2
[sane-devel] Well known option consensus
?tienne Bersac wrote:
> \section{Papersize}
>
> When using an Automatic Document Feeder, the user generally cannot
> preview. If the page being scanned is smaller than the maximum size
> supported by the hardware/backend, the frontend cannot determine
> the location of the document on the scan surface, and cannot limit
> the values of the scan area (tl-x/y and br-x/y) to match.
>
> If the backend implements options for the frontend user to set the
> paper size, the backend should limit the range of the scan area to
> that defined by the paper. The scan area is then relative to paper
> origin, not scan surface origin.
>
> \begin{options}
> \option{paper-width}{\FIXED}{\MM}{Paper width.}
> \option{paper-height}{\FIXED}{\MM}{Paper height.}
> \end{options}
Now things become really tricky ;) Some Fujitsu ADF scanners (and
probably also devices from other manufacturers) have a so-called
"overscan mode". In overscan mode, the scan window is larger than
the page size; for pixels outside tha page area, you get a
background colour (you can even select between white and black
background). This allows to detect and correct skewed scans and to
check the page size by "analyzing" the image.
So, stating that the scan window should not be larger than the page
size is not such a good idea...
It might be better if the backend tells the frontend, if scan window
coordinates are relative to the entire scan area or to the selected
page size.
Abel
[sane-devel] Well known option consensus
On 1/21/07, abel deuring wrote:
> ?tienne Bersac wrote:
>
> > \section{Papersize}
> >
> > When using an Automatic Document Feeder, the user generally cannot
> > preview. If the page being scanned is smaller than the maximum size
> > supported by the hardware/backend, the frontend cannot determine
> > the location of the document on the scan surface, and cannot limit
> > the values of the scan area (tl-x/y and br-x/y) to match.
> >
> > If the backend implements options for the frontend user to set the
> > paper size, the backend should limit the range of the scan area to
> > that defined by the paper. The scan area is then relative to paper
> > origin, not scan surface origin.
> >
> > \begin{options}
> > \option{paper-width}{\FIXED}{\MM}{Paper width.}
> > \option{paper-height}{\FIXED}{\MM}{Paper height.}
> > \end{options}
>
>
> Now things become really tricky ;) Some Fujitsu ADF scanners (and
> probably also devices from other manufacturers) have a so-called
> "overscan mode". In overscan mode, the scan window is larger than
> the page size; for pixels outside tha page area, you get a
> background colour (you can even select between white and black
> background). This allows to detect and correct skewed scans and to
> check the page size by "analyzing" the image.
>
> So, stating that the scan window should not be larger than the page
> size is not such a good idea...
>
> It might be better if the backend tells the frontend, if scan window
> coordinates are relative to the entire scan area or to the selected
> page size.
>
abel- i tried this a few weeks ago with my 4120C2, and found that i also had to
increase the paper size (lie to the scanner) to get it not to throw an error.
can you check in your personal modification that you actually can set
the br-x wider than paper-width? even if this is so, i bet you cannot
set it very much higher. i think i can deal with this in backend- when
overscan is set, i am going to add 16mm to your scan area dimensions
anyway...
allan
> Abel
>
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to sane-devel-requ...@lists.alioth.debian.org
>
--
"The truth is an offense, but not a sin"
[sane-devel] CVS Won't make.
On Sat, 20 Jan 2007 12:59:49 +0100 Mattias Ellert wrote: > fre 2007-01-19 klockan 20:03 -0600 skrev Robert Price: > > Thanks but I do have the headers installed. It was a new kernel build and > > I > > leave the source files. It apparently isn't looking in the right place. I > > may try to hack the sane code but I suspect the problem is a sympton of > > something more systemic. > > The byteorder.h file is created when configure is run. Unfortunately > someone had checked in a new configure.in without checking in a new > configure, which meant that a fresh checkout did not work without > running autoconf. The autogenerated files in CVS have now been updated. I'm sorry, that one was me. I tried to generate the configure but I had issues.. I think my autoconf was newer than the one originally used with sane. I then asked here for some good soul to generate one for me. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] CVS Won't make.
On Sat, 20 Jan 2007 12:37:25 +0100 Bertrik > I've had the same problems too. > > Isn't it somehow fundamentally wrong to require kernel headers for sane? > Sane is a user-space package not kernel-space. > > I remember seeing the compilation problem only with the epson backend, > but surely other backends must handle byte-order issues. Can't we just > fix the epson backend instead of requiring kernel headers for everyone? That header happens to have the same name of a kernel header, but it is not a kernel header at all. It's purpose is to provide portable definitions for endiannes conversion. theorically, we should fix all the backends to use that header. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Well known option consensus
Allan, >> It might be better if the backend tells the frontend, if scan window >> coordinates are relative to the entire scan area or to the selected >> page size. >> > > abel- i tried this a few weeks ago with my 4120C2, and found that i also > had to > increase the paper size (lie to the scanner) to get it not to throw an > error. > > can you check in your personal modification that you actually can set > the br-x wider than paper-width? even if this is so, i bet you cannot > set it very much higher. i think i can deal with this in backend- when > overscan is set, i am going to add 16mm to your scan area dimensions > anyway... Yes and no... The following settings (for an A5 page, 148.5 mm x 210 mm) [fujitsu] xres=300, tlx=0, brx=8512, pw=6993, maxx=10624 [fujitsu] yres=300, tly=0, bry=11435, ph=9923, maxy=40800 I get the "background pixels" at the top, at the right and at the bottom of the image, but not on the left. So I can set the image width larger than the page width, but in order to get "background pixels" on the left side, the page width value must be increased. But back to the problem I have/had with Etienne's suggstion for the "relations" between page size and scan window coordinates: It does not make much sense to allow to set a scan window in overscan mode: The backend should calculate the scan window settings automatically from the page size, and disable the options tl-x, tl-y, br-x, br-y. (Actually, Eikazo does that -- but I think this should be done by the backend...) Abel
[sane-devel] infrared dust removal algorithm
wouldnt the method be the same as for any other monochrome image? assume your IR is monochromatic. On 1/21/07, Alessandro Zummo wrote: > while working with infrared support I just noticed there > seems to be no available algorithm for dust removal... > > anyone can point to some source code or wants to write one? :)
[sane-devel] sane_read: Invalid argument on Epson Perfection 1640SU
> Unfortunately, I don't. However, the fact that the backend gets a > fatal error immediately after it has re-initialised the device might > indicate there is something wrong with the device. Maybe the lock is > on? Does it work on that other OS (assuming you have access so you > can check)? > > Hope this helps, It certainly did! This problem may very well be the simplest I've come across during my adventures in old hardware. As you suggested. The transport lock was on. That was embarrasing... ;-) Well I'm happy now and I'm going to take this scanner through its loops this afternoon, thank you very much! As for the other OS, well, I use it at work but not at home... Maybe the Windows driver would have suggested checking the lock, but, thats what a community is for, right. Have a nice day, /Henrik
[sane-devel] Well known option consensus
Hi, > But back to the problem I have/had with Etienne's suggstion for the > "relations" between page size and scan window coordinates: It does > not make much sense to allow to set a scan window in overscan mode: > The backend should calculate the scan window settings automatically > from the page size, and disable the options tl-x, tl-y, br-x, br-y. No ! If a user want to scan only a portion of the paper, he must be able to set scan area, but as long as there is no scan surface, we use paper size as scan surface. That make sense ! ?tienne. -- Verso l'Alto ! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070122/14116d8f/attachment.pgp From kitno...@gmail.com Mon Jan 22 14:43:25 2007 From: kitno...@gmail.com (m. allan noah) Date: Mon Jan 22 14:50:42 2007 Subject: [sane-devel] Well known option consensus In-Reply-To: <1169466263.5734.1.camel@thilivren> References: <1169400182.5609.23.camel@thilivren> <45b4083a.7070...@gmx.net> <97246d0e0701211646s24e11ee5o7f0e2e397b45e...@mail.gmail.com> <45b41a2c.9000...@gmx.net> <1169466263.5734.1.camel@thilivren> Message-ID: <97246d0e0701220543t16978099jed1efc3934e0b...@mail.gmail.com> On 1/22/07, ?tienne Bersac wrote: > Hi, > > > But back to the problem I have/had with Etienne's suggstion for the > > "relations" between page size and scan window coordinates: It does > > not make much sense to allow to set a scan window in overscan mode: > > The backend should calculate the scan window settings automatically > > from the page size, and disable the options tl-x, tl-y, br-x, br-y. > > No ! If a user want to scan only a portion of the paper, he must be able > to set scan area, but as long as there is no scan surface, we use paper > size as scan surface. That make sense ! you missed the point here. we are talking about an overscan option, which causes the scanner to add space all around the scan, such that the back- ground shows thru. but i think a person might want to overscan and still have only a small area of the page (one of the corners?) i think i can work this out, and still be compatible with the text of our suggestion. allan -- "The truth is an offense, but not a sin"
[sane-devel] failing make sane-backends-1.0.18; sanei_scsi question]
Hello,
first of all: I didn't follow the whole thread because I thought
that a "failing make" is not of interest for me.
On Jan 19 21:00 Gerhard Jaeger wrote (shortened):
> On Friday 19 January 2007 15:31, Johannes Meixner wrote:
> > On Jan 19 15:00 Julien Michielsen wrote (shortened):
> > > sanei_scsi.c:1276: error: 'HZ' undeclared (first use in this function)
> >
> > This patch replaces the fixed HZ compile-time value (which is
> > no longer supported by new glibc) by the more correct
> > sysconf(_SC_CLK_TCK) runtime value because a fixed HZ compile-time
> > value may be wrong in the running system if the runtime system
> > is not exactly the same as the compile-time system:
>
> That's what I've expected. So I think the patch I've sent
> earlier today should fix that issue.
I assume you mean the patch
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070119/1f4a7757/sanei_scsi-HZ.bin
in this mail from you
http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018479.html
-
--- sanei/sanei_scsi.c 22 Nov 2005 21:17:20 - 1.58
+++ sanei/sanei_scsi.c 19 Jan 2007 07:10:30 -
@@ -281,6 +281,20 @@ static char lastrcmd[16]; /* hold comman
# define MAX_DATA (32*1024)
#endif
+#ifdef SG_SET_TIMEOUT
+# ifdef _SC_CLK_TCK
+# define GNU_HZ sysconf(_SC_CLK_TCK)
+# else
+# ifdef HZ
+# define GNU_HZ HZ
+# else
+# ifdef CLOCKS_PER_SEC
+#define GNU_HZ CLOCKS_PER_SEC
+# endif
+# endif
+# endif
+#endif
+
/* default timeout value: 120 seconds */
static int sane_scsicmd_timeout = 120;
int sanei_scsi_max_request_size = MAX_DATA;
@@ -1273,7 +1287,7 @@ sanei_scsi_open (const char *dev, int *f
disconnect... ;-( */
{
int timeout;
-timeout = sane_scsicmd_timeout * HZ;
+timeout = sane_scsicmd_timeout * GNU_HZ;
ioctl (fd, SG_SET_TIMEOUT, &timeout);
}
#endif
-
sane-backends-1.0.18 builds with this patch for the released
openSUSE 10.2 and for openSUSE "factory" (i.e. the current
development version) but at the moment I didn't test older
Suse Linux versions.
Regarding resmgr:
See what I wrote here
http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018351.html
- disable-resmgr-support.patch disables the resmgr support in SANE
which is no longer needed in SANE because resmgr works now
outside of SANE via ACLs for the scanner device nodes.
And this is my disable-resmgr-support.patch
(some lines are wrapped here only by the mail software):
--- configure.in.orig 2006-07-03 00:21:42.0 +0200
+++ configure.in2006-09-11 10:47:29.0 +0200
@@ -131,15 +131,21 @@ AC_CHECK_HEADERS([io/cam/cam.h],,,[#incl
SANE_CHECK_MISSING_HEADERS
-AC_CHECK_HEADER(resmgr.h,[
- AC_CHECK_LIB(
- resmgr,
- rsm_open_device,[
- AC_DEFINE(HAVE_RESMGR,1,[define if you have
the resmgr library])
- LIBS="$LIBS -lresmgr"
- ]
- )
-])
+# Since Suse Linux 10.0 resmgr installs ACLs on device nodes.
+# Therefore there is no need to patch applications with special resmgr
+# support anymore.
+# As the "rsm_open_device" calls in sanei_scsi.c and sanei_usb.c
+# are optionally via "ifdef HAVE_RESMGR" with fallback "open" calls,
+# the special resmgr support is not removed but only disabled here:
+#AC_CHECK_HEADER(resmgr.h,[
+# AC_CHECK_LIB(
+# resmgr,
+# rsm_open_device,[
+# AC_DEFINE(HAVE_RESMGR,1,[define if you have
the resmgr library])
+# LIBS="$LIBS -lresmgr"
+# ]
+# )
+#])
AC_CHECK_HEADER(usbcalls.h,[
AC_DEFINE(HAVE_USBCALLS,1,[define if you have
the usbcalls library])
By the way:
Since there is no longer the need to have resmgr support compiled
into the software, I like to recommend resmgr as a well working
well seperated tool for certain kind of permission management.
When you do permission management via usual UNIX groups
(e.g. a group "scanner" for those users who should have
access to scanners), it is difficult (or impossible)
to set permissions depending on how a user is logged in
(either directly at the system via console or graphical login
or from remote e.g. via ssh).
Usually you would like to grant access to local connected scanners
(like USB and SCSI scanners) if an only if a user is logged in
directly at the system (but not for remote users).
This kind of permission management is supported by resmgr.
This is why we use resmgr and not usual UNIX groups.
Kind Regards
Johannes M
[sane-devel] Problem with my Canon LIDE25
Hi, I have the problem, that my scanner does not go back to the startposition and stop working. After a next scan under windows it does work again. Does anybody have a hint. The newest sane and plustek-drivers are installed. Regards Marc
[sane-devel] Well known option consensus
m. allan noah wrote: >> > But back to the problem I have/had with Etienne's suggstion for the >> > "relations" between page size and scan window coordinates: It does >> > not make much sense to allow to set a scan window in overscan mode: >> > The backend should calculate the scan window settings automatically >> > from the page size, and disable the options tl-x, tl-y, br-x, br-y. >> >> No ! If a user want to scan only a portion of the paper, he must be able >> to set scan area, but as long as there is no scan surface, we use paper >> size as scan surface. That make sense ! > > you missed the point here. we are talking about an overscan option, which > causes the scanner to add space all around the scan, such that the back- > ground shows thru. > > but i think a person might want to overscan and still have only a > small area of the page (one of the corners?) i think i can work this > out, and still be compatible with the text of our suggestion. Since the "level" of page size and skew detection is quite low in the scanners we're talking about, I think a backend does not need to do much here: In overscan mode, the backend simply returns the image of the document surrounded by "easily distinguishable", typically "dark" pixels; it is up to the frontend to detect the page borders and rotation angle. All this does not mean that the frontend cannot let the user select a smaller scan window within the page area -- but the clipping of the image must be done by the frontend. Abel
[sane-devel] Well known option consensus
On 1/22/07, abel deuring wrote: > m. allan noah wrote: > > >> > But back to the problem I have/had with Etienne's suggstion for the > >> > "relations" between page size and scan window coordinates: It does > >> > not make much sense to allow to set a scan window in overscan mode: > >> > The backend should calculate the scan window settings automatically > >> > from the page size, and disable the options tl-x, tl-y, br-x, br-y. > >> > >> No ! If a user want to scan only a portion of the paper, he must be able > >> to set scan area, but as long as there is no scan surface, we use paper > >> size as scan surface. That make sense ! > > > > you missed the point here. we are talking about an overscan option, which > > causes the scanner to add space all around the scan, such that the back- > > ground shows thru. > > > > but i think a person might want to overscan and still have only a > > small area of the page (one of the corners?) i think i can work this > > out, and still be compatible with the text of our suggestion. > > Since the "level" of page size and skew detection is quite low in > the scanners we're talking about, I think a backend does not need to > do much here: In overscan mode, the backend simply returns the image > of the document surrounded by "easily distinguishable", typically > "dark" pixels; it is up to the frontend to detect the page borders > and rotation angle. > > All this does not mean that the frontend cannot let the user select > a smaller scan window within the page area -- but the clipping of > the image must be done by the frontend. > i agree completely other than the last sentence. it should be possible for the backend to let the user select overscan mode, and then adjust the scan area/papersize as needed to set tl-x/y 0,0 to the black area 16mm outside of the paper. i dont think this violates the spirit of the standard proposal, and it keeps overscan mode as similar to the other modes as possible. in fact, i think this is the right thing to do in sane1, given recent user complaints on this mailing list. allan -- "The truth is an offense, but not a sin"
[sane-devel] Well known option consensus
m. allan noah wrote: >> All this does not mean that the frontend cannot let the user select >> a smaller scan window within the page area -- but the clipping of >> the image must be done by the frontend. >> > > i agree completely other than the last sentence. it should be possible > for the backend > to let the user select overscan mode, and then adjust the scan > area/papersize as needed > to set tl-x/y 0,0 to the black area 16mm outside of the paper. i dont > think this violates the > spirit of the standard proposal, and it keeps overscan mode as similar > to the other modes > as possible. in fact, i think this is the right thing to do in sane1, > given recent user complaints on this mailing list. OK, misunderstanding cleared ;) Perhaps we're beginning to discuss a far too special feature -- but I would maintain nevertheless that it makes sense for a backend to simply disable tl-x, br-x, tl-y, br-y in overscan mode, and that to set the scan area automatically to a value that is somewhat larger than the page size. After all, this would allow the backend to fix the weird behaviour of the fi4210/5120 that the parameter page width must be set to a "wrong" value: real page width + 32mm in overscan mode, if one wants the dark background on the left side of the scan area. Abel
[sane-devel] Well known option consensus
On 1/22/07, abel deuring wrote: > m. allan noah wrote: > > >> All this does not mean that the frontend cannot let the user select > >> a smaller scan window within the page area -- but the clipping of > >> the image must be done by the frontend. > >> > > > > i agree completely other than the last sentence. it should be possible > > for the backend > > to let the user select overscan mode, and then adjust the scan > > area/papersize as needed > > to set tl-x/y 0,0 to the black area 16mm outside of the paper. i dont > > think this violates the > > spirit of the standard proposal, and it keeps overscan mode as similar > > to the other modes > > as possible. in fact, i think this is the right thing to do in sane1, > > given recent user complaints on this mailing list. > > OK, misunderstanding cleared ;) > > Perhaps we're beginning to discuss a far too special feature -- but > I would maintain nevertheless that it makes sense for a backend to > simply disable tl-x, br-x, tl-y, br-y in overscan mode, we agree to disagree :) > and that to > set the scan area automatically to a value that is somewhat larger > than the page size. i agree to set the max area to be larger than page size, yes. > After all, this would allow the backend to fix > the weird behaviour of the fi4210/5120 that the parameter page width > must be set to a "wrong" value: real page width + 32mm in overscan > mode, if one wants the dark background on the left side of the scan > area. i can fix that even without forcing the user to do full-page scans. i just tack the 32mm on when i build the command block if you are in overscan mode. i need more docs and beta testers to see if this page-width change is needed with more expensive scanners. this discusion has become too specialized, but it does point out the concept that we were trying to capture in our 'pagesize' well-known option suggestion: the backend should endeavor to limit the scan area of an adf to values which are sensible for the options being used, including, but not limited to, paper size. allan -- "The truth is an offense, but not a sin"
[sane-devel] Problem with my Canon LIDE25
On Mon, Jan 22, 2007 at 04:12:03PM +0100, Marc Hansen wrote: > Hi, > I have the problem, that my scanner does not go back to the startposition and > stop working. > After a next scan under windows it does work again. > > Does anybody have a hint. The newest sane and plustek-drivers are installed. I have no idea what could be the problem, but my CanoScan LIDE 25 works just fine with debian etch. (I know this isn't particularly helpful, but knowing that at least it *can* would should be helpful.) -- David Roundy Department of Physics Oregon State University
[sane-devel] infrared dust removal algorithm
On Sun, 21 Jan 2007 21:26:15 -0600 "Clarence Risher" wrote: > wouldnt the method be the same as for any other monochrome image? > assume your IR is monochromatic. > > On 1/21/07, Alessandro Zummo wrote: > > while working with infrared support I just noticed there > > seems to be no available algorithm for dust removal... > > > > anyone can point to some source code or wants to write one? :) Yes, it would. I'm just searching for an algo... -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] Pages all white with Cybercom 9352 (mustek_pp) backend
Am Sonntag, 21. Januar 2007 21:47 schrieb Jochen Eisinger: > Hi, > > I'm not sure this is really a CCD scanner. You could try the cis1200 > driver, maybe that helps? > The cis1200 driver worked perfectly. Thanks, Jochen. The documentation however, states the Cybercom 9352 is a 300 dpi CCD, not a 1200dpi CIS scanner. http://www.sane-project.org/sane-mfgs.html#Z-CYBERCOM I think the documentation should be updated to avoid further confusion. Kind regards Jan -- .vbs = Virus Bearing Script?
[sane-devel] [announce] tiffscan 0.2 release
Hello sane devs, the first public release of tiffscan is available at http://sourceforge.net/projects/tiffscan -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] What represents the logo of Sane?
Hello, I have a question: What represents the logo of Sane? When I look the logo I see a phone with an explosion. But, Sane is not a phone... - D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses. -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070122/567f6d81/attachment.html From bobpricem...@hotmail.com Tue Jan 23 00:08:08 2007 From: bobpricem...@hotmail.com (Robert Price) Date: Tue Jan 23 00:22:21 2007 Subject: [sane-devel] Lexmark x1185 Can't Find Home Message-ID: Greetings; Attached is the debug output produced when I try to scan with a Lexmark x1185. The behavior of the machine is that it will make a distressing mechanical buzzing noise and stop. This happens with the release and CVS versions of sane. The scanner works fine on the same computer under Windows XP. I know this problem has been in the bug tracker for a while but I was hoping that posting the debug text here might prompt some ideas. I've attached the entire debug output but the last thing it shows before hanging is: [lexmark] sane_start: handle=0x82508a0 [lexmark] sane_get_parameters: handle=0x82508a0, params=(nil) [lexmark] sane_get_parameters: Data size determined as 3e12a [lexmark] sane_get_parameters: [lexmark] format: SANE_FRAME_RGB [lexmark] last_frame: TRUE [lexmark] lines 177 [lexmark] depth 8 [lexmark] pixels_per_line e2 [lexmark] bytes_per_line 2a6 [lexmark] sanei_lexmark_x1100_search_home_fwd: [lexmark] sanei_lexmark_x1100_search_home_bwd: Killed Any help or speculation, tips, etc. would be greatly appreciated. Thank you. Bob _ Valentines Day -- Shop for gifts that spell L-O-V-E at MSN Shopping http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline -- next part -- [sanei_debug] Setting debug level of lexmark to 128. [lexmark] SANE Lexmark backend version 1.0-0 [lexmark] sane_init: version_code=0xbfede42c [lexmark] attachLexmark: devname=libusb:2:4 [lexmark] sane_get_devices: device_list=0xbfede458, local_only=0 [lexmark] sane_open: devicename="libusb:2:4", handle=0xbfee0284 [lexmark] sane_open: devname from list: libusb:2:4 [lexmark] init_options: lexmark_device = 0x82508a0 [lexmark] sanei_lexmark_x1100_open_device: devnum=0 [lexmark] sane_control_option: handle=0x82508a0, opt=0, act=0, val=0x80ce814, info=(nil) [lexmark] Option value = 6 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 1 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 1 [lexmark] sane_control_option: handle=0x82508a0, opt=1, act=0, val=0x8284200, info=(nil) [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 2 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 2 [lexmark] sane_control_option: handle=0x82508a0, opt=2, act=0, val=0xbfee007c, info=(nil) [lexmark] Option value = 150 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 3 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 4 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 4 [lexmark] sane_control_option: handle=0x82508a0, opt=4, act=0, val=0x8284200, info=(nil) [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 5 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 1 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 1 [lexmark] sane_control_option: handle=0x82508a0, opt=1, act=0, val=0x8299b68, info=(nil) [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 2 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 2 [lexmark] sane_control_option: handle=0x82508a0, opt=2, act=0, val=0xbfedfed0, info=(nil) [lexmark] Option value = 150 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 2 [lexmark] sane_get_parameters: handle=0x82508a0, params=0x80ce930 [lexmark] sane_get_parameters: Data size determined as f7314 [lexmark] sane_get_parameters: [lexmark] format: SANE_FRAME_RGB [lexmark] last_frame: TRUE [lexmark] lines 2ee [lexmark] depth 8 [lexmark] pixels_per_line 1c2 [lexmark] bytes_per_line 546 [lexmark] sane_get_parameters: handle=0x82508a0, params=0x80ce930 [lexmark] sane_get_parameters: Data size determined as f7314 [lexmark] sane_get_parameters: [lexmark] format: SANE_FRAME_RGB [lexmark] last_frame: TRUE [lexmark] lines 2ee [lexmark] depth 8 [lexmark] pixels_per_line 1c2 [lexmark] bytes_per_line 546 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 1 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 2 [lexmark] sane_get_option_descriptor: handle=0x82508a0, option = 4 [lexmark] sane_
