[sane-devel] Re: sane-devel digest, Vol 1 #266 - 5 msgs
Pramathesh Ambasta schrieb: > Thanks for your response. > Yes the sg driver is loaded. sane-find-scanner reports no scanner is > found whether run as root or as ordinary user. > cat /proc/scsi/scsi reports only the Samsung CD-RW drive attached to the > system. > When scannerdrake searches for a scanner, the scanner makes some noise, > it seems like its lamp is moving - but nothing happens after that. > If I manually configure the scanner in scannerdrake, that does not work > out either. This sounds like a problem with the hardware or perhaps with the Linux SCSI system. I don't know how scannerdrake works, so I can't comment on it, but I assume that it simply tries to load drivers for detected SCSI adapters and then looks, which SCSI devices are connected to an adapter. /var/log/messages should contain error messages produced by modprobe or insmod (one of them are probably called by scannerdrake). Moreover, you could try to load the driver for the adapter manually (modprobe , e.g. modprobe aic7xxx) and see, what is written to /var/log/messages. And as a simple check, make sure that the SCSI cabling is correct: no bent pins in the connectors, for example. Abel
[sane-devel] fujitsu duplex scan with usb
m. allan noah wrote: > most scsi commands that use a data block after the command block (mode > select, set window, scan) are formatted differently when sent via usb. the > command block is sent first, in a single urb, padded to 31 bytes with null > bytes. then the data block(s) are sent in another urb, not padded. > > the existing fujitsu code is very scsi specific, and only uses one buffer > for scsi cmd/data to the do_cmd() function. this means that the caller has > to either pad the single buffer with just the right number of 0's in the > middle of the buffer, or the do_usb_cmd() function will have to break the > buffer inhalf, and pad the data itself. It's perhaps reasonable to call sanei_scsi_cmd2 instead of sanei_scsi_cmd. The former function needs/wants different buffers for the CDB and the write data. All OS specific SCSI interfaces (except the old Linux SG interface) use different buffers anyway, and in many cases the backends have also different buffers for CDB and data, so I expect that you can also avoid a few memcpy calls. And inside sanei_scsi, the function sanei_scsi_cmd tries to guess the CDB size and then calls sanei_scsi_cmd2 anyway. Abel
[sane-devel] Problem with sane, HP5200 and libusb
Hello Peter, I installed the CVS version of sane-backends and my scanner is working again. Many Thanks. Some times I still get this "Error on Device I/O" message, but on a second try the scanner works in most cases. Good work! Please let me know if I can help you, to get this thing kind of bullet proof. If you could tell me what to do, I could provide you with all kinds of logfiles and stuff to encircle this remaining little bug. At least I have to say thank you again. You made one more happy linux user! Greetings Stefan Am Mi, den 31.03.2004 schrieb Peter Kirchgessner um 18:46: > Hi Stefan, > > please try again the hp-backend from current CVS. I have made some > changes for the USB-devices. Maybe this helps you too. > > Sincerely > > Peter > > Stefan Seubert schrieb: > > My HP5200C scanner used to work perfectly with the scanner.o kernel > > module. Now I upgraded to kernel 2.6.3 and have to use libusb. Everytime > > I try to scan with scanimage the output looks like the following: > > > > P4 > > # SANE data follows > > 2550 3507 > > scanimage: sane_read: Error during device I/O > > > > > > On tty1 I get some of the following messages: > > > > cannot get config descriptor: Connection timed out > > > > And dmesg shows me some of these lines: > > > > usb 5-2: control timeout on ep0in > > usbfs: USBDEVFS_CONTROL failed cmd usbmodules dev 2 rqt 128 rq 6 len 18 > > ret -110 > > > > The Scanner is detectet by "scanimage -L" as "device `hp:libusb:005:002' > > is a Hewlett-Packard ScanJet 5200C flatbed scanner". > > > > The Scanner makes some noise like it is being initialized but it's not > > scanning. I tried sane-backends 1.0.13 and the cvs snapshot from > > 2004-03-04 with the same results. I use libusb-0.1.8 and I have also > > tried 0.1.7. > > > > I don't know if this problem is related to sane or libusb. It would be > > nice if someone here could help me with this. > > > > Thanks > > Stefan > > > > >
[sane-devel] sane-find-scanner and mustek parallel port devices
This is a multi-part message in MIME format.
--070004080404080406040306
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
I just wrote a short patch to sane-find-scanner which detects mustek
parallel port devices. With sanei_pa4s2 it's possible to get a list of
possible ports. All the patch does is trying to open those ports using
the sanei_pa4s2 - the sanei_pa4s2 contains the whole low-level stuff, so
no device dependant code is included in sane-find-scanner.
In order to avoid problems with parallel port printers or other hardware
if no scanner is present, you have to give the switch -p to
sane-find-scanner if you want your scanner detected.
Example:
# sane-find-scanner -p -q
found possible Mustek parallel port scanner at "parport0"
Any comments on this?
kind regards
-- jochen
--070004080404080406040306
Content-Type: text/plain;
name="sane-find-scanner.c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="sane-find-scanner.c.patch"
--- ./tools/sane-find-scanner.c.orig2004-04-06 20:23:43.0 +0200
+++ ./tools/sane-find-scanner.c 2004-04-06 20:23:47.0 +0200
@@ -44,6 +44,7 @@
#include "../include/sane/sanei.h"
#include "../include/sane/sanei_scsi.h"
#include "../include/sane/sanei_usb.h"
+#include "../include/sane/sanei_pa4s2.h"
#ifndef PATH_MAX
# define PATH_MAX 1024
@@ -90,6 +91,7 @@
fprintf (stderr, "\t-q: be quiet (print only devices, no comments)\n");
fprintf (stderr, "\t-f: force opening devname as SCSI even if it looks "
"like USB\n");
+ fprintf (stderr, "\t-p: enable scannig for parallel port devices\n");
if (msg)
fprintf (stderr, "\t%s\n", msg);
}
@@ -781,10 +783,87 @@
}
#endif
+static int
+check_mustek_pp_device (void)
+{
+ const char **devices;
+ int ctr = 0, found = 0, scsi = 0;
+
+ if (verbose > 1)
+printf ("searching for Mustek parallel port scanners:\n");
+
+ devices = sanei_pa4s2_devices ();
+
+ while (devices[ctr] != NULL) {
+int fd;
+SANE_Status result;
+
+/* ordinary parallel port scanner type */
+if (verbose > 1)
+ printf ("checking %s...", devices[ctr]);
+
+result = sanei_pa4s2_open (devices[ctr], &fd);
+
+if (verbose > 1)
+ {
+if (result != 0)
+ printf (" failed to open (%s)\n", sane_strstatus (result));
+else
+ printf (" open ok\n");
+ }
+
+if (result == 0) {
+ printf ("found possible Mustek parallel port scanner at \"%s\"\n",
+ devices[ctr]);
+ found++;
+ sanei_pa4s2_close(fd);
+}
+
+/* trying scsi over pp devices */
+if (verbose > 1)
+ printf ("checking %s (SCSI emulation)...", devices[ctr]);
+
+result = sanei_pa4s2_scsi_pp_open (devices[ctr], &fd);
+
+if (verbose > 1)
+ {
+if (result != 0)
+ printf (" failed to open (%s)\n", sane_strstatus (result));
+else
+ printf (" open ok\n");
+ }
+
+if (result == 0) {
+ printf ("found possible Mustek SCSI over PP scanner at \"%s\"\n",
+ devices[ctr]);
+ scsi++;
+ sanei_pa4s2_close(fd);
+}
+
+ctr++;
+ }
+
+ free(devices);
+
+ if (found > 0 && verbose > 0)
+printf("\n # Your Mustek parallel port scanner was detected. It may or\n"
+ " # may not be supported by SANE. Please read the
sane-mustek_pp\n"
+ " # man-page for setup instructions.\n");
+
+ if (scsi > 0 && verbose > 0)
+printf("\n # Your Mustek parallel port scanner was detected. It may or\n"
+ " # may not be supported by SANE. Please read the
sane-mustek_pp\n"
+ " # man-page for setup instructions.\n");
+
+ return (found > 0 || scsi > 0);
+
+}
+
int
main (int argc, char **argv)
{
char **dev_list, **usb_dev_list, *dev_name, **ap;
+ int enable_pp_checks = SANE_FALSE;
prog_name = strrchr (argv[0], '/');
if (prog_name)
@@ -815,6 +894,10 @@
force = SANE_TRUE;
break;
+ case 'p':
+ enable_pp_checks = SANE_TRUE;
+ break;
+
default:
printf ("unknown option: -%c, try -h for help\n", (*ap)[1]);
exit (0);
@@ -1218,9 +1301,19 @@
"make sure that\n # you have loaded a driver for your USB host "
"controller and have installed a\n # kernel scanner module.\n");
}
+ if (enable_pp_checks == SANE_TRUE)
+{
+ if (!check_mustek_pp_device() && verbose > 0)
+printf ("\n # No Mustek parallel port scanners found. If you expected"
+" something\n # different, make sure the scanner is correctly"
+ " connected to your computer\n # and you have apropriate"
+ " access rights.\n");
+}
+ else if (verbose > 0)
+printf ("\n # Not checking for parallel port scanners.\n");
if (verbose > 0)
-printf ("\n # Scanners connected to the parallel port or other "
- "proprietary ports can't be\n # det
[sane-devel] fujitsu duplex scan with usb
Hi, On Tue, Apr 06, 2004 at 09:06:12AM -0400, m. allan noah wrote: > agreed, just committed an updated version. please check. but i get this > error: henning? > > Checking in doc/descriptions/fujitsu.desc; > /cvsroot/sane/sane-backends/doc/descriptions/fujitsu.desc,v <-- > fujitsu.desc > new revision: 1.13; previous revision: 1.12 > done > U descriptions/fujitsu.desc > /bin/sh: sane-backends.html: Permission denied > make: *** [sane-backends.html] Error 1 That should be fixed now. After the alioth move I accidently did a "make" without setting umask accordingly. Bye, Henning
[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3
Gerhard Jaeger wrote: > Hi Mattias, > > how is the current state of the OSX support within the Plustek backend. > Have you any patches? I'm currently very short of time, but I'd like to do > what's necessary to not forgot your work. > > I've not forgotten the pending sanei_thread stuff! At the moment I have 4 open bug reports in the bug reporter. 300602, 300617, 300618, 300620 The first one is what I think you mean when you say "the pending sanei_thread stuff". I'm not sure if it is possible to fix this in the short term in a good way. The patch attached to the bug report is really just a temporary workaround (and was applied when I built the latest binary package). A slightly better proposal for a fix is suggested in a comment I made to the original bug report, but that one requires some coordination between the backend maintainers to implement. And there possibly are other ways to do it as well which might be better. This problem probably does not affect the plustek backend to a large extent, since the plustek backend only calls sanei_thread_kill (which is the call that is broken due to this problem in those backends that - like the plustek backend - block SIGUSR2) if the SIGUSR1 signal sent by the backend fails to kill the reader thread within 10 s. Some other backends rely more on this call to work. The second and third ones are minor fixes to sanei_thread that have not been seen to cause problems, but I noticed them when I was trying to figure out what was going on in the plustek backend. The fourth one is the specific patch to the plustek backend I just submitted. Without this one the plustek backend hangs on the read call in sane_read at the end of a scan. The only patch that I have that I have not yet submitted to the bug reporter is totally unrelated to the plustek backend. It is a possible but yet untested fix to a timeout problem in the sm3600 backend. I'm waiting to hear from the reporter of the problem if the patch works before submitting it, but if someone else want to try it I can send it to that someone if they get in touch with me. Mattias -- mattias.ell...@tsl.uu.se tel: +46 18 471 32 58 http://www.tsl.uu.se/~ellert/ fax: +46 18 471 35 13
[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3
Hi Mattias, how is the current state of the OSX support within the Plustek backend. Have you any patches? I'm currently very short of time, but I'd like to do what's necessary to not forgot your work. I've not forgotten the pending sanei_thread stuff! Ciao, Gerhard On Tuesday 06 April 2004 15:12, Mattias Ellert wrote: > Onizuka wrote: > > Great! With this patch it works!! > > Just in time for the 1.0.14 :-) > > Thank you! > > > > Gianfranco > > I have created a bug report so that it won't be forgotten: > > https://alioth.debian.org/tracker/index.php?func=detail&aid=300620&group_id >=1308&atid=410366 > > Mattias >
[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3
Onizuka wrote: > > Great! With this patch it works!! > Just in time for the 1.0.14 :-) > Thank you! > > Gianfranco I have created a bug report so that it won't be forgotten: https://alioth.debian.org/tracker/index.php?func=detail&aid=300620&group_id=1308&atid=410366 Mattias -- mattias.ell...@tsl.uu.se tel: +46 18 471 32 58 http://www.tsl.uu.se/~ellert/ fax: +46 18 471 35 13
[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3
>Try this patch instead. It only closes the write end of the pipe, >and not both as the previous one. > > Mattias > > >diff -ur sane-backends.orig/backend/plustek.c sane-backends/backend/plustek.c >--- sane-backends.orig/backend/plustek.c2004-01-09 >15:24:30.0 +0100 >+++ sane-backends/backend/plustek.c 2004-04-06 11:54:39.0 +0200 >@@ -443,6 +443,9 @@ > return SANE_STATUS_IO_ERROR; > } > >+ close( scanner->w_pipe ); >+ scanner->w_pipe = -1; >+ > DBG( _DBG_PROC, "reader_process: finished reading data\n" ); > return SANE_STATUS_GOOD; > } Great! With this patch it works!! Just in time for the 1.0.14 :-) Thank you! Gianfranco P.S. I dint know why but the direct reply got this error... - These recipients of your message have been processed by the mail server: mattias.ell...@tsl.uu.se; Failed; 5.1.1 (bad destination mailbox address) Remote MTA smtp1.uu.se: SMTP diagnostic: 550 Service unavailable; SPAM Alert; Client host [193.70.192.33] blocked by bl.spamcop.net
[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3
This is a multi-part message in MIME format. --060709010008070407050805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Onizuka wrote: > > Hi! > Thank you for the help! > After patching and rebuilding plustek.c scanimage hangs no more... so I > guess one problem is solved :-) > Now the problem is an I/O error: > > XS206:~ onizuka$ scanimage > prova.pnm > scanimage: sane_read: Error during device I/O > XS206:~ onizuka$ > > I ran again scanimage with debug set to 255 and the output > (gzip/uuencoded) is below > > Gianfranco Try this patch instead. It only closes the write end of the pipe, and not both as the previous one. Mattias diff -ur sane-backends.orig/backend/plustek.c sane-backends/backend/plustek.c --- sane-backends.orig/backend/plustek.c2004-01-09 15:24:30.0 +0100 +++ sane-backends/backend/plustek.c 2004-04-06 11:54:39.0 +0200 @@ -443,6 +443,9 @@ return SANE_STATUS_IO_ERROR; } + close( scanner->w_pipe ); + scanner->w_pipe = -1; + DBG( _DBG_PROC, "reader_process: finished reading data\n" ); return SANE_STATUS_GOOD; } -- mattias.ell...@tsl.uu.se tel: +46 18 471 32 58 http://www.tsl.uu.se/~ellert/ fax: +46 18 471 35 13 --060709010008070407050805 Content-Type: text/plain; name="sane-plustek.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sane-plustek.patch" diff -ur sane-backends.orig/backend/plustek.c sane-backends/backend/plustek.c --- sane-backends.orig/backend/plustek.c2004-01-09 15:24:30.0 +0100 +++ sane-backends/backend/plustek.c 2004-04-06 11:54:39.0 +0200 @@ -443,6 +443,9 @@ return SANE_STATUS_IO_ERROR; } + close( scanner->w_pipe ); + scanner->w_pipe = -1; + DBG( _DBG_PROC, "reader_process: finished reading data\n" ); return SANE_STATUS_GOOD; } --060709010008070407050805--
[sane-devel] fujitsu duplex scan with usb
Thanks, I think the status of the fujitsu scanners with USB interface should not be reported 'good'. Oliver Am Montag 05 April 2004 22:23 schrieb m. allan noah: > so, i tracked it down using usb snoopy in windows. the problem is simple > to explain, but harder to fix: > > most scsi commands that use a data block after the command block (mode > select, set window, scan) are formatted differently when sent via usb. the > command block is sent first, in a single urb, padded to 31 bytes with null > bytes. then the data block(s) are sent in another urb, not padded. > > the existing fujitsu code is very scsi specific, and only uses one buffer > for scsi cmd/data to the do_cmd() function. this means that the caller has > to either pad the single buffer with just the right number of 0's in the > middle of the buffer, or the do_usb_cmd() function will have to break the > buffer inhalf, and pad the data itself. > > for an example, see fujitsu_set_sleep_mode(). > > you see this problem only with scanning duplex or back side because the > code at line 3112 (talks about opcode==SCAN) is wrong. it should take the > last one or two bytes and send as adifferent urb, rather than assuming 00. > > i have started a new version of the fujitsu backend, which uses a command > and a data buffer to do_cmd() but have been far too busy to make much > headway. take a shot if you would like.
[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3
>Hi! > >I have been looking into this issue last weekend. A backtrace shows >that the process hangs on the read call in sane_read in the plustek >backend: >It should be possible to fix this by closing the filedescriptors at >the end of the reader thread, e.g. by applying the following patch. >(Has not been tested yet, but please do.) If it works it should go >into the CVS. > > Mattias Hi! Thank you for the help! After patching and rebuilding plustek.c scanimage hangs no more... so I guess one problem is solved :-) Now the problem is an I/O error: XS206:~ onizuka$ scanimage > prova.pnm scanimage: sane_read: Error during device I/O XS206:~ onizuka$ I ran again scanimage with debug set to 255 and the output (gzip/uuencoded) is below Gianfranco XS206:~ onizuka$ uuencode -m debug.sane.gz debug.sane.gz begin-base64 644 debug.sane.gz H4sICDNfckAAA2RlYnVnLnNhbmUA7F17b9u4sv//fgoWC9x1Frajt+VgXSBN0m7uyQtxum1RLAJZ ohLd2pKvJCfNwfnwd4aUbFKWZDWbNPVWRh+WOBwOh8Phb0Y09TlxQhpce3SyuPmLjGmaBuENYZdk Su/olEQ+mU8XSUq/kDQimmn2/+tzduMvcpGVTBz3Cw098qfSNwY9VemSuROnWBf597LihKh9pa/q PfcuEZi8/iXn0xvvnx2RNxkzNwr94GYRO2kQhcQPpvR3udbbKCaLhJL7IL0lJ6dDW1d3tV0dpEmo R96P35DEdcKQxolcUboq8KSOewv9vwtcSkJKQWYnBU04SUrS+4hMg5Ame4U6PfJ5kUz+IncgdRT3 jg+JA+LP48hbuClcrpFn/Pl/oTMrdizo0z7xoXe5fjvKV2XwRt8h769UbVe1djWD3VPUwU6hLheF 0xNOUqDIWt+F/3eBONNRgSgq3shqTYMJ1NmbTCZ7nucVaO5vaUwJlJEgIektfF0k4WI2oTHTCFRg d3P1spICi5nzhZJkAWzSW9D8Q7RgYxyTWweGwnVpkqAd7oJ23V1gjz3YhRZ316QpMHY8L0BDcqbT B2RLoNskmVM38B9IEs0oieZYnhT75MSzxbxLpue+fx4ehR58dWZzuKptDm3TWaSRR1PqMgOGXpQN 1SMGZ22oSBLM5tOHzezXawY+U8a9E6bEyfQRuLkYkwUbAlD+HYxXRAKPOsSZRHAbBrJc9BD6jJyx Hs5ObjHdTEaS0DSfKPXTpLEho5pru3l2fnW0VxgNMNDE8WmXgFkFKQrKLTYI/Qhv3ERpgQv/+HE0 Y4TMvSwmyQMQzPrkmOnx1xj7j+zQja6riH8kSbpMUafvx1dcy06agguiHrd/3sVyLtnsAEF68yhO u8sZwxllY0m9fr/f1P+tmUxIv+ZCcB1JsguE0IhIXO1hiybIJx3zdqjWeQz1o0XC9EvDNH6orZ6A 7weHjTMSVhufOH4KvuLr169gZ27SJQrxgsSZTLPR9amTgm+RmHAJ8klNdEURiw+pG3k4mBnZ67LJ X+oyyJzGQeSBRaEsESx/KM6MOtBbmEqcqEySrLpq1spRUr8gRt4YrF5gDih3L0mh/wlZhGm0QCPr MmvNCTNlRkXXRqA9XMev3WmUlCsvd45ErVdeTlcjd4WBgNNP76nzhc/SmXMDFp4CyADbT5hjL9Tr fNi/PDs+e7eHFWL6K1N6EIJ5wBJAYicEBqAC98urV692aiXITTOM4hlURZdMnJg6NZWy/oJo0OGP pN6iMqpqBp8aMfhUZwusD9DpBHAZDd2AJmXNpXOngbwZVTWDTfJmVJvkDekNQL+7clGhsIGoGVU1 g02iZlTNzRUFTzIYjUbjOrD+ZRA2SeNgTp7eXklPzWYwrreTRTBNoWYj8xzfOtjfT8Bik4nlpBXj 3pSTQFoxLE05CaTNxydFpd7ROOVTOjexRitFqRI5t7Oc0QZ7KlB/k9wJuPHdmCZpBCjDjZw4kc3L c9IGPslFdHHgTA+BeoOwImlzSdEGnSmz21QWMAbciPHTZiGh/oFQsV5Mmfgbp+qXYD5HZve30bQ4 W+l8s6TIoLmoBepHygqwKAAT8EGXGyQuMxNAvl4UNrBsbO8ttrG5T0jWvDMw0Vwn5rEg2PNiyjIF bNZhc/e3gWw4zUX9wKo2k5fRblqDYjqfOm7uzG8cAHN3znRBEbAuMKRdxFBYVHqF6JkEMfWuGSey ycPllGVcbmJKQ85nA5cVZRmfCfQmE2cDnyVl45Gu6j1iUUTrjRSQEVfrIOfWSA013Fj/lqI1UUYZ s43T2PH+F27kJuVR38EJcOPMZk5mW42U+I5VyD9qv97o8wqVWhTZbWK2qlClRkm4TeyWFcqFcx6+ iduywjetrTTEpZ9cXeyTTghsLnhxFs0mEAFNH4qoKw+b8iGcUIi7AwzJnWQVfWP8xxMLGZRLGcgo 8MoBHJdjswFwOhS3XhtLuubamEF8PyUR4JQ48MAlL0KX582C9KFL3EUMAUQ6fWAqIc6dE0yZ6vy1 jOGppMJulhQ5Gx8kv2YZIHJ8uIepHUNRMBdUqO9MkwhVF8R5kiijVxWg7/CE7w6/VrNrrT6Um0V3 uxfHh2hH/8F/Ml78ijMqQutmnzXT6GRWsfMf8oY68YVzr2rQ0vKKaIacaGBGsPygPMENRJxgQESo hUw2Wwd0c4NdAEVzi8A0HSzQLph2QoUMbm89dV1c6TdnMyuSeEuJ86wiNAVQr5jq2zSvYRQQUjiA 9O8zVl2eN+BPDXhBwtNZxbz+hgQqz9SRDgoF8cPXiQ8fzVTwu7Ij9YV1QXqesSeUi10ke+u9xAwf N1rCysWyfLbGfVamCEVZHimvppriQ5c83ZUV6oqyXsgzOnvkgYo1pQBiD6JUUSUrKE6LZSvs2ydl ZQxqcmlKyxheK5Qtw6lknSeErNdfybL7SqHooboo4VHl9cMeoAChDKLFKo5YVMERi6o4QjBcxRGL KjhiURVHdBgZuMRqUhlbt/PSQhkuwsuKJTyXuKiUZ1ZaxjOvWMJzua7v4aqurHHNytdKGd+8ckld 56G6tNR7C+Uw5WG6XkdzGvKJLU7kfTH53e+LT0IPMDWD/gohHj60mOg99tBCaUKkNiEaNCEyn4yT /mREjXrXSE/Gk6mgESfryZTZhEhpROQ/GdHT6UmrIQKY0+MwqwlRnak0IzJtINLqlbkkspsQDRsQ 1U6EJVGdxpdEdUan+6gCxawdu4zIqiUyJtgcTLs6U8mJVK+aSLUUi1mBVTPAOZFaR6QYQ5/bk1NH 5AxRT5oi6uktT8ZkUDIlr7NtCsAL/mo9Vgvr9NCGJGj8Zx6JjJD5/rBLLpbBxmitIWAaRNeHbA1g AcfX2sK9LE3EY5Nd0Ug4GayCWSj034UgB2VZ7+hhvnMkceOAY3nUy2uJ/nfeal8W7ToIgxTqd/RB l+ux21NLYOqH/besff6x1lXFExj4hDoCMHrghHKa62T/9KI3vtq/ej8W+Ijjfnk0Prq6Oj57B9/e HY+vji7HHVmUvPzqjyNyejw+IMe75yIGze9lz3sZQ2zMsrrM2vDfoeQmhAQo7iRioQvbiwCdEBH+ 7vuExsluFAb/Xnxxdvv43HOX9bF3ZpnK+2v413rfd53p7wX1jmk6hvjmwomBNUiVdMQe/Ub+OLw4 3iNGX9bFb+Qj3B+pGDYgxWid4NOS4DQI4fun0cCUCBCJXwRf6XSMgc3IBhs+AcAM4B2+11EOlRXl EGLW/cP/EWV+/ZpASY/TivJJPN8uplMyTumcPaMdA1rHGcgqkVFmAFIFpB0H/6adi5jCCOwAlaqp fD/TYCgrDTWK+VR3MWWDl8io6zcm/gkNb9LbkaXYWX8uIfw4iKZRPNLXWk6gZWjRHKhoJIaF017D bwP4pk9kdV0ckpFqGQrbbWXAarhTUm7rFt+gpbk7XZaEJ9jIiDWBl4kW07uRJcsyndIwE3kqi9wl /5e6IYxjl9z67EvB0t7R9PTg5F+HwV3g0bhgZsdhSm8yS78KwMj32XTFoSCdlYV1GQf+vaDy7Onl O8TgFx9ODxfpw8GDO6V/BDe3EuUBzwURZEUyaaAdxrM46KfnV+eXvYx3skeAMWoe+gjfrg/fX32C S9WXLettbirIVQPazzAK9l/crFR+OeSXjitVvbh9ePOQ0gRCgBGxikVoI7xIU42BAQNoqhLNVZQ6 U84ATMWQ65+MtKHZhXCe+j4baA0dTgJWSosGd+EsEnoSzALUv8YFprL8fn652Z2w5zYFr47Byg2F qHsu+5sxT7Ww/UzxbC3lkLnyPcJcm+hZWT4BCpi322XeTlxop85NwuLRMsfuxXdsi4gkSSZkkkZz FKqsDO+Dp+nsZLmZEd9A+mWkrNOuN8DzMHtZKmREXguii06abWEBXV3nSd1OlrMZeJiz2SmSYgxI eqQeSgiVuDvjc4eFnzzTSzo40w1laMnz7OAWR2j6Wfmrm2X/tTXXn9OoDWi0BjR6Jc3mFGdRPWyk KiLnep1JMfXPjL/0wQ+Dv2RR3o+xdImyMrP+WwisxldhW
[sane-devel] fujitsu duplex scan with usb
agreed, just committed an updated version. please check. but i get this error: henning? Checking in doc/descriptions/fujitsu.desc; /cvsroot/sane/sane-backends/doc/descriptions/fujitsu.desc,v <-- fujitsu.desc new revision: 1.13; previous revision: 1.12 done U descriptions/fujitsu.desc /bin/sh: sane-backends.html: Permission denied make: *** [sane-backends.html] Error 1 allan On Tue, 6 Apr 2004, Oliver Schirrmeister wrote: > > Thanks, > I think the status of the fujitsu scanners with USB interface should not > be reported 'good'. > > Oliver > > Am Montag 05 April 2004 22:23 schrieb m. allan noah: > > > so, i tracked it down using usb snoopy in windows. the problem is simple > > to explain, but harder to fix: > > > > most scsi commands that use a data block after the command block (mode > > select, set window, scan) are formatted differently when sent via usb. the > > command block is sent first, in a single urb, padded to 31 bytes with null > > bytes. then the data block(s) are sent in another urb, not padded. > > > > the existing fujitsu code is very scsi specific, and only uses one buffer > > for scsi cmd/data to the do_cmd() function. this means that the caller has > > to either pad the single buffer with just the right number of 0's in the > > middle of the buffer, or the do_usb_cmd() function will have to break the > > buffer inhalf, and pad the data itself. > > > > for an example, see fujitsu_set_sleep_mode(). > > > > you see this problem only with scanning duplex or back side because the > > code at line 3112 (talks about opcode==SCAN) is wrong. it should take the > > last one or two bytes and send as adifferent urb, rather than assuming 00. > > > > i have started a new version of the fujitsu backend, which uses a command > > and a data buffer to do_cmd() but have been far too busy to make much > > headway. take a shot if you would like. > > > -- "so don't tell us it can't be done, putting down what you don't know. money isn't our god, integrity will free our souls" - Max Cavalera
[sane-devel] Problem with CanoScan N656U & Mac OS X 10.3.3
This is a multi-part message in MIME format. --030805030401080700080009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Onizuka wrote: > Yesterday I downloaded the current snapshot (to solve OS X compilation > errors in 1.0.13) and built it. > I also compiled and installed the latest libusb (0.1.8). > When I try the scanimage command the scanner make some strange noise > =:-/ and then the program hangs... It seems like a problem with Canon > scanners I once read in this ML but that was long ago and I think it was > solved... > > Anyone can help me? > Thank You!!! > > Gianfranco > > XS206:~ onizuka$ scanimage > test.pnm > [plustek] reader_process: finished reading data Hi! I have been looking into this issue last weekend. A backtrace shows that the process hangs on the read call in sane_read in the plustek backend: (gdb) backtrace #0 0x9000ebc4 in read () #1 0x005ba994 in sane_plustek_read (handle=0x22e000, data=0xbfff77d0 "\210\213?", '?' ..., max_length=32768, length=0xb810) at plustek.c:2051 #2 0x44e0 in scan_it () at scanimage.c:1144 #3 0x5fd8 in main (argc=1, argv=0xa000104c) at scanimage.c:1990 The problem is the following: When the reader process is started with fork (like on linux), the file descriptors in the reader process are automatically closed when the reader process ends. The read call in the main process then exits because the write end of the pipe was closed when the reader process exited. However, when pthreads are used (like on MacOS X) the file descriptors are not closed when the reader thread ends, since in this case the file descriptors are shared between the threads. The read call therefore never exits, since both ends of the pipe are still valid file descriptors. (So this problem is not introduced by the workaround for the broken pthread_cancel call on MacOS X, but present on all platforms that uses threads.) It should be possible to fix this by closing the filedescriptors at the end of the reader thread, e.g. by applying the following patch. (Has not been tested yet, but please do.) If it works it should go into the CVS. Mattias diff -ur sane-backends.orig/backend/plustek.c sane-backends/backend/plustek.c --- sane-backends.orig/backend/plustek.c2004-01-09 15:24:30.0 +0100 +++ sane-backends/backend/plustek.c 2004-04-05 11:51:43.0 +0200 @@ -443,6 +443,8 @@ return SANE_STATUS_IO_ERROR; } + close_pipe( scanner ); + DBG( _DBG_PROC, "reader_process: finished reading data\n" ); return SANE_STATUS_GOOD; } -- mattias.ell...@tsl.uu.se tel: +46 18 471 32 58 http://www.tsl.uu.se/~ellert/ fax: +46 18 471 35 13 --030805030401080700080009 Content-Type: text/plain; name="sane-plustek.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sane-plustek.patch" diff -ur sane-backends.orig/backend/plustek.c sane-backends/backend/plustek.c --- sane-backends.orig/backend/plustek.c2004-01-09 15:24:30.0 +0100 +++ sane-backends/backend/plustek.c 2004-04-05 11:51:43.0 +0200 @@ -443,6 +443,8 @@ return SANE_STATUS_IO_ERROR; } + close_pipe( scanner ); + DBG( _DBG_PROC, "reader_process: finished reading data\n" ); return SANE_STATUS_GOOD; } --030805030401080700080009--
