[sane-devel] Scanning with CanoScan N650U under Mac OS X 10.3.2
I could not get sane to work. But I by chance found another solution for me. Anyone who has a .mac membership can get the Mac OS X version of ArcSoft Photostudio for free. And if you download the appropriate Photoshop plugin from Canon for the N650U you can put the plug-in file into Photostudio's plugin folder and scan with Photostudio for free. Works for basic scanning. The plugin also works with Graphicconverter (shareware app). // \\ Henrik Rintala //
[sane-devel] Trust Imagery 9600
On Wed, 07 Jan 2004 11:00:18 -0100 gerard klaver wrote: > see the teco mailinglist at yahoo, also mail archive is present. > To get this scanner working you have to patch the following files > teco3.conf with the name of the scanner: > scsi "Aashima" "IMAGERY 9600SP" > Frank Zago (teco3 maintaniner) should be able to tell more about the > changes which are needed to get this scanner working. thanks; gives me something to be getting on with. It'll be a while, but I guess no-one else is missing it! regards, Ben.
[sane-devel] Re: pthread_cancel and MacOS X
Hi, On Sun, Jan 11, 2004 at 06:57:09PM +0100, Jaeger, Gerhard wrote: > Henning, what do you think about changing the test-backend. As far > as I understood, the test-backend simulates, when the reader-process > has finished, a "hanging" backend, that is "killed" by the parent process. > Probably we can accept a workaround only for the MacOS platform... I think that generally there should be no OS-specific code in the backends at all. The whole idea of sanei_thread and the other sanei_ code is to abstract the OS and hardware access. The idea behind the "hanging" reader process is that the SANE standard wants the backend to close the select filedescriptor at the end of the scan. That's done by the test backend. Some time ago we had trouble with frontends that couldn't cope with closing the select file descriptor. This descriptor is usually a pipe and is it not enough to close the reader process part of that pipe. The parent process side has to be close and that's the signal for the frontend that scanning is finished (no more data). If the reader process doesn't hang until sane_cancel, there is a race condition between closing both sides of the pipe. To make sure that all frontends can cope with closing only the main process side of the pipe, the reader process waits. So if a frontend (or sanei_ implementation) can't cope with that, there is usually a general problem that just don't happen that often with other backends because most of the time the reader process terminates too fast. However, with threads I guess a file descriptor isn't closed after exiting the thread (?). In this case we can ignore that problem so I don't mind removing the endless loop if we are using threads in the test backend. I don't know about the patch concerning sanei_thread itsself as I'm rather clueless about threads :-) Generally speaking, this should be fixed where it is broken. If there are simple and not too ugly workarounds in SANE, that's ok for me. But otherwise I guess it's "not our fault". Bye, Henning
[sane-devel] Re: pthread_cancel and MacOS X
Hoh, hoh... stop, I don't say, that it is not needed or not useful!!! I only mean, that we should not spend too much time on a problem which needs to be fixed outside of SANE. Also please remember: Using the pthread approach instead of the Unix process stuff has also been done, because of MacOSX is not able to inherit file descriptors to a child process. Now that the sanei_thread stuff seems to work for quite a lot of platforms, we ran into the next MacOSX trouble... What comes next? I mean I appreciate your work as I think it is useful to spread SANE over another platform, but I don't think that SANE should work around each OS bug, especially here, when there's no clean solution for this problem. This needs to be solved by the guys, that implemented the pthread stuff there. Henning, what do you think about changing the test-backend. As far as I understood, the test-backend simulates, when the reader-process has finished, a "hanging" backend, that is "killed" by the parent process. Probably we can accept a workaround only for the MacOS platform... Hope we find a good solution on that. I'll recheck some other approaches... Ciao, Gerhard On Sonntag, 11. Januar 2004 15:28, Mattias Ellert wrote: > Jaeger, Gerhard wrote: > > Hi again, > > > > I also think, that a working test-backend is not that essential, as > > working "real" backends. > > Here I must strongly disagree. A working test backend is extremely > essential. It is a very important tool in debugging. > > If a frontend works with the test backend, but not with some other > backend, you know that the problem is (most probably) in that backend > and not in the frontend itself. > > If you can change the test backend in some other way so that the patch > is not needed, that would be fine, but giving up a working test backend > is not a viable solution to the problem. > > Mattias
[sane-devel] Re: OS X and umax 1220u
some info may be repeated as I'm cross-posting to the backend devel list. On Jan 11, 2004, at 8:15 AM, Henning Meier-Geinitz wrote: > On Sat, Jan 10, 2004 at 04:38:59PM -0600, David Minor wrote: >> I commented out everything in dll.conf but umax1220u, set USB debug >> output to 255 in addition to the umax1220u debug at 128 as before. I >> also disconnected all other USB devices to simplify matters. I'm not >> going to pretend to being able to interpret the output, but I will >> attach for anyone to look over and see if the problem can be isolated. > > I'm not the author of that backend so I may be completely wrong... > > However, this time you get a completely different error. Openeing the > scanner works, but starting the scan doesn't: > >> [umax1220u] sane_start >> [umax1220u] UMAX_set_scan_parameters: >> [umax1220u] color = 1 >> [umax1220u] xo= 0, yo = 0 >> [umax1220u] w = 0, h = 0 >> [umax1220u] xres = 75, yres = 75 >> [umax1220u] left = 0, top= 0 >> [umax1220u] right = 0, bottom = 0 >> scanimage: sane_start: Invalid argument > > There is no tranfer to the scanner involved at all. Looks like a > backend bug. It sets widths and height to 0 by default. > > Try again with scanimage but set width and height explicitely to e.g. > 10 mm (see scanimage --help for details). > versions: scanner: umax 1220u system: OS X 10.3.2 scanimage (sane-backends) 1.0.13; backend version 1.0.13 (patched) TWAIN SANE interface: 0.3 libusb: 0.1.8 beta 2004-01-05 $ scanimage -L device `umax1220u:libusb:001:004' is a UMAX Astra 1220U flatbed scanner $ scanimage -T scanimage: sane_start: Invalid argument $ scanimage -x 200 -y 200 I can successfully scan if I pass width/height params. What a great sound to hear this old dust collector chugging away! Using TWAIN Acquire in Graphic Convertor still does not work. No feedback from it at all. So it works, but not out of the box. It would be great if I could find a way to 1) get TWAIN working and 2) get the backend automatically come up with the dimensions needed. Thanks, Henning, for your consistent review and prompt reply on this list. Thanks to all the developers related to this process for keeping at it. I would be happy to continue to test/try things for the os x/umax 1220u environment. dm
[sane-devel] HP Scanjet 3670...
Hi, sanjay.chigurup...@lntinfotech.com has a HP scanjet 2400 and it seems to be the same driver. After the mail of mancio_...@libero.it we just received, I think I am the last one to try to write a driver for this scanner :( If I forget someone just send an e-mail... Personnaly, I just defend my PhD and due to that I had no time to go on with this driver, but now i will have much time and I am still very interested to do it. I tried to ask HP for some technical doc but with no results... if you want to try... I tried to log the usb transaction under windows, bur unfortunately I can only log the beginning of the transaction... I don't receive anything in the log after the preview scan :( So as you can see we are at the very beginning of this job, but if you are interested I will be very very happy to collaborate. Do not hesitate to e-mail me, and we can start a more robust project to lead to this driver if you want... Sincerely Mike Christian Josefsson wrote: > Hi! > > I'm a Computer Science student, which has come to the point of writing > my Master Thesis. Since I'm interested in systems programming and Linux > and in the posession of a unsupported scanner, namely hp scanjet 3670, > I've concidered writing a driver for that scanner as part of my Thesis > (the thesis would also contain other investigations ...). > But since there appears to be some activity going on in writing a driver > for the scanjet 3670 I would like to hear, how far you have come, and > if it would be feasible for one more person trying to write the driver... > > However in case the driver is already close to finished and/or there already > are enough developers aiming at the same driver, I'd stop pursuing this > idea and instead find myself another subject for my Thesis. > > Kind regards > // Christian
[sane-devel] Epson GT-7400U not detected
=2DBEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, > > You may also try the snapscan backend. At least the 1670 is > > supported by that backend. Maybe these scanners are similar? But > > you will need the latest development version of SANE. Maybe the > > manintainer of the snapscan backend has heard baout that scanner: > > Oliver Schwartz > > I've checked around a little bit and found some tidbits of > information that seems to indicate that the GT-7400U is the little > sister of the GT-8400U. There is a reasonable chance that this > scanner works with the snapscan backend. You will probably have to > muck around a bit to get it to load the right firmware file and > copy that file from the Windoze software. With a bit of luck it's sufficient to add the USB IDs in snapscan.conf=20 and edit the path to the firmware file in snapscan.conf. The firmware=20 file is installed with your windows driver, it's probably named *.bin=20 and located somewhere under WINNT/Twain32. If possible please send me a debug log from=20 "SANE_DEBUG_SNAPSCAN scanimage -L > debug.log" =2D -Oliver =2DBEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQFAAV8x/V6sbrmfIuMRAnWqAJ9fqP+YuDyqG+0jEnbFAs6MtNMbXwCffAJP GhiyguWWkjD6DnEOEs5+VSE=3D =3DzEd0 =2DEND PGP SIGNATURE-
[sane-devel] Re: pthread_cancel and MacOS X
Jaeger, Gerhard wrote: > Hi again, > > I also think, that a working test-backend is not that essential, as working > "real" backends. Here I must strongly disagree. A working test backend is extremely essential. It is a very important tool in debugging. If a frontend works with the test backend, but not with some other backend, you know that the problem is (most probably) in that backend and not in the frontend itself. If you can change the test backend in some other way so that the patch is not needed, that would be fine, but giving up a working test backend is not a viable solution to the problem. 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] OS X and umax 1220u
Hi, On Sat, Jan 10, 2004 at 04:38:59PM -0600, David Minor wrote: > I commented out everything in dll.conf but umax1220u, set USB debug > output to 255 in addition to the umax1220u debug at 128 as before. I > also disconnected all other USB devices to simplify matters. I'm not > going to pretend to being able to interpret the output, but I will > attach for anyone to look over and see if the problem can be isolated. I'm not the author of that backend so I may be completely wrong... However, this time you get a completely different error. Openeing the scanner works, but starting the scan doesn't: > [umax1220u] sane_start > [umax1220u] UMAX_set_scan_parameters: > [umax1220u] color = 1 > [umax1220u] xo= 0, yo = 0 > [umax1220u] w = 0, h = 0 > [umax1220u] xres = 75, yres = 75 > [umax1220u] left = 0, top= 0 > [umax1220u] right = 0, bottom = 0 > scanimage: sane_start: Invalid argument There is no tranfer to the scanner involved at all. Looks like a backend bug. It sets widths and height to 0 by default. Try again with scanimage but set width and height explicitely to e.g. 10 mm (see scanimage --help for details). Bye, Henning
[sane-devel] Problems with mustek_pp and releasing the parallel port
Op 10-01-04 21:59:13 schreef Jim George: > Hi Eddy, > > I do have a printer connected to the same port. It's an Epson Photo > Stylus 820cxi if that makes any difference. Have you tried disconnecting it? > I tried turning off/on my scanner but that made no difference, then I > rebooted and when I tried again I got the attached (which was the > same as when I had to turn the scanner off/on). > > Could it be a simple configuration issue, something like using EPP on > the port? That's unlikely, but you never know. You can try changing the port settings in the BIOS. You can usually choose between EPP, ECP, ... Maybe it makes a difference. > Anyway please find the SANE?I_PA4S2 output from this aborted > attempted attached. The scanner still isn't recognized. Can you still scan at all in non-debug mode? Best regards, Eddy
[sane-devel] HP Scanjet 3670...
> > I haven't heard from mancio_...@libero.it after his initial posti= ng > (http://lists.alioth.debian.org/pipermail/sane-devel/2003-November/= 009360.html). > If he doesn't answer on this list, try to contact him di= rectly. > Hi, I'm sorry, I had no time enough to begin the project.= Bye.
[sane-devel] Sane USB problem with HP ScanJet 5300C on FreeBSD-5.2-RC2/amd64
--Boundary-00=_gDVAA0n5p0t0Hbn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I'm trying to get my scanner to work on FreeBSD 5.2-RC2/amd64. I can "see" the scanner with sane-find-scanner and usbdevs but scanimage seems to hang. I'm using the sane-backends-1.0.12_3 and sane-frontends-1.0.11 and libusb-0.1.7_1 from the package tree (but also tried ports and a newer backends version as well). See attached the DEBUG output of "scanimage -L". For me it looks like the scanner is found and a request is written to it, but there is never an anwer. Beside, how do I use libusb on 5.2? The man pages are saying something about creating /dev/ugen* but as 5.2 uses devfs, you can't create it and it isn't there. Cheers, aanno --Boundary-00=_gDVAA0n5p0t0Hbn Content-Type: application/x-gzip; name="scanimage.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="scanimage.log.gz" H4sICOkvAEACA3NjYW5pbWFnZS5sb2cAvZdtT9swEMff91Oc4AVlom2SPgCReAGdJjqNhy2ANCEU nMQJFold2U5Zv/3sxEDLCjJrwKpaJ7m7/8927N5dC0QxCRMcldkNBFhKQjOoLiHHM5wDSwHNiCCM gmSw121d27jUNqWItJPrPbupWzdwjznFeZhhGc4wTRgPp5wlZSx9GLMyT4AyCRxLTlQ8qE16xgQm XyHlrFCKMxJjGCxFfuqGhBIVLmUlTYweiBhRivmjZ9v54/RTp6d+dh13G5CEnnrUK42d09JxhIKs BucvjzXTvXq8aojecAhtRrcrFybClNAkjEohsPDhWwVhYkeOhY1rMSjXjEO0rs0C1ZbGaIq40Igx oylRpIRi2NhYbWtsUpLj2tD1gWSUcR0AF1M5r26/Q2iTTaV+ZRIiUJTjToaKAnWk7tsyeAsMMSsK TOW6FDHKScSRvmdL0W+OguXJ/xAMGiSgZg46jOZzW4BhcwAp4zHuoIGt9OgD3oFhJysRT2wRdtdH sJXaW3vXiVgQOLyaBJOzU1vV/QbmuNL9Nj4/tD5gnKZUTyanZz8u7IXd5oQvgqNJcAwn48NOMHKc sTWD9zEMGsKaod8Uw/G5teagKc27qbXm8PP2rztqZgNXWYBJQqy1GzinNnW+9pSDvBdgr2mAd0/B fkMEy1mgdb7SxJFW57qwcYwfcpVtwjmK7/WflTVEE8dbwRKV1b5kgEBNyHcsYdjXZ501kfd5G9Dr r7sB9fLXZQHUZYG1tDrbJJ/rgKocQFKi+A4ugyP/9p+QW68k91U9YHJ631Q9B7XnDpjq56AOsWMU 1KXnOHh/EON4AbR+6EP7CnN9xwe368BRSfLEh11ne4Upm2Kq4V9UQKtJtfHicPX1Y1V1uxxh680Q +hsnoKfoFXdof0nowUpkoWZIA0xOf15Ofv1esFBkGuuBE4khLpIdtV4lVcs26r6CU5mqYiy/XxxX HWAE0VzqMmvB01FNzaqnOuYzqr7fbl3VbrvPrfUXTmJcgX8PAAA= --Boundary-00=_gDVAA0n5p0t0Hbn--
[sane-devel] HP5370C - Distorted image
--qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable While I can't really tell you how to fix it, what causes the problem is actually trivial. Lets say that the scanning software is expecting the scanner to send 541 pixels per line and the scanner actually sends 542, each row gets offset by one leading to a very nice 45 degree slant to the right. If it sends 540 you get a slant to the left. It's a very simple off-by-one error. Maybe if you try scanning different sizes to see which ones work and which ones don't you can get some kind of idea of where the discrepancy lies. Hope this helps, On Sun, Jan 11, 2004 at 03:29:54AM +0100, gil...@ffii.org wrote: > Hello. >=20 > First: Thanks a lot for your continuous efforts to make this scanner work= with > Linux! >=20 > [Last time I had tried it (several months ago), with 'hpusbscsi', I had to > quickly power off the scanner as the awful noise and erratic motion of the > scanning made me believe it would fall apart... > Today I compiled kernel 2.6.0, and reading that 'hpusbscsci' was now > obsolete, I thought I could give it a try.] >=20 > Now the scanner doesn't seem to suffer anymore :-) but the image produced > is distorted: I'm among the unlucky ones who get a 45 degrees > shifted-wrapped image (cf. a post from November 26). >=20 > Is the source of the problem known? Any chance that the scanner will be > working properly? [Scanning is the last and only thing which I must do on > M$-Windows!] >=20 >=20 > Best regards, >=20 > Gilles >=20 > P.S. System info: > # scanimage --version > scanimage (sane-backends) 1.0.13; backend version 1.0.13 >=20 > Debian GNU/Linux testing/unstable >=20 > --=20 > 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 --=20 Martijn van Oosterhout http://svana.org/kleptog/ > (... have gone from d-i being barely usable even by its developers > anywhere, to being about 20% done. Sweet. And the last 80% usually takes > 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFAAL/bY5Twig3Ge+YRAtzbAKDYcfxmr4AsoxUivHdLuDSkBcMAhwCcCR4f G+J1LRw7eVNdu9X6hWpD9N0= =bAt+ -END PGP SIGNATURE- --qDbXVdCdHGoSgWSk--
[sane-devel] HP5370C - Distorted image
Hello. First: Thanks a lot for your continuous efforts to make this scanner work with Linux! [Last time I had tried it (several months ago), with 'hpusbscsi', I had to quickly power off the scanner as the awful noise and erratic motion of the scanning made me believe it would fall apart... Today I compiled kernel 2.6.0, and reading that 'hpusbscsci' was now obsolete, I thought I could give it a try.] Now the scanner doesn't seem to suffer anymore :-) but the image produced is distorted: I'm among the unlucky ones who get a 45 degrees shifted-wrapped image (cf. a post from November 26). Is the source of the problem known? Any chance that the scanner will be working properly? [Scanning is the last and only thing which I must do on M$-Windows!] Best regards, Gilles P.S. System info: # scanimage --version scanimage (sane-backends) 1.0.13; backend version 1.0.13 Debian GNU/Linux testing/unstable
[sane-devel] RX500 MFP scanner
Could someone help me to get the scanner part of this device working? I haven't got it working although I've got it recognised as a RX500. The problem is that it somehow cannot switch the device on. output of command "lsusb" is: Bus 001 Device 002: ID 04b8:0807 Seiko Epson Corp. output of "sane-find-scanner" is: # No SCSI scanners found. If you expected something different, make sure that # you have loaded a SCSI driver for your SCSI adapter. found USB scanner (vendor=0x04b8 [EPSON], product=0x0807 [USB2.0 MFP]) at libusb:001:002 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. # Scanners connected to the parallel port or other proprietary ports can't be # detected by this program. output of scanimage -L [epson] Unknown type R or level d, using B3 device `v4l:/dev/video0' is a Noname Terratec Cinergy 400 TV virtual device device `epson:libusb:001:002' is a Epson RX500 flatbed scanner If I start xsane as a user I don't get to see the device, but as root it gives me the option of using my TV-card or the RX500 device. After selecting the RX500 xsane starts well. Now if I want to make a scan or a prescan it generates a message that it cant switch on the device. "wrong/false argument". Seems I close but I haven't got enough administrator experience with these type of devices. Am I missing something simple here? //Marcellino
