[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi, On Sat, Jan 11, 2003 at 04:05:59PM +0100, Jaeger, Gerhard wrote: I've currently updated the Plustek Backend. New version now is 0.45-1. All changes are now in CVS and will go into SANE-1.0.10. Please check plustek.desc, the unsupported entries are broken, they are all listed as Canon scanners. I guess you can just remove them because they are in unsupported.desc now. By the way, I'll remove the UT16B from unsupported.desc because it's already listed in gt68xx.conf as untested. I hope it's not too much trouble to support it in gt68xx. But there don't seem too much of these scanners, at least nobody (but you) has yet contacted me about this scanner. This version is more or less a bug-fixing version and includes support for the EPSON 1260 Photo (inkl. TPA autodetection) - shouldn't damage motor anymore! CanoScan N670U/N676U CanoScan N1220U CanoScan N1240U Cool, so the new entries in unsupported.desc are void :-) Although the picture quality on the CanoScan 1220 and 1240 is not very good, I think we're on the correct way... Shouldn't the status then be beta instead of stable? Just a nitpick :-) The USB support covers now the libusb too, please have a look at the plustek.conf for more info. Cool. I think that all backends can now cope with libusb. Bye, Henning
[sane-devel] Re: Sane on Ultra Sparc
Hi, On Sat, Jan 11, 2003 at 07:40:17PM +0100, T. Ribbrock wrote: On Fri, Jan 10, 2003 at 06:15:58PM +0100, Henning Meier-Geinitz wrote: Ok. This is for SANE 1.0.8? gcc version? Compilation worked without any patches? bosth shared libs and dynamic loading works? USB and X clients are unknown? It's sane 1.0.7. Compilation needs a patch that was probably added by Red Hat, so don't ask me how or why... :-} The patch is attached - without it, I get compile errors when rebuilding the RPM. Yes, the famous we have io.h but it's broken bug. At least 1.0.10 should work around this one. I'll just wait for 1.0.10 with the SCSI work-around included and then add that one to the list. And while we're at it - for sane 1.0.7: Linux 2.4 Sparc32, gcc 2.96, User-level SCSI support: yes, USB: ???, shared and dynamic library support: yes, X11 clients: ??? URL: http://www.ultralinux.org Tested with only one Mustek scanner, but on two different SparcStations... Thanks, will be added to web page. The patch mentioned above applies to this one as well - my apologies for not checking all. The 1.0.9 backends seem to compile without that patch, though. Ok. It would be nice if you could also test 1.0.10 also, once it's released. Thanks, Henning
[sane-devel] How many scanners on an ieee1394 bus
Does anyone know how many scanners you can hang on an ieee1394 or USB 2.0 bus and still get sane to work on all of them? As many as these busses take, in principle. There might be a limit on IEEE1394 simply because you run out of sg devices after a while, but I'm not sure what the limit is. As a matter of fact, I'm not even sure how many devices you can have on an IEEE1394 or USB2. As far as SANE is concerned, there should be no limit, all devices should work independently from each other. The only problem comes when you have two identical scanners and want to tell them apart in software, but what do you want that for anyway... Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
[sane-devel] Info: More re-badged Artec E+ 48U scanners
Hi, just in case someone wants to know it/for the list archive: It has been reported, that the following scanners are re-badged Artec E+ 48U models, and therefore work with the artec_eplus48 backend: Memorex Mem 48u (reported by Avrum Goodblatt) Medion MD4394 (reported by Keith Abraham) Obviously it's easier to invent new names than new scaners :-) bb Michael
[sane-devel] How many scanners on an ieee1394 bus
and...@users.sourceforge.net said: As many as these busses take, in principle. There might be a limit on IEEE1394 simply because you run out of sg devices after a while, but I'm not sure what the limit is. As a matter of fact, I'm not even sure how many devices you can have on an IEEE1394 or USB2. For USB 1 or 2 it is 127 devices on the bus and you have to have a master device controlling the show. Usually the computer and you can only have one such device. So you cannot easily plug the same USB device into two computers at once. For IEEE1394 (or FireWire/iLink) it is 64 devices on a bus, and no requirement for a master device, as all devices can be a master. So you can simply sling a Firewire cable between two machines and they can talk to one another over it, or you can connect the same device (scanner, hard disk etc.) to two machines at one. These are things you cannot do with USB. Rounding off the maximum number of scanners on a single IEEE1394 bus would in theory be 63. However I doubt you get get anywhere near either of these maximum figures before things fall over. JAB. -- Jonathan A. Buzzard Email: jonat...@buzzard.org.uk Northumberland, United Kingdom. Tel: +44(0)1661-832195
[sane-devel] mac osx with epson usb backend
Hi, On Sat, Jan 11, 2003 at 09:24:33AM -0800, Ricky Charlet wrote: Mac OSX 10.2.3 libusb-0.1.7 BUT! from your advice in the previous post, I replaced my sane-backends with the sane-backends-2003-01-11 snapshot. (I did a make uninstall; make distclean in sane-backends-1.0.9 and compiled then compiled and installed the sane-backends snapshot. ) This has solved my problem I reported in my last post. Yeah! scanimage now succeeds in recognizing the existance of my scanner. Ok. But I still can't scan. :-( I'll insert an output dump of scanimage with SANE_DEBUG_USB=255, SANE_DEBUG_SANEI_USB=255, SANE_DEBUG_EPSON=255. My read of this dump is that there is a libusb call (usb_bulk_read) failing. But what confuses me is that during this dump there are some previous points at which usb_bulk_read was called and apparently succeeded. Anyway here is the dump = [sanei_usb] sanei_usb_close: closing device 0 USB error: error clearing pipe stall That may be part of the problem. For some reason, the usb_clear_halt fails. [sanei_usb] sanei_usb_open: trying to open device `libusb:-08:005' usb_os_open: 04b8:0101 [...] Again the device is opened. usb_bulk_write: endpoint=0x02 size=2 TO=6 write completed CFLoopRun returned [sanei_usb] sanei_usb_write_bulk: wanted 2 bytes, wrote 0 bytes The write fails. I guess because of the clear_halt failed before. Try editing sanei/sanei_usb.c. Search for sane_close, there are two lines with usb_clear_halt in this function. Comment them out and recompile/reinstall. Does it work now? Bye, Henning
[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi, On Sat, Jan 11, 2003 at 09:55:05PM -0500, Gene Heskett wrote: Just one thing about using that preferences menu. The builtin no activity timeout shuts it (xsane and company) down in about 30 seconds, making it hard to study the menu's and adjust anything before xsane goes away. Can this be reset somehow to say 5 minutes? Which builtin no activity timeout? Is this plustek-specific? At least with other backends (e.g. test) there is no such thing as far as I know. Bye, Henning
[sane-devel] mac osx with epson usb backend
Hi, On Sun, Jan 12, 2003 at 06:46:08AM -0500, Karl Heinz Kremer wrote: On Sun, Jan 12, 2003 at 12:12:56PM +0100, Henning Meier-Geinitz wrote: [ ... ] usb_bulk_write: endpoint=0x02 size=2 TO=6 write completed CFLoopRun returned [sanei_usb] sanei_usb_write_bulk: wanted 2 bytes, wrote 0 bytes If I remember correctly, libusb on the Mac will not report how may bytes it wrote, so this my not be a problem. You are right, that's a libusb bug. The CVS version of libusb seems to return the number of bytes written, however. So this one is the real problem? Converting ep address to pipeRef. pipeRef for ep 0x81 found: 0x01 usb_bulk_read: endpoint=0x81 size=1 TO=6 USB error: error reading from bulk endpoint 81 [sanei_usb] sanei_usb_read_bulk: read failed: No such file or directory No such file or directory? Maybe errno doesn't show the correct error here. I don't see any pattern when read works and when it doesn't. Bye, Henning
[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi, On Sunday, 12. January 2003 00:20, Henning Meier-Geinitz wrote: [SNIP] Please check plustek.desc, the unsupported entries are broken, they are all listed as Canon scanners. I guess you can just remove them because they are in unsupported.desc now. Okay fixed! By the way, I'll remove the UT16B from unsupported.desc because it's already listed in gt68xx.conf as untested. I hope it's not too much trouble to support it in gt68xx. But there don't seem too much of these scanners, at least nobody (but you) has yet contacted me about this scanner. Also fixed (removed from the unsupported.desc file). Well I'm not sure about the 16B maybe we get more requests upon this device in the near future. I believe, that it is almost the same scanner as the 1248U - we'll see. This version is more or less a bug-fixing version and includes support for the EPSON 1260 Photo (inkl. TPA autodetection) - shouldn't damage motor anymore! CanoScan N670U/N676U CanoScan N1220U CanoScan N1240U Cool, so the new entries in unsupported.desc are void :-) Already removed. Although the picture quality on the CanoScan 1220 and 1240 is not very good, I think we're on the correct way... Shouldn't the status then be beta instead of stable? Just a nitpick :-) Hmpf! Depends on how you classify status? On one hand you're right - the scanner is not supported perfectly, on the other hand, the backend code is stable so far - so what? The USB support covers now the libusb too, please have a look at the plustek.conf for more info. Cool. I think that all backends can now cope with libusb. Well at least the old version was able to be used with libusb, but there you needed to know the libusb device node Cheers Gerhard
[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi Till, On Saturday, 11. January 2003 19:12, Till Kamppeter wrote: Thgank you for the update. I am preparing an official update for Mandrake Linux 9.0 now, to preven the Epson 1260 Photo scanners of Mandrake 9.0 users from being damaged. I have tested your update with my Epson Perfection 1260 Photo (it survived the driver version shipped with SANE 1.0.9 without needing to turn it off) and it works well. Puhh - thank god! Only problem is the model auto-detection. It is way too slow. I have a tip to make it faster: When you run sane-find-scanner, it needs about a second after failing with the SCSI search to find the scanner's USB ID's. And if I mention the USB ID's directly in plustek.conf, xsane needs about a second to start. So I recommend that you let the auto-detection part of the plustek driver call the library function which sane-find-scanner uses to determine the USB ID. Then the driver can probe this ID directly and so it gets access to the scanner in two seconds instead of two minutes. WDYT? Till Hmmm, I didn't get this one! If you still provide only the device name, then the startup behaviour should be the same as before (1.0.9) the only thing I changed here is the autodetection of the device name, to support the libusb stuff. It's not clear to me, why it takes so long for autodetection... Even when I use the libusb, it's not that slow here: cfg example: [usb] device auto Okay I have no SCSI subsystem! But as told before when using [usb] device /dev/usbscanner then you should have the same behaviour as before. Gerhard
[sane-devel] Re: [ANN] Plustek Backend update V0.45-1
Hi Gene, On Saturday, 11. January 2003 22:08, Gene Heskett wrote: On Saturday 11 January 2003 10:05, Jaeger, Gerhard wrote: Announcing a 45-1 release. I unpacked it over the old 45 in sane-backends-1.0.9, did a make clean make make install, which apparently went well. Fireing up xsane from the icon, I had it do a preview, which ran as far as the end of the forward travel of the carriage, at which time it cleared Olivers logo from the preview window, and the whole thing went away about 1 second later. The carriage went back home as it should have, but the lamp was left on. Quite a strange behaviour! I recommend to check the .conf file each time you make an update. Running it from a shell, it did the same thing, and reported a segfault to the shell window as it exited. I remember this behaviour a long time ago, but after a complete source code review and cleanup of my environment there are no problems left here! The epson iscan-1.40 derived backend still works ok though. It should do so;-) I'm going to do another make clean and get rid of the config.cache etc stuffs and try it again, as I've re-arranged the order in ld.so.conf a bit since that configure was done. Humm, that might have done something, in 2 restarts it hasn't crashed yet. See above! However, the returned image seems to be quite dark in the 600 dpi mode, with the raw histogram only occupying about the left hand 25% of that window. Also, all the britness and contrast sliders for both overall and rgb are pegged at the right border of the slider, and labeled 100 at that point. The initial image doesn't look that bad in the preview window, but 1/2 second later when the autoadjust kicks in, the image drops to be dark enough to be obvious. It can only be rescued by the options window britness slider being set for about +4 and a new scan done. Also, the white line artifact is (hooray!) gone when at 600 dpi. However, at 300dpi, its back and the output is too dark as before. Then at 1200 dpi, the inverse appears to be true, I'm on the third scan right now with the britness slider in the option window now at -15 and its still quite a bit too bright. Not making too much progress, I'm trying -30 now. Still too bright in the whites, but the darker colors are now all black, but the histograms haven't changed. Now the contrast is set for -30 also, but its still too bright and contrasty. Final settings for a decent scan are brightness=0 and contrast = -65. So thats a bit off. I also tried a 2400dpi scan (can we say slow?) at those settings and it looked pretty close to the 1200 dpi result except its beginnng to look like it was jpegged a wee bit too much. Is this mode by interpolation? Even the white line artifact is fuzzy. Then at 150dpi, the inverse is true, the usable setting is +7 and +50. Ditto for the 75dpi setting. I don't recall this change dpi, change everything else as being this obvious before, and ISTR the main control windows sliders all were centered at 100.0 prior to this. The motor you'll be glad to hear is running very quietly, only noticable at 150 and 300 dpi. This is odd indeed, I went back to do one more check at 600dpi, and had to virtually zero those sliders to get a decent scan again. I think I've got ghosts or something... Should this not be repeatable? Well XSANE is a powerful tool, but there are per default too much things that will be applied to the aquiered image... For first tests, I recommend xscanimage or disabling all of the automatic xsane stuff... Anyway, I tweaked the driver using the information and register settings I got from my EPSON 1260. When having a look at the 1250 and at least at ISCAN, there seem to be some differences which we should pin down... Cheers Gerhard
[sane-devel] Thank you for help driver CanoScan N656U
I compiled Sane 1.09 on my Linux Red Hat 8.0 live machine and it worked perfectly with my CanoScan N656U scanner. I didn't expect it to be so easy, especially on a platform that doesn't get a whole lot of attention sometimes. Thank you SANE developers! Maurizio Tiecher
[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi, On Sat, Jan 11, 2003 at 07:12:39PM +0100, Till Kamppeter wrote: I have tested your update with my Epson Perfection 1260 Photo (it survived the driver version shipped with SANE 1.0.9 without needing to turn it off) and it works well. Only problem is the model auto-detection. It is way too slow. If you use the kernel scanner driver, that one is at fault. That's fixed in Linux 2.4.21-pre3. The problem is the message about the wrong minor number pronted to syslog over and over again. I have a tip to make it faster: When you run sane-find-scanner, it needs about a second after failing with the SCSI search to find the scanner's USB ID's. sane-find-scanner checks all device file in /dev/usb/scanner* once and tries to find out it's vendor and product ids. Even this is slow with the old kernel driver. The backends ask sanei_usb for all devices that match a give vendor and product id so for each of these requests the function to scan /dev/usb/scanner* is called. This can take quite a lot of time because it 's done for every supported scanner. But essentially, it's the same routine as in sane-find-scanner. The more devices in /dev/usb/scanner? (and /dev/usbscanner*) you have, the longer this can take. That may explain the difference between your and Gerhard's setup. I don't think there is a fix in SANE that can change this until the new kernel scanner driver is installed everywhere. It's also not specific to the plustek backend, because most of the USB backends work this way. The more scanners they support, the longer the scan takes. Example (SANE from CVS): 2.4.21-pre1: time scanimage -L real 1m24.844s user 0m0.040s sys 1m21.080s 2.4.21-pre3: time scanimage -L real 0m0.104s user 0m0.020s sys 0m0.060s To make the scan faster if a new kernel shouldn't be used and the driver shouldn't be back-ported, there may be some work-arounds: - don't create too much /dev/usb/scanner* devices if you don't need them - disable other USB backends in dll.conf - use only libusb, not the scanner driver bye, Henning
[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi, On Sun, Jan 12, 2003 at 02:49:54PM +0100, Jaeger, Gerhard wrote: Although the picture quality on the CanoScan 1220 and 1240 is not very good, I think we're on the correct way... Shouldn't the status then be beta instead of stable? Just a nitpick :-) Hmpf! Depends on how you classify status? On one hand you're right - the scanner is not supported perfectly, on the other hand, the backend code is stable so far - so what? For the backend status I think alpha is works somehow, but may crash or do unexpected things. beta: Works ok but not 100% stable in all situations. For the per-scanner status I usually use something like that: alpha: is detected and does scan something, but colors may be completeyl off. beta: works, but maybe not in all modes or up to the highest resolution. stable: everything works. Usually if I put a comment after the scanner that describes something that doesn't work it's not stable. But that's only my personal opinion. Bye, Henning
[sane-devel] sane SCSI lockup with anything other than binary mode
Hi, Running RH 8 distro with upgraded 2.4.19 kernel on a Dell Inspiron 7500 (PIII). I have an Epson GT-8500 scsi scanner attached to the laptop with an Adaptec 1460A SlimScsi PC card adpater. I use the aha152x kernel module as a driver. This combo used to work perfectly (no problems with detection or hi resolution color scanning) until my recent upgrades of kernel and RH version. Now with anything more demanding than binary mode black and white scans, SANE quits and, if I remove the card, the whole system freezes because Linux gets into a loop trying to reset the bus and I have to reboot. I'm wondering if this is a buffer size problem. Any insights would be most gratefully accepted. Here is the output of /var/log/messages: Jan 7 15:17:59 localhost cardmgr[455]: socket 0: Adaptec APA-1460 SlimSCSI Jan 7 15:17:59 localhost cardmgr[455]: executing: 'modprobe aha152x_cs' Jan 7 15:18:01 localhost kernel: aha152x: processing commandline: ok Jan 7 15:18:01 localhost kernel: aha152x: BIOS test: passed, detected 1 controller(s) Jan 7 15:18:01 localhost kernel: aha152x: resetting bus... Jan 7 15:18:01 localhost kernel: aha152x0: vital data: rev=1, io=0x340 (0x340/0x340), irq=9, scsiid=7, reconnect=enabled, parity=enabled, synchronous=disabled, delay=100, extended translation=disabled Jan 7 15:18:01 localhost kernel: aha152x0: trying software interrupt, ok. Jan 7 15:18:01 localhost kernel: scsi0 : Adaptec 152x SCSI driver; $Revision: 2.5 $ Jan 7 15:18:01 localhost kernel: Vendor: EPSON Model: SCANNER GT-8500 Rev: 1.26 Jan 7 15:18:01 localhost kernel: Type: Processor ANSI SCSI revision: 01 Jan 7 15:18:02 localhost kernel: Attached scsi generic sg0 at scsi0, channel 0, id 2, lun 0, type 3 Jan 7 15:18:02 localhost cardmgr[455]: executing: './scsi start sga' Jan 7 15:19:48 localhost modprobe: modprobe: Can't locate module char-major-81 Jan 7 15:21:43 localhost last message repeated 4 times Jan 7 15:21:43 localhost last message repeated 3 times Jan 7 15:21:48 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 001b Jan 7 15:21:48 localhost kernel: printing eip: Jan 7 15:21:48 localhost kernel: cd0a4a21 Jan 7 15:21:48 localhost kernel: *pde = Jan 7 15:21:48 localhost kernel: Oops: Jan 7 15:21:48 localhost kernel: CPU:0 Jan 7 15:21:48 localhost kernel: EIP:0010:[cd0a4a21]Not tainted Jan 7 15:21:48 localhost kernel: EFLAGS: 00010002 Jan 7 15:21:48 localhost kernel: eax: ebx: cbab2c00 ecx: c68ca000 edx: c51bf5c0 Jan 7 15:21:48 localhost kernel: esi: c7a13400 edi: 0004 ebp: cbab2c00 esp: c6aafdf8 Jan 7 15:21:48 localhost kernel: ds: 0018 es: 0018 ss: 0018 Jan 7 15:21:48 localhost kernel: Process scanimage (pid: 1366, stackpage=c6aaf000) Jan 7 15:21:48 localhost kernel: Stack: c12170c0 0020 0340 0354 0297 ca389ad4 c7a13400 cd0a4b4f Jan 7 15:21:48 localhost kernel:cbab2c00 c01c0a60 c01c0452 cbab2c00 c01c0a60 Jan 7 15:21:48 localhost kernel:c01c4630 cbab2c00 ca389ad4 ca389d80 c7a13400 c01c7bd0 cbab2c00 Jan 7 15:21:48 localhost kernel: Call Trace:[cd0a4b4f] [c01c0a60] [c01c0452] [c01c0a60] [c01c4630] Jan 7 15:21:48 localhost kernel: [c01c7bd0] [c01c70b8] [c01c7148] [c01cbab3] [c01ccb70] [c01cb880] Jan 7 15:21:48 localhost kernel: [c01cb65e] [c013a183] [c0108fc7] Jan 7 15:21:48 localhost kernel: Jan 7 15:21:48 localhost kernel: Code: 0f b6 50 1b 8b 14 95 38 44 2e c0 2b 82 9c 00 00 00 c1 f8 02 Jan 7 15:21:59 localhost modprobe: modprobe: Can't locate module char-major-81 Jan 7 15:21:59 localhost last message repeated 3 times Jan 7 15:22:48 localhost kernel: 3(scsi0:2:0) cannot abort running or disconnected command Jan 7 15:22:58 localhost kernel: (scsi0:2:0) cannot abort running or disconnected command Jan 7 15:22:58 localhost kernel: aha152x0: scsi reset in Jan 7 15:23:03 localhost kernel: scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 0 id 2 lun 0 -- Carter Brey (cb...@attglobal.net) Homepage: http://www.newyorkphilharmonic.org/music/orchestra/index.cfm?page=profilepersonNum=7 Confidant, confidante, n: One entrusted by A with the secrets of B, confided to himself by C. -- Ambrose Bierce, The Devil's Dictionary
[sane-devel] [ANN] Plustek Backend update V0.45-1
Henning Meier-Geinitz wrote: For the per-scanner status I usually use something like that: alpha: is detected and does scan something, but colors may be completeyl off. beta: works, but maybe not in all modes or up to the highest resolution. stable: everything works. I think, alpha and beta a good to describe development states of software. For hardware support qualities Perfectly, Mostly, Partially, and Paperweight are better. The above should be translated as as follows: stable - Perfectly beta- Mostly alpha - Partially Unsupported - Paperweight Then the levels match exactly the ones ones on linuxprinting.org (see http://www.linuxprinting.org/database.html). Till
[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi, On Sunday, 12. January 2003 15:43, Henning Meier-Geinitz wrote: [SNIP] Hmpf! Depends on how you classify status? On one hand you're right - the scanner is not supported perfectly, on the other hand, the backend code is stable so far - so what? For the backend status I think alpha is works somehow, but may crash or do unexpected things. beta: Works ok but not 100% stable in all situations. For the per-scanner status I usually use something like that: alpha: is detected and does scan something, but colors may be completeyl off. beta: works, but maybe not in all modes or up to the highest resolution. stable: everything works. Usually if I put a comment after the scanner that describes something that doesn't work it's not stable. But that's only my personal opinion. think you're right here - we have the backend status and at least the per-scanner status, so we should, ahem I should use this more precisely - I'll change it before 1.0.10 release. Gerhard
[sane-devel] sane SCSI lockup with anything other than binary mode
Hi, On Sun, Jan 12, 2003 at 09:49:14AM -0500, Carter Brey wrote: Running RH 8 distro with upgraded 2.4.19 kernel on a Dell Inspiron 7500 (PIII). I have an Epson GT-8500 scsi scanner attached to the laptop with an Adaptec 1460A SlimScsi PC card adpater. I use the aha152x kernel module as a driver. [...] Jan 7 15:17:59 localhost cardmgr[455]: socket 0: Adaptec APA-1460 SlimSCSI Jan 7 15:17:59 localhost cardmgr[455]: executing: 'modprobe aha152x_cs' aha152x_cs? Isn't the name of the module aha152x? Jan 7 15:21:48 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 001b Jan 7 15:21:48 localhost kernel: printing eip: Jan 7 15:21:48 localhost kernel: cd0a4a21 Jan 7 15:21:48 localhost kernel: *pde = Jan 7 15:21:48 localhost kernel: Oops: Jan 7 15:21:48 localhost kernel: CPU:0 Jan 7 15:21:48 localhost kernel: EIP:0010:[cd0a4a21]Not tainted Kernel oops. Run the output through ksymoops and contact the linux kernel mailing list. But check the archives before, maybe it's already solved in a current kernel. It may well be triggered by the driver not expecting big buffers. However, i thought this kind of bug has been solved long time ago. Anyway, you could try seeting the environment variable SANE_SG_BUFFERSIZE to 32768 before running a SANE frontend to decrease the buffer size. Bye, Henning
[sane-devel] Re: [ANN] Plustek Backend update V0.45-1
On Sunday 12 January 2003 09:13, Jaeger, Gerhard wrote: Hi Gene, On Saturday, 11. January 2003 22:08, Gene Heskett wrote: On Saturday 11 January 2003 10:05, Jaeger, Gerhard wrote: Announcing a 45-1 release. I unpacked it over the old 45 in sane-backends-1.0.9, did a make clean make make install, which apparently went well. Fireing up xsane from the icon, I had it do a preview, which ran as far as the end of the forward travel of the carriage, at which time it cleared Olivers logo from the preview window, and the whole thing went away about 1 second later. The carriage went back home as it should have, but the lamp was left on. Quite a strange behaviour! I recommend to check the .conf file each time you make an update. Running it from a shell, it did the same thing, and reported a segfault to the shell window as it exited. I remember this behaviour a long time ago, but after a complete source code review and cleanup of my environment there are no problems left here! The epson iscan-1.40 derived backend still works ok though. It should do so;-) I'm going to do another make clean and get rid of the config.cache etc stuffs and try it again, as I've re-arranged the order in ld.so.conf a bit since that configure was done. Humm, that might have done something, in 2 restarts it hasn't crashed yet. See above! [snip the rest of my whining] Got the email with the debug enabled file, and you should have the debug history by now. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
[sane-devel] [ANN] Plustek Backend update V0.45-1
On Sunday 12 January 2003 06:22, Henning Meier-Geinitz wrote: Hi, On Sat, Jan 11, 2003 at 09:55:05PM -0500, Gene Heskett wrote: Just one thing about using that preferences menu. The builtin no activity timeout shuts it (xsane and company) down in about 30 seconds, making it hard to study the menu's and adjust anything before xsane goes away. Can this be reset somehow to say 5 minutes? Which builtin no activity timeout? Is this plustek-specific? At least with other backends (e.g. test) there is no such thing as far as I know. Beats me Henning. All I can report is that if there is no initial activity, the whole thing goes away in a bit over a minute Well I was gonna include the capture but debug = 255 so let me cancel that first. here is a screen clip after setting the debug off: [root@coyote tmp]# time xsane [sanei_debug] Setting debug level of epson to 0. Alarm clock real1m3.704s user0m0.530s sys 0m0.540s [root@coyote tmp]# My guess is that the nearly 4 seconds is the delay in my choosing the plustek backend before it started. One must start a scan within this time frame or it goes away. Other messing around with the menu's doesn't reset the timer. Maybe this is something Oliver does in xsane? I don't know. As a test of that, I've left xsanimage sitting there after chooseing the plustek backend. Effectively the same thing, it goes away in 1 minute plus the backend selection time lag as follows: [root@coyote tmp]# time xscanimage [sanei_debug] Setting debug level of epson to 0. Alarm clock real1m1.559s user0m0.110s sys 0m0.610s [root@coyote tmp]# I was quicker on the draw that time :-) Now its running again, but with the epson iscan backend. And that doesn't time out, at least in the 1+ minute the plustek backend does. I left it running for about 5 minutes. So that tells me the 1 minute alarm clock is in the plustek backend. But I haven't grepped for it. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
[sane-devel] Re: Sane on Ultra Sparc
On Sun, Jan 12, 2003 at 12:59:49AM +0100, Henning Meier-Geinitz wrote: [...] Yes, the famous we have io.h but it's broken bug. At least 1.0.10 should work around this one. I'll just wait for 1.0.10 with the SCSI work-around included and then add that one to the list. I think 1.0.9 already did - at least I remember compiling it straight from the tarball. The patch mentioned above applies to this one as well - my apologies for not checking all. The 1.0.9 backends seem to compile without that patch, though. Ok. It would be nice if you could also test 1.0.10 also, once it's released. Certainly. Cheerio, Thomas -- - Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919 You have to live on the edge of reality - to make your dreams come true!
[sane-devel] Re: Sane on Ultra Sparc
On Sat, Jan 11, 2003 at 08:19:24PM +0100, abel deuring wrote: [...] (a simple copy of struct sg_io_hdr as defined in sg.h, but with padding ints before each pointer declaration. I even don't know, if the SParc processor use big or low endian pointer/integers, [...] Sparc is big endian - I know that much... ;-) Cheerio, Thomas -- - Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919 You have to live on the edge of reality - to make your dreams come true!
[sane-devel] mustek_pp driver version 12-alpha
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enigC5068C84F9E9AC538F851276 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I just commited version 12-alpha of the mustek_pp driver to the SANE CVS. It's a complete rewrite of the backend based on information provided by Mustek (thank you!). However, there are some differences: * CIS scanners are now completly supported, thanks to Eddy De Greef for writing the driver. He's now also maintaining this part of the backend * CCD scanners with 600dpi optical resolution aren't supported anymore (actually, they never really worked anyway) * CCD scanners with 300dpi are supported, but that part of the driver is not working yet * the config file syntax changed, i hope it's much easier now furthermore, the .desc file is incomplete and the backend exports tons of 'illegal' symbols, i'll fix this before code freeze... regards -- jochen --enigC5068C84F9E9AC538F851276 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+IclR8OF76YrreuMRAlmHAJ4+05FBH7OVhMB4OCRjc9/wGtE6sACg3t3N /84xSJHtg+gkJYEcLqv/psg= =AkJF -END PGP SIGNATURE- --enigC5068C84F9E9AC538F851276--
[sane-devel] [patch] xscanimage: resolution of the resulting GIMP image
--pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, Here is a patch for xscanimage (when used through gimp) to automatically se= t=20 the resolution of the resulting GIMP image. Regards, Aurelien --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Ic1Cw3ao2vG823MRApeDAJwNcr3Z6sZzLkcE6O5hQlevqsBEZgCdG8e9 iiebBFDNz3ggVgTAiovaBns= =yu8h -END PGP SIGNATURE- --pWyiEgJYm5f9v55/--
[sane-devel] [PATCH] Move xscanimage and xsane menu entries in GIMP
--=-=-=
Hi,
A couple of people have asked for the xscanimage menu entries in GIMP
to be moved to File/Acquire, along with XSane's ones.
Here are two patches :
- for xscanimage, move the entries to File/Acquire/xscanimage/*
- for XSane, move the entries to File/Acquire/XSane/*
So both will have a dedicated submenu, and we won't end up with a
zillion of items in File/Acquire.
Please apply,
JB.
--
Julien BLACHE http://www.jblache.org
j...@jblache.org
--=-=-=
Content-Disposition: attachment; filename=xscanimage.diff
Content-Description: xscanimage diff
--- sane-frontends-1.0.9.orig/src/xscanimage.c
+++ sane-frontends-1.0.9/src/xscanimage.c
@@ -284,7 +284,7 @@
Andy Beck, Tristan Tarrant, and David Mosberger,
Andy Beck, Tristan Tarrant, and David Mosberger,
8th June 1997,
- Toolbox/Xtns/Acquire Image/Device dialog...,
+ Toolbox/File/Acquire/xscanimage/Device dialog...,
RGB, GRAY,
GIMP_EXTENSION,
nargs, nreturn_vals,
@@ -299,7 +299,7 @@
if (encode_devname (devlist[i]-name, sizeof (name) - 11, name + 11) 0)
continue; /* name too long... */
- strncpy (mpath, Toolbox/Xtns/Acquire Image/, sizeof (mpath));
+ strncpy (mpath, Toolbox/File/Acquire/xscanimage/, sizeof (mpath));
len = strlen (mpath);
for (j = 0; devlist[i]-name[j]; ++j)
{
--=-=-=
Content-Disposition: attachment; filename=xsane.diff
Content-Description: xsane diff
--- xsane-0.90.orig/src/xsane-text.h
+++ xsane-0.90/src/xsane-text.h
@@ -726,8 +726,8 @@
#define XSANE_GIMP_INSTALL_HELP_(This function provides
access to scanners and other image acquisition devices through the SANE
(Scanner Access Now Easy) interface.)
/* Menu path must not be translated, this is done by the gimp. Only translate
the text behind the last / */
-#define XSANE_GIMP_MENU_DIALOG _(Toolbox/File/Acquire/XSane: Device
dialog...)
-#define XSANE_GIMP_MENU
_(Toolbox/File/Acquire/XSane: )
+#define XSANE_GIMP_MENU_DIALOG _(Toolbox/File/Acquire/XSane/Device
dialog...)
+#define XSANE_GIMP_MENU
_(Toolbox/File/Acquire/XSane/)
#define XSANE_GIMP_MENU_DIALOG_OLD _(Toolbox/Xtns/XSane/Device
dialog...)
#define XSANE_GIMP_MENU_OLD_(Toolbox/Xtns/XSane/)
--=-=-=--
[sane-devel] Feature freeze for SANE 1.0.10
Hi, We are now in feature freeze for SANE 1.0.10. That means, no more features are allowed to be included in CVS. Bug fixes and documentation updates are allowed, however. Further time table: 2003-01-25: Code freeze 2003-02-01: Release After code freeze only fixes of grave bugs that render a backend completely unusable or break compilation and documentation updates are accepted. Bye, Henning
[sane-devel] No devices available
Hi, On Mon, Jan 13, 2003 at 08:02:09AM +1100, Barry Kirsten wrote: On Sun, 12 Jan 2003 22:28, Henning Meier-Geinitz wrote: On Sun, Jan 12, 2003 at 11:05:42AM +1100, Barry Kirsten wrote: I can't get xsane to recognise my Canoscan 600 scanner under Debian 3.0. Try SANE_DEBUG_CANON=255 scanimage -L to get more debug information. debian:/home/barry# SANE_DEBUG_CANON=255 scanimage -L [looks ok] This seems OK to me - the scanner is recognised by sane, and there are no error messages. Fine :-) Did you put /dev/sg1 in canon.conf or set a link /dev/scanner to /dev/sg1? I think that's necessary for the canon backend. Yes, /dev/sg1 and /dev/scanner are in canon.conf and I have made links between the two. I also have /dev/sg1 and /usr/bin/xsane in /etc/sane.d/snapscan.conf. Everything seems ready to go, but it doesn't. I'm puzzled. Any help or suggestions much appreciated. Well, what does happen when you try to scan? Try scanimage image.pnm. If that doesn't work, set the debug variable. Do the same for xsane. Do you use both xsane and scanimage as the same user? Otherwise there may be permission problems. I only one version of SANE installed? Otherwise xsane may use the other one. Bye, Henning
[sane-devel] Epson contacts
Hi, my attempts to get the Epson Perfection 660 working with the SnapScan=20 backend haven't been all that successful so far. It seems that the=20 Perfection 660 has some subtle protocol differences in comparison to=20 Agfa scanners. In the past I got the impression that Epson gives reasonable=20 development support to SANE developers. Does anybody on the list have=20 any contacts to Epson to get some protocol documentation (or maybe=20 even the scanner for testing purposes)? Regards, Oliver http://snapscan.sourceforge.net
[sane-devel] mustek_pp driver version 12-alpha
Hi, On 2003.01.12 21:00 Jochen Eisinger wrote: I just commited version 12-alpha of the mustek_pp driver to the SANE CVS. It's a complete rewrite of the backend based on information provided by Mustek (thank you!). Is there any hope of support for the ScanExpress A3 EP anytime soon? Or,=20 1505 scanners, generally? Melanie
[sane-devel] Re: [patch] xscanimage: resolution of the resulting GIMP image
Hi,
On Sun, Jan 12, 2003 at 09:17:45PM +0100, Aurelien Jarno wrote:
Oups, forgotten the patch...
A bit too late for 1.0.10 but after that we can include the patch.
--- xscanimage.c 2003-01-12 20:45:27.0 +0100
+++ /home/aurel32/xscanimage.c2003-01-12 20:45:09.0 +0100
@@ -380,4 +380,29 @@
#endif /* HAVE_LIBGIMP_GIMP_H */
+static SANE_Word get_resolution(SANE_Handle dev)
+{
+ int i;
+ SANE_Word resolution;
+ SANE_Int num_options;
+ const SANE_Option_Descriptor *option_desc;
+
+ sane_control_option (dev, 0, SANE_ACTION_GET_VALUE, num_options, 0);
Better check the return code. If this fails for some reason,
num_options may be unitialized (or set it to 1).
+ for(i = 1 ; i num_options ; i++)
+ {
+option_desc = sane_get_option_descriptor(dev, i);
+if (option_desc)
+ if (option_desc-name)
+if (strncmp(option_desc-name,
+SANE_NAME_SCAN_RESOLUTION,
+ sizeof(SANE_NAME_SCAN_RESOLUTION)) == 0)
+{
+ sane_control_option (dev, i, SANE_ACTION_GET_VALUE, resolution,
0);
Same here.
+ resolution = get_resolution(dev);
+ if (resolution != 0) gimp_image_set_resolution(scan_win.image_ID,
+ resolution,
+ resolution);
+
Is this function part of gimp 1.0? Just to make sure that xscanimage
still compiles on older installations.
Bye,
Henning
