[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] [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] [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] [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] [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] [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] [ANN] Plustek Backend update V0.45-1
Hi there, 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. 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 CanoScan LIDE 20 CanoScan LIDE 30 Although the picture quality on the CanoScan 1220 and 1240 is not very good, I think we're on the correct way... The USB support covers now the libusb too, please have a look at the plustek.conf for more info. Please test the stuff with your devices. Cheers Gerhard
[sane-devel] [ANN] Plustek Backend update V0.45-1
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. 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 Jaeger, Gerhard wrote: Hi there, 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. 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 CanoScan LIDE 20 CanoScan LIDE 30 Although the picture quality on the CanoScan 1220 and 1240 is not very good, I think we're on the correct way... The USB support covers now the libusb too, please have a look at the plustek.conf for more info. Please test the stuff with your devices. Cheers Gerhard ___ Sane-devel mailing list sane-de...@www.mostang.com http://www.mostang.com/mailman/listinfo/sane-devel
[sane-devel] [ANN] Plustek Backend update V0.45-1
On Saturday 11 January 2003 10:05, Jaeger, Gerhard wrote: Announcing a new 45-1 release. In addition to my other excess verbiage report, I should add that the only way to shut the epson 1250u lamp off is to wait out the idle period before quitting, or quit and restart, then quit again once its recognized the scanner and blinked the light once then turned it off. A simple quit while the lamp is still on will leave it on. And I do have those options set in my plustek.conf. Or at least I *did* have them set. On checking to make sure of my facts, I found the loffOnEnd was 0, and lampOff also at 0. So I assume my file was overwritten at some point by a fresher version. Resetting those, the lampOff delay now works. But I'm back to the other oddments I had before, like the first preview run looked pretty good, but the histogram windows showed only a single line. The trim each color set of sliders that you get when clicking on the lower left icon was normal at that point. A rescan then set everything to maximum except the gamma sliders, and the formerly 2 stops too bright preview display dropped about 5 stops in britness, with the histograms now showing the raw only covering the leftmost 1/3 of that window, and processed only covering the leftmost 2/3rds of the display. Do we have a wild pointer someplace? Memory allocated but not initialized till after the first run? Something is certainly odd. I stopped it, restarted it, and got both histograms properly filled in this time, and with the preview display now about 1 stop dark, and the raw is using the left 1/3rd, but the enhanced is now full scale. Bringing the gamma up to 1.3 in all channels like I set in the plustek.conf makes the previewed image look very good. I'm gonna stop it and restart it after I've caused some memory shuffling so it doesn't get its own memory back. I'll be back later. -- 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 Saturday 11 January 2003 19:30, Henning Meier-Geinitz wrote: Hi, On Sat, Jan 11, 2003 at 07:07:49PM -0500, Gene Heskett wrote: On checking to make sure of my facts, I found the loffOnEnd was 0, and lampOff also at 0. So I assume my file was overwritten at some point by a fresher version. At least the original sane-backends make install does not overwrite config files. But if you did make uninstall, they would have been removed. No, I hadn't. The trim each color set of sliders that you get when clicking on the lower left icon was normal at that point. A rescan then set everything to maximum except the gamma sliders, and the formerly 2 stops too bright preview display dropped about 5 stops in britness, with the histograms now showing the raw only covering the leftmost 1/3 of that window, and processed only covering the leftmost 2/3rds of the display. I'm not sure if I understand this but are you talking about xsane's autoadjsut gamma, brightness and cotrast feature? That can be disabled in Preferences-Enhancement-Autocorrect colors. Thanks, I'll give that a try. -- 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 Saturday 11 January 2003 20:12, Gene Heskett wrote: On Saturday 11 January 2003 19:30, Henning Meier-Geinitz wrote: Hi, On Sat, Jan 11, 2003 at 07:07:49PM -0500, Gene Heskett wrote: On checking to make sure of my facts, I found the loffOnEnd was 0, and lampOff also at 0. So I assume my file was overwritten at some point by a fresher version. At least the original sane-backends make install does not overwrite config files. But if you did make uninstall, they would have been removed. No, I hadn't. The trim each color set of sliders that you get when clicking on the lower left icon was normal at that point. A rescan then set everything to maximum except the gamma sliders, and the formerly 2 stops too bright preview display dropped about 5 stops in britness, with the histograms now showing the raw only covering the leftmost 1/3 of that window, and processed only covering the leftmost 2/3rds of the display. I'm not sure if I understand this but are you talking about xsane's autoadjsut gamma, brightness and cotrast feature? That can be disabled in Preferences-Enhancement-Autocorrect colors. Thanks, I'll give that a try. And it does work a whole lot better, even densities are had from 150dpi to 2400 dpi now. 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? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
