[sane-devel] Canon LIDE 90
Ralf Haueisen schrieb: Ralf Haueisen schrieb: Hi all. I am just working to get my Canon LiDE 90 working. I took in the genesys_devices.c the LiDE60 an did some changes. I have a sniffer log taken with usbsnoop. Some registers i could firgue out where to set them. The image still looks like data is somehow scrambled. There are some setting in the file for the DAC. (static Genesys_Frontend Wolfson[] ) to which registers do these data belong? TIA, Ralf The settings in the Genesys_Frontend structs go to the analog frontend via the serial interface at registers 0x3a/0x3b(FEWRDATA)+0x51(FEWRA), through sanei_genesys_fe_write_data. If you are receiving noise data, this may indicate that the byte order was swapped. You should check that the parallel interface to the frontend is setup correctly(registers 0x52 to 0x57). HTH, Pierre Hi Pierre. The registers 0x52 to 0x57 are not set by the windows software. If I set 0x52 to 0x05, 0x53 to 0x07 and 0x54-0x57 to 0x00 i get some image. If all registers are zero there is only noise. So it seems this is the point where i have to play. But I have no idea what to do. Ralf registers 0x52 to 0x59 can be found in Genesys_Sensor
[sane-devel] Canon LIDE 90
Ralf Haueisen schrieb: Ralf Haueisen schrieb: Hi all. I am just working to get my Canon LiDE 90 working. I took in the genesys_devices.c the LiDE60 an did some changes. I have a sniffer log taken with usbsnoop. Some registers i could firgue out where to set them. The image still looks like data is somehow scrambled. There are some setting in the file for the DAC. (static Genesys_Frontend Wolfson[] ) to which registers do these data belong? TIA, Ralf The settings in the Genesys_Frontend structs go to the analog frontend via the serial interface at registers 0x3a/0x3b(FEWRDATA)+0x51(FEWRA), through sanei_genesys_fe_write_data. If you are receiving noise data, this may indicate that the byte order was swapped. You should check that the parallel interface to the frontend is setup correctly(registers 0x52 to 0x57). HTH, Pierre I can see a strcture in scan direction but if in directon of the senor anything is semared out and noisy, just like i get an average value. Can you send a small image?
[sane-devel] Canon LIDE 90
Ralf Haueisen schrieb: Can you send a small image? The image shows the cover of a book... This looks like the shading correction(corrects for the properties of each ccd cell) is making the image worse. please disable it by changing gl841_init_optical_regs_scan to only disable it: /*if (flags OPTICAL_FLAG_DISABLE_SHADING)*/ r-value = ~REG01_DVDSET; /*else r-value |= REG01_DVDSET;*/ The resulting image may give better information. Another possibility is to look at the generated black_white_shading.pnm when SANE_DEBUG_GENESYS=255 is set in the environment.
[sane-devel] Timetable for sane-backends 1.0.19
Volker Grabsch schrieb: On Fri, Nov 16, 2007 at 10:24:05AM -0500, m. allan noah wrote: This is the proposed timetable for the release of sane-backends 1.0.19: 2008-01-06 Feature freeze 2008-01-20 Code freeze 2008-02-03 Release [...] If there are any new backends that should be included in that release and haven't been committed to CVS yet, please tell us NOW. We will endeavour to help new backend authors get their code included. What about the experimental backend drivers? I'm especially interested in the new genesys backend. When will it move from the experimental CVS to the backend CVS? What does this move depend on? How can I help? Is there any site that shows the current state of this backend? Do you mean the genesys or the genesys-new directory? The changes from genesys are mostly integrated into the current cvs, minus the settings for the LiDE 35/50/60 as those still need some tweaking. Oh, and the source files in genesys/ are a bit outdated compared to genesys/power-mode. The files in genesys-new have not been touched since they have been imported. Regards, Pierre
[sane-devel] Timetable for sane-backends 1.0.19
Pierre Willenbrock schrieb: Volker Grabsch schrieb: On Fri, Nov 16, 2007 at 10:24:05AM -0500, m. allan noah wrote: This is the proposed timetable for the release of sane-backends 1.0.19: 2008-01-06 Feature freeze 2008-01-20 Code freeze 2008-02-03 Release [...] If there are any new backends that should be included in that release and haven't been committed to CVS yet, please tell us NOW. We will endeavour to help new backend authors get their code included. What about the experimental backend drivers? I'm especially interested in the new genesys backend. When will it move from the experimental CVS to the backend CVS? What does this move depend on? How can I help? Is there any site that shows the current state of this backend? Do you mean the genesys or the genesys-new directory? The changes from genesys are mostly integrated into the current cvs, minus the settings for the LiDE 35/50/60 as those still need some tweaking. Oh, and the source files in genesys/ are a bit outdated compared to genesys/power-mode. I forgot to mention genesys/calibration-cache is completely experimental and not tested on anything other than my Canon LiDE 35. The files in genesys-new have not been touched since they have been imported. Regards, Pierre
[sane-devel] Canon LIDE 90
Ralf Haueisen schrieb: -Urspr?ngliche Nachricht- Von: Pierre Willenbrock pierre at pirsoft.dnsalias.org Gesendet: 27.11.07 22:23:19 An: Ralf Haueisen ralf.haueisen at web.de CC: sane-devel at lists.alioth.debian.org Betreff: Re: [sane-devel] Canon LIDE 90 Ralf Haueisen schrieb: Can you send a small image? The image shows the cover of a book... This looks like the shading correction(corrects for the properties of each ccd cell) is making the image worse. please disable it by changing gl841_init_optical_regs_scan to only disable it: /*if (flags OPTICAL_FLAG_DISABLE_SHADING)*/ r-value = ~REG01_DVDSET; /*else r-value |= REG01_DVDSET;*/ The resulting image may give better information. Another possibility is to look at the generated black_white_shading.pnm when SANE_DEBUG_GENESYS=255 is set in the environment. It is not the shading. Well, it does look better. My current guess: either some gpio is incorrect, or the sensor needs some other clock settings. The noise may stem from too few light or the data bytes from the frontend are swapped. The sensor does not seem to switch the read out pixel, but it does capture line data, so you end up with the first pixel over and over again. First, i'd make sure that i actually get the most significant byte from the frontend(by trying the possible byte positions in register 0x52) if you get a noise free image from the scanner, you got the msb right. The lsb is not that important at the moment(It would be the byte position where you get a different noisier image). The correct msb may be very dark(not 0 though), you are scanning pixels that are under the scanner cover). Then i'd try to find out which of the clock/gpio registers needs to be set. An usb log may reveal this. Hope this helps, Pierre
[sane-devel] Genesys driver for CanoScan LiDE 90
Hi Volker, Volker Grabsch schrieb: Dear Sane Developers, I just started to analyze my scanner CanoScan LiDE 90. I'm using the current sane-backends tools (CVS version) with the experimental genesys drivers (CVS version). According to sane-find-scanner it contains a GL842 chipset. However, the genesys driver have only support for GL841. So I decided to try this driver and extended the genesys driver. Iirc, the gl841 and gl842 use the same register set. My changes are very primitive (see the attached patch). I just copied the entries from lide-50 and adjusted some values. But at least it makes the scanner move. There are some strange delays, but after c. 20 seconds the scanner starts. It is able to tun a preview and a real scan, at least the scanner's motor is moving as if it would scan. However, it returns always just a black image instead of the paper I'm scanning. The delays are caused by failing calibration of the optical parameters, because the gl842 chip only receives black data from the analog frontend. You need to find the correct parameters for the frontend and the correct gpio-setup, especially for the half-resolution mode of the sensor. To get this information, you need to get an usb log from the windows driver of a low resolution(for example preview) and full resolution scan. The scanned area can be very small. To take the log, i recommend using usbsnoop: http://benoit.papillault.free.fr/usbsnoop/ For some more information see my previous message about the CanoScan LiDE 90: http://lists.alioth.debian.org/pipermail/sane-devel/2007-September/019945.html Is there any genesys hacker or any genesys documentation about how to add support for a new scanner to that driver? Is the experimental genesys driver still in active development? Hope that helps, Pierre
[sane-devel] GL646
stef schrieb: Le Saturday 10 November 2007 07:48:52 stef, vous avez ?crit : Le Friday 09 November 2007 11:57:57 Pierre Willenbrock, vous avez ?crit : Hi list, i need someone with a gl646-based scanner to test the attached patch. It is my solution for problems on e.g. arm system which align byte values on 2 byte boundaries, without resorting to attribute((packed)). The dirty byte in Genesys_Register_Set is just for testing purposes and will not be committed. Thanks in advance, Pierre Hello, I'll give it a try this weekend, I'll tell you about what it gives. Regards, Stef Hello, I've applied it and tested locally with my MD6471. The few scans I did were OK. So I think it can be check-in in CVS gl646-wise. Regards, Stef Hi Stef, if that patch had failed, it would have failed very early. Thank you for testing, Pierre
[sane-devel] GL646
Hi list, i need someone with a gl646-based scanner to test the attached patch. It is my solution for problems on e.g. arm system which align byte values on 2 byte boundaries, without resorting to attribute((packed)). The dirty byte in Genesys_Register_Set is just for testing purposes and will not be committed. Thanks in advance, Pierre -- next part -- A non-text attachment was scrubbed... Name: bulk_write_register_api.diff Type: text/x-patch Size: 15532 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071109/966bbad7/attachment.bin
[sane-devel] Troubles with genesys backend
Mohammad Tabbara schrieb: Hi all, I've installed backends 1.0.18 on debian etch on arm and have a Canon Lide 50 attached that is detected by the backend but results in a seg fault when trying to scan. I've tried the various combinations of the following: pre-built debian packages (apt-get install) cross-compiled tar balls of sane and CVS copies (including building libusb myself) a Cirrus Logic ARM board as well as a Samsung ARM board kernels 2.6.13 - 2.6.23 scanner connected directly and through a powered USB hub (in case the embedded boards can't source enough power) and I always wind up with a segfault which gdb reports as occurring in sanei_gl841_init_cmd_set . A (gzipped) log file is attached. It seems like this isn't something that's isolated: http://www.nslu2-info.de/showthread.php?p=27052 Any ideas on what may be causing trouble on ARM linux? Please try the attached patch and talk back if it does or doesn't work. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: arm-fix.diff Type: text/x-patch Size: 1990 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071013/9bd9a83c/attachment.bin
[sane-devel] Help with Canon LiDE 90 (GL842)
kent whitten schrieb: I'm trying to get this going, and could use any hints what the gpio pins might be used for. This guy has lots more pins set for output, than any other genesys device. I'm actually scanning, but getting nothing back but zeros, so I'm taking all 200 passes in calibrate_offsets, then getting a black page. All of my traces are caught on a CATC anaylzer, and there is another scanner here in pieces, if I can answer any questions. Thanks Kent Hi Kent, try to capture an usb log using a windows os. That should give the correct gpio setup or setup sequence. At least the 35/50 needs a special gpio sequence to get the lamp etc. to work(else it would just reset itself when trying to directly set the gpio pins..). Assigning a meaning to a pin then is mostly guesswork, but can be sped up by searching the pcb for the gpio wires. I could think of making a single gpio pin continually change its output state and then searching for it. I collected some scripts from my efforts in getting the LiDE 35 to work here: http://pirsoft-dsl-dropzone.de/ This one is not linked, but may be useful to you: http://pirsoft-dsl-dropzone.de/canon-lide35.tbz2 it is my stand-alone scanning test program. Regards, Pierre
[sane-devel] A Question about USB sniffer logs (SnoopyPro) / windows' USB system
Ren? Kjellerup schrieb: Hi' all, Now I've made a few logs, and I've come across something odd. I start the sniffer, then open the preview/scanning interface from my photo editor (PS7). And when it's running, the sniffer just stops getting any more packets even when scanning an image of say 1x1cm at 100dpi. I can even change to another setting and scan that and still no aditional packets are seen by the sniffer. Can Windows force to go around the sniffer and somehow communicate with the scanner directly in some way? SnoopyPro has a buffer size limitation making it unable to receive packets above a certain size. If it receives a large packet, it stops logging. Try this one: http://benoit.papillault.free.fr/usbsnoop/ Doesn't have a pretty gui for log analysis, but exports every part of the packet into a textual log file(SnoopyPros xml output is just useless). Regards, Pierre
[sane-devel] gl843 genesys backend
Hi Igncio, J. Ignacio Gij?n schrieb: Sorry if you receive this message twice, I sent a similar one yesterday but it looks like it is lost. It is right there. My question es about the HP G4050 scanner that uses a gl843 chip. I have had one of this for a couple of weeks now, and have been playing a bit with the genesys backend and some captures with an usb sniffer. The chips I've been able to identify in this scanner are: Usb chip: gl843 Motor: allegro a3967 slbt AFE: wolfson WM8196 scds Memory: atmel 628 93c46 I've done some changes to the gl841 part of the genesys backen to initialize the extra registers of the gl843, change the way the motor tables are loaded (different to the gl841) and all the things I've found that need to be changed in some hours reading the genesys code. Right now I have basic communication with the scanner, but the motor moves very slow, I've read several messages in the archives of the list about the configuration of the structures of the genesys backend and I think that the configuration is more or less ok. And I'm not able to get a image although I don't see errors in the logs (SANE_DEBUG_GENESYS_GL841=255) A moving motor is a good first step, that means the gl843 is basically doing it's job as instructed, and the hardware does not have too special power management features(ever needed to switch gpio pins in a certain order, else the scanner shortcircuits itself and resets?). What you are running into is the complete lack of ccd-support in the gl841 part. Currently, only cis-mode is implemented. You need to collect the register settings for the clock registers, setup the lamp pwm properly and set the scanner into ccd-mode. If i didn't forget some part, that is. Probably the motor and the gpio parts are wrong. don't worry with the motor. that should be easy to improve. So my question is, have somebody done something to support the gl843? I've read somethings in the archives about some canon scanners using this chip, but have found nothing to look. To my knowledge, there is no previous work for the gl843. Regards, Pierre
[sane-devel] Canon LIDE35 color and motor issues
Pierre Willenbrock schrieb: Luke Campagnola schrieb: It's been a while since I originally brought this up, but I've pulled out the ol' scanner for another go. to recap: color calibration isn't quite right on my canon lide35--the dark colors drop out to black. I turned on SCAN_FLAG_DISABLE_SHADING as you instructed, and as you predicted this recovered my lost dark colors. Where should I go from here? Should I crank up SANE_DEBUG_GENESYS and send you the scanimage output and *.pnm files? Thanks, Luke Hi Luke, Did you try with sane from cvs? There have been some bug fixes. If that does not show the dark colors, use SANE_DEBUG_GENESYS=255 and SANE_DEBUG_GENESYS_GL841=255 with scanimage in color mode, and send the resulting error output and the generated .pnms. Regards, Pierre The patch i attached will not apply -- try this one instead. On 3/7/06, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: - Color reproduction is better with the sane driver than the windows driver, which tends to boost the reds way too much (yaay) - Brightness reproduction is quite poor with the sane driver. It seems that darker colors just drop off to black very quickly. A better tool to determine if the bright and dark colors are correctly reproduced is a histogram tool. You can clearly see, if there is still room at the bottom and top of the histogram(not too much, as you still want some useable color values ;-)). This reveals that dark colors are cut off for the sane driver, but it also shows that the windows driver cuts off bright colors. Anyway, it shows a incorrect calibration on the sane side. snip To get an unshaded image, you can disable shading correction in gl841_init_regs_for_scan by changing the flags(last parameter to gl841_init_scan_regs, currently 0) to include SCAN_FLAG_DISABLE_SHADING. If the image then still shows dark colors cut off, the offset/exposure calibration is to blame. Otherwise the shading calibration calculates incorrect data(which i suspect). I should put this lengthy description online somewhere.. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: new-calib.patch Type: text/x-patch Size: 14689 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070114/b08c478c/new-calib-0001.bin From olaf.meeuwis...@avasys.jp Mon Jan 15 00:56:42 2007 From: olaf.meeuwis...@avasys.jp (Olaf Meeuwissen) Date: Mon Jan 15 00:57:42 2007 Subject: [sane-devel] Re: Epson V350 PHOTO ? In-Reply-To: 25592666.60937f96.45a76833.62...@o2.pl (piotr n.'s message of Fri, 12 Jan 2007 11:51:31 +0100) References: 20070108230338.gj3...@abridgegame.org 2007031322.436e35b5@inspiron 877ivtyw0q@geek.avasys.jp 25592666.60937f96.45a76833.62...@o2.pl Message-ID: 87wt3pqi11@geek.avasys.jp piotr_n piot...@o2.pl writes: Hi, Hi, I,ve read notes about troubles with an Epson V100 working with linux. To sum up it seems not working with this system perfectly. As a potential buyer of Epson V350 I'd like to ask if this model has or hasn't problem with linux. My question is about full support this scanner by sane system (or other) as a model with different chip (GT-F700) in contrast to V100 (GT-F650) AFAIK, the V350 as well as the V100 are only supported via iscan's epkowa backend. Both require a binary-only non-free plugin that is only available for i386 machines. If you can live with that, the V350 works under linux. # The GT-F700 and GT-F650 are the model names for the Japanese market. # They do not refer to the chipset. Hope this helps, -- Olaf Meeuwissen EPSON AVASYS Corporation, SE1 FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2
[sane-devel] Canon LIDE35 color and motor issues
Hi Luke, I did rewrite some parts of the calibration, so there may be some improvements/regressions. Please test the attached patch, it applies against current cvs. I only need the stderr output this time. Try 75 dpi and 1200 dpi, they use different ccd-modes. As you very probably already realized, the sane-devel list has a mail size limit of 50kb(*6/8 for binary data). If the (compressed)log is larger than that, please reply only to me. Regards, Pierre Luke Campagnola schrieb: I actually hadn't tried CVS, which was silly, but it turns out the problem is a little worse there.. the darks may be slightly better but now the lights are clipped too. I've attached output + pnms. Thanks. On 1/4/07, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: Luke Campagnola schrieb: It's been a while since I originally brought this up, but I've pulled out the ol' scanner for another go. to recap: color calibration isn't quite right on my canon lide35--the dark colors drop out to black. I turned on SCAN_FLAG_DISABLE_SHADING as you instructed, and as you predicted this recovered my lost dark colors. Where should I go from here? Should I crank up SANE_DEBUG_GENESYS and send you the scanimage output and *.pnm files? Thanks, Luke Hi Luke, Did you try with sane from cvs? There have been some bug fixes. If that does not show the dark colors, use SANE_DEBUG_GENESYS=255 and SANE_DEBUG_GENESYS_GL841=255 with scanimage in color mode, and send the resulting error output and the generated .pnms. Regards, Pierre On 3/7/06, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: - Color reproduction is better with the sane driver than the windows driver, which tends to boost the reds way too much (yaay) - Brightness reproduction is quite poor with the sane driver. It seems that darker colors just drop off to black very quickly. A better tool to determine if the bright and dark colors are correctly reproduced is a histogram tool. You can clearly see, if there is still room at the bottom and top of the histogram(not too much, as you still want some useable color values ;-)). This reveals that dark colors are cut off for the sane driver, but it also shows that the windows driver cuts off bright colors. Anyway, it shows a incorrect calibration on the sane side. snip To get an unshaded image, you can disable shading correction in gl841_init_regs_for_scan by changing the flags(last parameter to gl841_init_scan_regs, currently 0) to include SCAN_FLAG_DISABLE_SHADING. If the image then still shows dark colors cut off, the offset/exposure calibration is to blame. Otherwise the shading calibration calculates incorrect data(which i suspect). I should put this lengthy description online somewhere.. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: new-calib.patch Type: text/x-patch Size: 20552 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070113/10afecf5/new-calib.bin From jante_n...@yahoo.co.uk Sat Jan 13 09:59:45 2007 From: jante_n...@yahoo.co.uk (John) Date: Sat Jan 13 10:07:04 2007 Subject: [sane-devel] Frontend for film scanners Message-ID: 20070113085945.70026.qm...@web86912.mail.ukl.yahoo.com I have a Minolta dimage III positive film scanner, which can take 4 positive frames at once. I have not been able to find any good software to use with this scanner. Does anyone have a good hint? Preferably I would like to have a piece of software that lets me preview all 4 frames and on a buttonpress scans the four pictures, make some digital processing to improve the quality and saves them to a directory I have choosen and ejects the frameholder and waits for me to repeat the procedure. Would this be hard to do with sane, given that the frameholder must be positioned for individual scans, or is it perpaps just treated as x and y coordinates just as in a flatbed scanner case? - Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail. -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070113/f81f820a/attachment.html From e...@epo.dk Sat Jan 13 10:20:34 2007 From: e...@epo.dk (Erik P. Olsen) Date: Sat Jan 13 10:41:17 2007 Subject: [sane-devel] Frontend for film scanners In-Reply-To: 20070113085945.70026.qm...@web86912.mail.ukl.yahoo.com References: 20070113085945.70026.qm...@web86912.mail.ukl.yahoo.com Message-ID: 45a8a462.1060...@epo.dk John wrote: I have a Minolta dimage III positive film scanner, which can take 4 positive frames at once. I have not been able to find any good software to use with this scanner. Does anyone have a good hint? If you don't find support with sane you could try the commercial
[sane-devel] Canon LIDE35 color and motor issues
Luke Campagnola schrieb: It's been a while since I originally brought this up, but I've pulled out the ol' scanner for another go. to recap: color calibration isn't quite right on my canon lide35--the dark colors drop out to black. I turned on SCAN_FLAG_DISABLE_SHADING as you instructed, and as you predicted this recovered my lost dark colors. Where should I go from here? Should I crank up SANE_DEBUG_GENESYS and send you the scanimage output and *.pnm files? Thanks, Luke Hi Luke, Did you try with sane from cvs? There have been some bug fixes. If that does not show the dark colors, use SANE_DEBUG_GENESYS=255 and SANE_DEBUG_GENESYS_GL841=255 with scanimage in color mode, and send the resulting error output and the generated .pnms. Regards, Pierre On 3/7/06, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: - Color reproduction is better with the sane driver than the windows driver, which tends to boost the reds way too much (yaay) - Brightness reproduction is quite poor with the sane driver. It seems that darker colors just drop off to black very quickly. A better tool to determine if the bright and dark colors are correctly reproduced is a histogram tool. You can clearly see, if there is still room at the bottom and top of the histogram(not too much, as you still want some useable color values ;-)). This reveals that dark colors are cut off for the sane driver, but it also shows that the windows driver cuts off bright colors. Anyway, it shows a incorrect calibration on the sane side. snip To get an unshaded image, you can disable shading correction in gl841_init_regs_for_scan by changing the flags(last parameter to gl841_init_scan_regs, currently 0) to include SCAN_FLAG_DISABLE_SHADING. If the image then still shows dark colors cut off, the offset/exposure calibration is to blame. Otherwise the shading calibration calculates incorrect data(which i suspect). I should put this lengthy description online somewhere.. Regards, Pierre
[sane-devel] Plustek Optic Slim 2420
Maximilian Fabricius schrieb:
On 1/1/07, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote:
Maximilian Fabricius schrieb:
Hi all,
I have been working on trying to get the OpticSlim 2420 to work.
Is disassembled the scanner (hardware) and made pictures. they may be
found here
http://rosa.physik.tu-berlin.de/~mxhf/OS2420/
They are fairly high resolution ~1MB per image so that you can see all
details. lease excuse the German on the navigation bar.
This scanner has a Wolfson Micro WM8196 analog frontend, an ICSI
IC41LV16256-35K memory chip(256k 16bit words), LB1940 motor driver chip.
From this I learned that the scanner has a GL842 chip (not GL841). The
GL842 seems
to be very similar to the 841 though as a quick scan through the data
sheet revealed.
In fact, at least the things documented in genesys' datasheets are
identical.
So far I cloned the ST24 section in genesys_gl841 and
I got as far as being able to execute tstbackend without getting an
error.
I had to comment the Init_Devices lines 4990-4993 in genesys_gl841.c.
I am somewhat stuck now. Starting scanimage results in strange noise
from the scanner.
Try the motor struct i sent in the Canon-4400F thread[1].
Concerning your frontend settings, use the register state just before
the preview scan starts(which probably is urb 1367 in the log referenced
in [2]).
By the way: i am preferring usbsnoop[3], which dumps the usb log into a
plain text file, making parsing it way easier. Also, it does not stop
logging, when it encounters an urb larger than 16k or so(fortunately for
you, the plustek driver does not use that large urbs).
Regards,
Pierre
[1]
http://lists.alioth.debian.org/pipermail/sane-devel/2006-December/018335.html
[2]
http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018338.html
[3]
http://benoit.papillault.free.fr/usbsnoop/
Thanks Pierre,
I am currently playing around with the frontend. I tried setting it to
the values I got from my log.
Hi Maximilian,
some correction to the register mappings inline
-- SNIP SNIP ---
{{0x00, 0x27, 0x24, 0x0f}//reg[4]:0x00 - 0x03
, {0x00, 0x00, 0x0f}//sign[3]: 0x00 - 0x06
0x24 - 0x26
, {0x02, 0x01, 0x01}//offset[3]: 0x20 - 0x22
, {0xc4, 0xc8, 0xd2}//gain[3]: 0x28 - 0x2a
, {0x00, 0x00, 0x00}//reg2[3]
: 0x05, 0x06, 0x08
}
,/* OS2420 */
-- SNIP SNIP ---
I also used your motor struc.
So far the scanner starts moving the ... sled? And only the green
light is powered on. But the sled only moves for about a cm. Then it
starts making noise like a quiet machine gun.
Does it still move when making noise? If not, try increasing the step
times. The upper limit is 65535. You could also try to change the
maximum step mode to 0(only full steps allowed).
There may be issues with custom powermanagement features, controlled via
the gpio pins. Finding good settings for the gpio pins, or even what
function they control, can take a lot of experimentation.
I am not done playing around and haven't double checked my frontend
register values yet.
It might help to understand what they actually mean.
You can find the datasheet linked here:
http://www.wolfsonmicro.com/products/WM8196/
complete with register description.
Regards,
Pierre
[sane-devel] Plustek Optic Slim 2420
Maximilian Fabricius schrieb: Hi all, I have been working on trying to get the OpticSlim 2420 to work. Is disassembled the scanner (hardware) and made pictures. they may be found here http://rosa.physik.tu-berlin.de/~mxhf/OS2420/ They are fairly high resolution ~1MB per image so that you can see all details. lease excuse the German on the navigation bar. This scanner has a Wolfson Micro WM8196 analog frontend, an ICSI IC41LV16256-35K memory chip(256k 16bit words), LB1940 motor driver chip. From this I learned that the scanner has a GL842 chip (not GL841). The GL842 seems to be very similar to the 841 though as a quick scan through the data sheet revealed. In fact, at least the things documented in genesys' datasheets are identical. So far I cloned the ST24 section in genesys_gl841 and I got as far as being able to execute tstbackend without getting an error. I had to comment the Init_Devices lines 4990-4993 in genesys_gl841.c. I am somewhat stuck now. Starting scanimage results in strange noise from the scanner. Try the motor struct i sent in the Canon-4400F thread[1]. Concerning your frontend settings, use the register state just before the preview scan starts(which probably is urb 1367 in the log referenced in [2]). By the way: i am preferring usbsnoop[3], which dumps the usb log into a plain text file, making parsing it way easier. Also, it does not stop logging, when it encounters an urb larger than 16k or so(fortunately for you, the plustek driver does not use that large urbs). Regards, Pierre [1] http://lists.alioth.debian.org/pipermail/sane-devel/2006-December/018335.html [2] http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/018338.html [3] http://benoit.papillault.free.fr/usbsnoop/
[sane-devel] Re: Canon 4400F
Jaagup Rep?n schrieb:
Jaagup Rep?n wrote:
Hello.
I have Canon 4400F scanner. This is not supported, but it must to be
added to genesys backend. I am trying to add, but I need help. I
have to find SENSOR, DAC, GPO and motor type, shading and search lines,
start of scan area, white strip and black mark.
I forgot to say that I have USB sniffer log
file(http://jrepan.pri.ee/usbsnoop.log.decode) and I found some
information from
http://lists.alioth.debian.org/pipermail/sane-devel/2005-December/015750.html
I got frontend:
{{0x02, 0x20, 0x30, 0xdc}
, {0x32, 0x00, 0x03}
, {0x10, 0x32, 0xc8}
, {0xda, 0x00, 0x00}
, {0xf0, 0x00, 0x00}
Is this correct?
From your log i get this:
{{0x00, 0x23, 0x24, 0x2f}
, {0x00,0x00,0x00} //never set in log
, {0x60,0x60,0x60}
, {0xfa,0xfa,0xfa}
, {0x00,0x00,0x00} //never set in log
look for this sequence:
wrote 0x51 frontend register address
wrote 0x3b high bit of data
wrote 0x3a low bits of data
those are frontend register writes(at least in your log).
Regarding the Motor struct, this will probably work(without looking at
your log)
{
2400,
4800,
1,
{
12000,
12000,
1,
1.0
},
{
12000,
12000,
1,
1.0
}}
This should lead to very slow movements of the scanning head, but it
should move if the scanner is correctly initialized(the Canon LiDE
35/50/60 are a bit tricky, and the 500F seems to be similar).
As you can see, i use half of the real resolution here. The reason is,
the backend is not (yet) capable of using something other than 2400,
1200 or 600 as sensor resolution. In the meantime, we can make double
the scanner dimensions, to accommodate for the real 4800dpi.
The gl841 part of the backend also lacks support for non-LiDE color sources.
Hope that helps,
Pierre
[sane-devel] Missing greys
Hi Henrik Henrik Uggla schrieb: I've got a Canoscan Lide 50. I have discovered that when I scan at 150 dpi or more the greys are missing in depth (in the black end). But when I scan at only 75 dpi the result looks much better since darker and lighter pixels are mixed to show the right grey nuance. Is it possible to have this behaviour at higher resolutions as well and in that way creating those missing greys? I can't explain why there is a difference between calibration for 75dpi compared to 150dpi(You didn't scan them at different bit depth, i guess). But anyways, dark shades were incorrect since the beginning of Canon LiDE 50 support. I had some improvements to the calibration process sitting in my local copy since about 3 months, so i just committed them. You can get them from the cvs repository. Test results for the current method are welcome. Regards, Pierre
[sane-devel] Canon LiDE 70 support
Maik Musall schrieb:
Hi,
I'm newly subscribed here, and found just two postings about this
scanner in the archives. I purchased one today and am trying to get
support for it. So far, no success. I tried to just add a struct
canon_lide_70_model into genesys_devices.c by copying the lide_60 part
and only adjusting the resolutions and model names, and adding a line
{0x04a9, 0x221c, canon_lide_60_model},
into genesys_usb_device_list. After this, I added the usb data to
/etc/sane.d/genesys.conf, and then after compiling I get:
# scanimage -L
device `genesys:libusb:004:007' is a Canon LiDE 70 flatbed scanner
but scanning doesn't actually work:
# scanimage ~/file.pnm
scanimage: open of device genesys:libusb:004:007 failed: Invalid argument
The scanner doesn't show any reaction. I wonder if it's a GENE based one
at all. How do I find out? How can I help to get this supported? I have
14 days before I have to send it back if it doesn't work... ;-)
I'm using gentoo Linux 2.6.17-r8 and sane-backends 1.0.18-r2.
Here is the lsusb -v -v output's section about the scanner:
[...]
Regards
The scanimage -v -v output on this page:
http://www.sane-project.org/unsupported/canon-lide-70.html
says it is very probably not a genesys based scanner.
Regards,
Pierre
[sane-devel] Canon Lide 80, USB log
Aaron Lawrence schrieb: Hello all, [...] I used the awk and perl script on http://john.daltons.info/lide60/ to generate some output of plugging in the scanner, initializing and a 300dpi color scan. It was a while ago when I took the usb log but I believe I canceled the scan partway through. http://www.ford23.com/canon_lide_80/300dpi_color/00index.html Can you somehow give me access to the raw log? That way i should be able to create a test program replicating the behavior in the log to figure out which parts of the scanning process is missing. Private mail should be possible, if your web server does not allow you to upload such large amounts of data. Alternatively i can setup a ftp server. Regards, Pierre
[sane-devel] LiDE 500F: how to go further?
Hi Ralph, Ralph Sontag schrieb: These scanners are pretty low-level. To do anything useful, you need to setup the motor and ccd. This includes calibration. The calibration is done only once in win98. So I will setup win98 once again and made a start the sniffer before the first connect. I put my scripts here: http://pirsoft-dsl-dropzone.de Fine - but I got a error 403: Forbidden for http://pirsoft-dsl-dropzone.de/usbsnoop-stage1.pl http://pirsoft-dsl-dropzone.de/usbsnoop-collect.pl Can you send me the files or made it available? I didn't check the permissions after upload, sorry. Should be available now. After patching with the new patch, the scanner ist jerking in a frequency around 30 Hz, but it make no move. So, there is still something missing. I will try to create another patch during this week. Regards, Pierre
[sane-devel] LiDE 500F: how to go further?
Hi Ralph, Ralph Sontag schrieb: Hi Pierre, I put my scripts here: http://pirsoft-dsl-dropzone.de I made a new scan: 0 .. ~ 5 MB : USB starts 5 .. ~ 15 MB : ScanGear - the Canon-Program starts 15 .. ~ 110 MB : Calibration. 110 .. ~ 200 MB : Scan (visiting card, 300, ca. 1.5 MB) 200 .. ~ 215 MB : ScanGear ends So I have 215 MB raw log file, and after running the scripts 168.8 MB. I've put it to http://www-user.tu-chemnitz.de/~sontag/sane/ (bzip2, 21 MB). It's very usefull to pipe the file in uniq -c - it enlarges the size, but we can jump over the block of identical lines. Didn't know about uniq. Thanks for the hint. At first lot of blocks of 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, are read. Not exactly. First the driver fills main memory with 0x55, (BULK means bulk output), each time preparing the bulk-transfer with a buf_prepaccess. Then it reads all the memory back in one read(scattered over multiple usb bulk in packets, BULK). The same for 0xaa. Just the driver checking the memory. The write register for main memory is 0x3c, the read register is 0x45. It does the same for gamma memory. Similar for some registers. But the accesses before this are interesting, too. The driver fiddles with the gpio pins, which may be the key to get the scan head moving. The last of this blocks ends at line 65433, then the scanner starts writing blocks: write_register(0x00) set_write_register(0x2b, 0x00) set_register(0x3c) buf_prepaccess(0xf000,BULK_OUT) Data: 01 00 82 00 00 f0 00 00 Index: 0 BULK(61440) 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, ... next block around line 73122: 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, buf_prepaccess(0xf000,BULK_OUT) Data: 01 00 82 00 00 f0 00 00 Index: 0 BULK(61440) 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, This repeats 4 times until line 98226: 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, set_write_register(0x2a, 0x00) set_write_register(0x2b, 0x00) set_register(0x45) buf_prepaccess(0x00040002,BULK_IN) Data: 00 00 82 00 02 00 04 00 Index: 0 BULK(65024) 0xeb, 0xff, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, - and I think, here the calibration starts with setting registers and write data. But I can'nt interprete these registers ... Datasheets can be downloaded here: http://www.genesyslogic.com/ Also try the other languages. At least for one gl84x there is a datasheet available on one of the non-english pages, but not on the english pages. It is currently not clear to me, which chip is in your scanner. Regards, Pierre
[sane-devel] LiDE 500F: how to go further?
Hi Ralph, Ralph Sontag schrieb: first I want to thank for the help and the information. I put my data on http://www-user.tu-chemnitz.de/~sontag/sane/ Please try the attached patch. It may already get scanimage past initialization. If not, please also send a debug log without win98 initialisation. OK, first time after patching the scanner makes terrible noise ... :-) It clatters very much ... A scan does'nt start. After replug the scanner croons, bot does nothing. Your scanner is 2400dpi x 4800dpi? Perhaps the attached patch is more usable. It reduces the maximum speed of the head, and adjusts the maximum y-resolution. I make some new logs, but where ends the win98-initalisation? See below ... These scanners are pretty low-level. To do anything useful, you need to setup the motor and ccd. This includes calibration. The calibration is done only once in win98. If you want to, i can send you some perl scripts and instructions on how to use them. I don't understand all details of the protocol, so there are some unknowns. I found some scripts under http://john.daltons.info/lide60/ If you have some scripts for the LIDE500F, they are welcome. But the scripts from John Dalton produce also some usefull information. I've put the raw files and the analysis with these scripts to http://www-user.tu-chemnitz.de/~sontag/sane/ (actual the last for lines: usblog-xp/00index.htmlanalysed files from XP 500 k 8. 5. 2006 usbsnoopxp.bz2raw file from XP770 k 8. 5. 2006 usblog-w98/00index.html analysed files from W98 450 k 8. 5. 2006 usbsnoopw98.bz2 raw file from W98 2.1 M 8. 5. 2006 ) These analyses seem to be not very useful. I see a lot of unknowns where there should be register reads/writes. I put my scripts here: http://pirsoft-dsl-dropzone.de How can I see, where the nessesary information starts? Then I can cut the parts before ... There shouldn't be a lot of windows logs needed. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: canon-500f.diff Type: text/x-patch Size: 26419 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060512/6ada0c43/canon-500f-0001.bin From pie...@pirsoft.dnsalias.org Fri May 12 21:18:52 2006 From: pie...@pirsoft.dnsalias.org (Pierre Willenbrock) Date: Fri May 12 21:19:09 2006 Subject: [sane-devel] LiDE 500F: how to go further? In-Reply-To: 4464fa2d.8060...@pirsoft.dnsalias.org References: 200605021417.39020.chri...@attglobal.net 200605021830.56197.chri...@attglobal.net pine.lnx.4.61.0605021338560.19...@limos.pfeiffer.edu 200605032139.27907.chri...@attglobal.net pine.lnx.4.61.0605041002530.14...@catan.informatik.tu-chemnitz.de 445d1051.5050...@pirsoft.dnsalias.org pine.lnx.4.61.0605081140090.7...@catan.informatik.tu-chemnitz.de 4464fa2d.8060...@pirsoft.dnsalias.org Message-ID: 4464fbbc.2040...@pirsoft.dnsalias.org Sorry, forgot to remove the configure-changes from the diff. -- next part -- A non-text attachment was scrubbed... Name: canon-500f.diff Type: text/x-patch Size: 3570 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060512/d242e95a/canon-500f.bin From da...@hddesign.com Fri May 12 23:46:57 2006 From: da...@hddesign.com (Damon Butler) Date: Fri May 12 23:47:48 2006 Subject: [sane-devel] HP ScanJet 5300c only partially detected In-Reply-To: 20060511161114.gb18...@meier-geinitz.de References: 44633fec.7040...@hddesign.com 20060511161114.gb18...@meier-geinitz.de Message-ID: 44651e71.1040...@hddesign.com Try SANE_DEBUG_AVISION=255 scanimage -L (or whatever is needed to set environment variables on MacOS X). You should get debug messages like this: [sanei_debug] Setting debug level of avision to 255. [avision] sane_init:(Version: 1.0 Build: 182) [...] If this doesn't happen, try: SANE_DEBUG_DLL=255 scanimage -L and send the output. I set both environment variables, and here's the output I got. - % sudo scanimage -L [sanei_debug] Setting debug level of dll to 255. [dll] sane_init: SANE dll backend version 1.0.11 from sane-backends 1.0.17 [dll] sane_init: reading dll.conf [dll] add_backend: adding backend `net' [dll] add_backend: adding backend `abaton' [dll] add_backend: adding backend `agfafocus' [dll] add_backend: adding backend `apple' [dll] add_backend: adding backend `avision' [dll] add_backend: adding backend `artec' [dll] add_backend: adding backend `artec_eplus48u' [dll] add_backend: adding backend `as6e' [dll] add_backend: adding backend `bh' [dll] add_backend: adding backend `canon' [dll] add_backend: adding backend `canon630u' [dll] add_backend: adding backend `coolscan' [dll] add_backend: adding backend `coolscan2' [dll] add_backend: adding backend `dmc' [dll] add_backend: adding backend `epson' [dll] add_backend: adding backend `fujitsu' [dll
[sane-devel] USB speed
Hi list, i am trying to make the scanning speed of my scanner depend on the usb speed available. I first attempted to use the detection from the cs3200f backend, but found that it only detects if the device is high speed capable, not if it is currently communicating with high speed. On further investigation i found that there are two ways to determine the used speed on linux: * The first one involves an ioctl, which needs an file descriptor of the device. I cannot see any way to get the fd from libusb. * The second one is looking at /proc/bus/usb/devices, parsing the T-lines. This only needs the device number and the bus number, which can be obtained from libusb. The attached patch adds a function to sanei_usb which adds a function determining the usb speed. Currently, it only reports speeds when using libusb on Linux. I tested this on Linux 2.6.16. Any objections to this approach? Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: usb-speed.diff Type: text/x-patch Size: 4686 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060506/7705d805/usb-speed.bin From j...@jblache.org Sat May 6 19:40:43 2006 From: j...@jblache.org (Julien BLACHE) Date: Sat May 6 19:40:59 2006 Subject: [sane-devel] Negs Scanning Pure Red In-Reply-To: 200605061000.55912.i...@quantum-sci.com (Quantum Scientific's message of Sat, 6 May 2006 10:00:55 -0700) References: 200605061000.55912.i...@quantum-sci.com Message-ID: 87lktfaqmc@frigate.technologeek.org Quantum Scientific i...@quantum-sci.com wrote: Hi, Running Debian Linux, Gimp for photo editing, and XSane with the Microtek2 profile for scanning, and Sane 1.0.15. You can try to upgrade SANE (and XSane maybe) using the Sarge backports maintained by Aur?lien Jarno. See http://people.debian.org/~aurel32/ for instructions. JB. -- Julien BLACHE http://www.jblache.org j...@jblache.org GPG KeyID 0xF5D65169
[sane-devel] LiDE 500F: how to go further?
Hi Ralph, Ralph Sontag schrieb: I have an Canon CanoScan LiDE 500F. I've added in backend/genesys_devices.c a section as a copy from the LiDE 60 - ok, now scanimage list the device: scanimage -L device `genesys:libusb:001:050' is a Canon LiDE 500F flatbed scanner But it don't work. The LiDE 35/40/50/60 are very similar(not to say they have identical hardware). Your LiDE 500f on the other hand has some differing properties. I have a Windows 98 running in qemu. The scanner works in this emulator- environment, an I got some debug-messages with usbsnoop: http://www-user.tu-chemnitz.de/~sontag/sane/usbsnoop.log.1.gz I only decoded the above log. It looks like a calibration run. First the driver does some tests on the registers, then on the memory. After this, it does the calibration. This should be enough to make the scanner deliver data using scanimage. http://www-user.tu-chemnitz.de/~sontag/sane/usbsnoop.log.2.gz This are scans with color, 300 dpi. _After_ working with qemu also scanimage will produce output: http://www-user.tu-chemnitz.de/~sontag/sane/scanimage-scan-grey.png scanimage then also produces log-files: http://www-user.tu-chemnitz.de/~sontag/sane/scanimage-debug.log Without initialisation under W98, the scanner don't work with scanimmager - so it seems, there is at first a problem during initialisation. It hangs at [genesys] sanei_genesys_read_register (0x41, 0xf0) completed Please try the attached patch. It may already get scanimage past initialization. If not, please also send a debug log without win98 initialisation. At second the data is wrong: the picture shows only noise. This is to be expected. The AFE(Analog FrontEnd) chip is not initialised correctly and the gl841 probably latches digital data at wrong times. To further complicate this, your scanner uses a CCD-chip, while mine has a CIS. I have not enough experience to interprete the log-files, so I ask, what to do next. If you want to, i can send you some perl scripts and instructions on how to use them. I don't understand all details of the protocol, so there are some unknowns. I will try to get some debugging-output with Windows XP and will try to start usbmon for debugging with linux. At least i don't need logs from linux. The sane backend already dumps most of the relevant information, and does a lot things different to the windows drivers. Logs from win98 are as good as from winxp. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: canon-500f.diff Type: text/x-patch Size: 3312 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060506/2ca88d11/canon-500f.bin From i...@quantum-sci.com Sat May 6 21:15:57 2006 From: i...@quantum-sci.com (Quantum Scientific) Date: Sat May 6 21:17:38 2006 Subject: [sane-devel] Negs Scanning Pure Red In-Reply-To: 87lktfaqmc@frigate.technologeek.org References: 200605061000.55912.i...@quantum-sci.com 87lktfaqmc@frigate.technologeek.org Message-ID: 200605061415.58789.i...@quantum-sci.com Thanks. This does help a bit. But it seems this pure red for very black is intended as a warning that blacks are crushed. I know they're crushed, and I need to recover them as best as possible. This red crap just makes for hours of repair work to remove it. On Saturday 06 May 2006 12:40, Julien BLACHE wrote: Quantum Scientific i...@quantum-sci.com wrote: Hi, Running Debian Linux, Gimp for photo editing, and XSane with the Microtek2 profile for scanning, and Sane 1.0.15. You can try to upgrade SANE (and XSane maybe) using the Sarge backports maintained by Aur?lien Jarno. See http://people.debian.org/~aurel32/ for instructions. JB.
[sane-devel] Genesys, Canon LiDE 35/40/50/60
Gerald Murray schrieb: Quoting Pierre Willenbrock pie...@pirsoft.dnsalias.org: Hi Gerald, Gerald Murray schrieb: Tested: LiDE 35: 150,300,600,1200 using usb-1.1. --snip-- That is probably a calibration problem. There is no easy way to fix that. What helped Henning was to clean the calibration area. The backend is currently not able to cope with (much) dirt there. You can get a distorted raw scan of the calibration area by enabling debugging. That should give you a file named black_white_shading.pnm. When scanned at the higher resolutions(=600dpi), it should have vertically striped area(s), but only very few dirt particles. I have not figured out how to clean the calibration area. There was no instructions that came with the scanner. Is there some guide to how to take the parts apart? There is one possible plastic hook pair on the bottom, but it looks like a manuafacturer-only access point, requiring a special tool. Then i guess you need to live with the vertical stripes. But please send the black_white_shading.pnm from a 1200dpi scan so i can try to find a better calibration algorithm. Also a few slices across the image, possibly from a jerk of the head at that point in the scan. On the whole, an acceptable image. Did this happen because the scanner moved the head back to restart at the buffer overflow position? If that is the case, i need to do some more tuning on the acceleration tables. That should definitely not happen(Though it is no reason not to put the code into sane-backends). It happened at 10 cm of an 11cm postcard scan. The scanner does quite a bit of shuffling, and I thought it might be related to that forward/reverse timing in the shuffle. I guess that did not happen all the time at the same position? HP2400: no change, not working. Not working as in refuses to move head/deliver useful data or as in provides a 2400x1200dpi image? For the latter case i do have a patch, enabling a nearest match interpolation. The head never moves. It goes into a calibration at the beginning, and never completes the calibration correctly, and then times out with a question on the lamp: [genesys] genesys_warmup_lamp: warmup timed out after 46 seconds. Lamp defective? scanimage: sane_start: Error during device I/O Sorry, misread HP2400 to be 2400 dpi.. Regards, Pierre
[sane-devel] Genesys, Canon LiDE 35/40/50/60
Hi Gerald, Gerald Murray schrieb: Tested: LiDE 35: 150,300,600,1200 using usb-1.1. Motor ok. Scans at 150,300 are excellent quality. At 600, 1200 minor image flaws: there is faint but noticable streaks down the longest length of the image, from color reception or brightness not being quite right. That is probably a calibration problem. There is no easy way to fix that. What helped Henning was to clean the calibration area. The backend is currently not able to cope with (much) dirt there. You can get a distorted raw scan of the calibration area by enabling debugging. That should give you a file named black_white_shading.pnm. When scanned at the higher resolutions(=600dpi), it should have vertically striped area(s), but only very few dirt particles. Also a few slices across the image, possibly from a jerk of the head at that point in the scan. On the whole, an acceptable image. Did this happen because the scanner moved the head back to restart at the buffer overflow position? If that is the case, i need to do some more tuning on the acceleration tables. That should definitely not happen(Though it is no reason not to put the code into sane-backends). HP2400: no change, not working. Not working as in refuses to move head/deliver useful data or as in provides a 2400x1200dpi image? For the latter case i do have a patch, enabling a nearest match interpolation. Thanks for testing, Pierre
[sane-devel] Genesys, Canon LiDE 35/40/50/60
Hi, Parag N() schrieb: Is that experimental module can be used with HP 2400 scanner also? It can be used for development and other experimental code. So, yes, the experimental cvs module can be used for developing support for the HP 2400 scanner. But no, there is no code supporting the HP 2400 scanner, yet. Regards, Pierre
[sane-devel] Genesys, Canon LiDE 35/40/50/60
Hi List, as some of you may have noticed, the genesys backend now has the ability to set a motor power level, leading to much quieter scans in high dpi modes(if it is implemented for the scanner). This feature is currently available in the experimental module, as the settings for this new mode need some more testing on scanners other than mine. So, if you own a scanner of the Canon LiDE 35/40/50/60 series, please try the code from the experimental module. The low power mode is used when scanning at resolutions =600dpi, and during calibration. Errors are most likely when the scanner does a fast feed to the scanning area. Also, it would be good if someone owning a gl646 based scanner tests the code, as the gl646 part tends to break whenever i change something :( Regards, Pierre
[sane-devel] Canon Lide 50 (Genesys) - Added threshold for BW (lineart)
Laurent Charpentier schrieb: I would like to submit a patch for the genesys backend (Canon LIDE 50). The patch adds the threshold feature for black/white mode (in 1.0.17 the threshold is set to 50% and can't be changed). The attached patch is relative to sane-backends-1.0.17 (files genesys.c, genesys.h, genesys_gl841.c, genesys_low.h). Thank you to apply this patch. It is in cvs now, with a little cleanup. I also made the software lineart conversion for gl646 use this threshold. Regards, Pierre
[sane-devel] Canon Lide 50 (Genesys) - Added threshold for BW (lineart)
Laurent Charpentier schrieb: Hi Everyone, I would like to submit a patch for the genesys backend (Canon LIDE 50). The patch adds the threshold feature for black/white mode (in 1.0.17 the threshold is set to 50% and can't be changed). The attached patch is relative to sane-backends-1.0.17 (files genesys.c, genesys.h, genesys_gl841.c, genesys_low.h). Thank you to apply this patch. I will take a look at the patch when i find some time. I guess this should be done for software b/w as used by the gl646 part, too. Regards, Pierre
[sane-devel] Any further with canoscan LiDE 500F?
Jeff Shrowder schrieb: Michael and Pierre, Looking through the archives I see a number of postings on developing a driver for the Canon Canoscan LiDE 500F. How far did you get? I didn't do any further work, apart from those postings. I don't know if Michael made any progress. If you are willing to add code for the Canon Canoscan LiDE 500F, I am able to help you with some of the driver related aspects. You still need to figure out the scanner specifics, like how to switch between full ccd resolution and half(to name something more obscure). This involves hours of experiments, good guesses, and a lot staring at usb logs. Regards, Pierre
[sane-devel] genesys endianess
St?phane VOLTZ schrieb: I had to put an ifdef WORDS_BIGENDIAN (like for slope tables), so that my MD6471 could work again after the endianess changes you done. To be exact, the code i used for gamma was meant to work for both endianesses, but does not work for either.. I forgot to modify all parts of the index into the tables. Could you please test that the ifdefed part works now? Regards, Pierre
[sane-devel] genesys endianess
Hi Jon, Jon Chambers schrieb: On Tue, 7 Mar 2006, Pierre Willenbrock wrote: [...] I am planning to add a function that swaps the bytes in place if needed which should be called on the pixel data. You may find the byte ordering calls built into the socket library (htons, htonl, etc) useful. htons/ntohs, htonl/ntohl convert between host byte order and network byte order, which is big endian. Those functions are a noop for a big endian system. It is a common mistake to think htons and co will unconditionally swap bytes. I need a function that converts between host byte order and little endian, and i already know how to do that. Regards, Pierre
[sane-devel] Canon LIDE35 color and motor issues
Hi Luke, Luke Campagnola schrieb: First I want to thank everybody for their great work on the genesys backend, we really appreciate your hard work! Now the complaining bit. I've been comparing the sane driver to the windows driver and I've come up with a few notes: - The windows driver seems to have much smarter control of the stepper motor. This is just a minor issue, but at any scan speed, the head is constantly starting, stopping, reversing, and starting again under sane. I guess it looks at the type of the usb connection, and increases the time taken per line if the connection is not a high speed connection, leading to a smaller data rate, so the scanner does not need to backtrack. - Color reproduction is better with the sane driver than the windows driver, which tends to boost the reds way too much (yaay) - Brightness reproduction is quite poor with the sane driver. It seems that darker colors just drop off to black very quickly. I've posted a sample scan on my website here: http://luke.no-ip.org/tmp/color_comparison.png There are four images--the top row is SANE, bottom row is windows. The left column shows the original scans and the right column has the contrast cranked up. You can see pretty clearly in the top-right image that a lot of the photo has been lost under SANE. A better tool to determine if the bright and dark colors are correctly reproduced is a histogram tool. You can clearly see, if there is still room at the bottom and top of the histogram(not too much, as you still want some useable color values ;-)). This reveals that dark colors are cut off for the sane driver, but it also shows that the windows driver cuts off bright colors. Anyway, it shows a incorrect calibration on the sane side. If I have time, I'll tinker with some of the exposure registers (EXPR, EXPG, EXPB) and see if that helps.. any ideas for other places I might look? These are calibrated to get good values from the ccd, while not overexposing. I will now go into detail on what happens during processing the image. The overall flow of color information is this: First, a light falls on your original, with a specific intensity. The light reflects from the original and hits (through some optics) an ccd chip. The ccd chip accumulates the incoming light and creates a certain voltage. The voltage is largely proportional to the intensity, but if the intensity is too high, the voltage is much lower. After some time the voltages of the ccd are stored away into some buffers(sample and hold i guess). Now the scanning logic goes sequentially through all pixels, requesting the voltage. The voltage then is fed into an A/D converter, which can adjust the analog voltages by adding an offset and multiplying with a gain. Then it converts the voltages into an digital value. This value is then adjusted digitally for each pixel to remove unregularities in the scanning optics, leading to a regular pattern of brighter and darker vertical lines. This is named shading correction. The final step is a gamma correction. In the case of the LiDE 35, the light is a colored led, which blinks for a part second. The duration the led is lit is our exposure time, giving us the ability to calibrate the intensity. The output voltage is then moved to the A/D converter, but only one channel is connected, so the offset and gain are used for all colors. This gives 16 bits worth of intensity information. The shading correction on the other hand is per color and pixel. It is very similar to what the A/D does, adding an offset and multiplying by a gain. Gamma is adjusted with one table per color, mapping a range of intensities to an 8 bit value. This leads to the following variables that can be tuned: * exposure for each color * analog offset for all colors * analog gain for all colors * digital offset for each color and pixel * digital gain for each color and pixel * gamma table for 256 ranges The exposure needs to be as high as possible while not saturating the ccd to get the best possible voltage range out of the ccd, while not oversaturating it. At the same time, alle three colors should lead to nearly the same maximum voltages, as there is only one channel through the A/D converter, whose offset and gain can be changed. Analog offset and gain should map the voltage to nearly the full range of 16bit values. Again, in this case it is better to have the highest/lowest values unmapped, than losing voltage values. The shading mapping works as described above. Just before the shading mapping is done, the averaging takes place, averaging a set of pixels to reduce the resolution for transport. For each set of averaged pixels, only one shading data entry is used, and the other entries for this set are ignored. So far for the differences to the general model, now on to the calibration. The exposure is calibrated by repeatedly scanning a white calibration area, adjusting the exposures by color to get the intensity
[sane-devel] genesys endianess
Hi all, i am planning to complete the endian conversion code in the genesys backend. I identified the following fields where endian conversion is neccessary: Going down to scanner: * slope tables * shading tables * gamma tables The registers need to be addressed bytewise anyways, so they don't need endian conversion anyways. The slope tables already have some code to convert endianess when creating the tables, but the tables are accessed after that conversion. I think the best way to handle this issue is just before sending the data to the scanner. This would leave the data in memory in an easily useable form. Coming up from scanner(scanned data): * actual scan data * calibration data These are two fields, as the data for a scan is handled different from data for calibration. Also, the data for actual scans is already processed to correct endianess. Calibration data on the other hand is used in a many functions. I am planning to add a function that swaps the bytes in place if needed which should be called on the pixel data. Any points i am missing? Regards, Pierre
[sane-devel] Questions about the genesys backend and the corresponding frontends (Wolfson Microelectronics)
Hello Jean-Baka Domelevo-Entfellner schrieb: Following on my project to include support for the OpticFilm 7200 (by Plustek) to the genesys backend, I have some questions to the maintainer(s) of the latter: 1) Are the AFEs taken into account for the moment all made by Wolfson ? The Genesys_Frontend stuctures are different for the UMAX, ST12, HP2400c, etc. I wonder why. Currently, the only tested AFE for the gl841 part is the Wolfson WM8199. The code for AFEs is in no way universally useable. It would be better to add function tables for the AFEs, as done for gl646 chip and gl841 chip. 2) Concerning this same structure, I don't understand exactly the meaning of the four values put in reg and the three put in reg2. Apparently being register contents corresponding to extra registers (we already have the three gain registers and the three offset registers), it would allow for seven configuration registers for the AFE, which looks far too much for me. In my case the AFE is the AD9826, and it has only two 8-bit configuration registers. The WM8199 has three registers for each of gain and offset. Additionally it has six registers for various configuration settings, registers 1-3, 6, 8 and 9. Some AFEs use register 0. 3) At the same point, in sign, correct me if this is not the sign bit (bit#8, i.e. the ninth of the field) of the offset for each of the three channels. Some AFEs are able to invert their input channels. 4) There seem to be some mistakes (or things I don't understand :-)) in the addresses given to the sanei_genesys_fe_write_data function, in genesys.c and genesys_gl841.c. For instance, for the red gain, I can see the address 0x28, which doesn't seem to match the Wolfson WM8192 chip documentation (please indicate which is the exact AFE used, but I think the register addresses are pretty much the same for all WM chips). I looked at my documentation and found register 0x28 to be the red channel gain, for WM8199 and WM8192. The relevant info is this: address description 101000 PGA Gain (Red) hidden on page 23 for WM8192 and page 24 for WM8199. 101000(binary)==0x28(hex). 5) As I could have other questions in the near future, please allow me to write directly to you (dear maintainer(s)) in the future, cause it could become boring for the other readers of the list. Problem is I don't know who is in the current maintainer's team concerning the genesys backend (Pierre ? St?phane ? Gerhard ? Henning ? Maybe I will do some kind of temporary restricted ml...) You are welcome to write directly to me. Regards, Pierre
[sane-devel] Plustek OpticFilm 7200 : first investigations
Jean-Baka Domelevo schrieb: [...] Okay, I don't like the question mark after the name of the chip. On the sane-project webpage listing the unsupported devices, it is said probably a GL841, based upon a trial by sane-find-scanner, probably. To make sure, the first thing I did after unpacking my brand new scanner was to open it (carefully!) and check for the chipset used. And it IS a GL842, not 841. As trustworthy as my eyes can be. It's all for today, I'm starting to have a look at the genesys backend and go through the GL841 and GL842 datasheets to make out where exactly is the difference between them. gl841 and gl842 are identical from the driver side. The genesys backend works for my scanner which is a gl842 based Canon LiDE 35. Regards, Pierre
[sane-devel] Plustek OpticFilm 7200 : first investigations
Jean-Baka Domelevo schrieb: On 1/28/06, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: gl841 and gl842 are identical from the driver side. The genesys backend works for my scanner which is a gl842 based Canon LiDE 35. Hi Pierre, I've downloaded the genesys files from the CVS, and I've seen you're the main contributor to the genesys backend nowadays... Thanks very much for your work. You say gl841 and 842 are to be driven the exact same way... Great news, so the only thing I have to do is to work out a Genesys_Model struct for the OpticFilm 7200 to be but in genesys_devices.c ? And also ad something in Sensor[] and Motor[] ? I guess I will have to dig out what's the exact CCD in my box, right ? Well, there is essentially no working support for the ccd of ccd-scanners. You will need to add that. The only scanners currently supported by the gl841 part use a cis sensor. The Motor struct is pretty simple to fill. You could default to 1 for maximum speed, and it should already be working, but be slow. Getting a fast scan is a bit harder. You need to look at a log from windows, and find the maximum final and starting speeds for each stepping mode. The Sensor struct contains mainly the same values as windows uses. And also, it is said that the GL842 can handle 600, 1200 or 2400 dpi resolutions, nothing more? But Plustek repeatedly state that their scanner is a 7200 * 7200 dpi _in hardware_... What does it mean ? The 600, 1200 and 2400dpi dpihw modes are actually used to select a specific memory model. Apart from that it is only used to calculate how many of the input pixels are sent to the host. For example, if the scanner has a 7200dpi sensor, and the chip is in 2400dpi mode, you would set dpiset to 1200 to get an 3600dpi image. Regards, Pierre
[sane-devel] Does the Canon Lide 80 work?
Hi Aaron, golan...@aol.com schrieb: After patching the backend and a recompile I get the following when attempting a 'scanimage image.pnm' : [more log] [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index =, len = 2 [sanei_usb] : 06 18 ... [genesys_gl841] reg[0x06] = 0x18 [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index =, len = 2 [sanei_usb] : 07 00 ... USB error: error sending control message: No such device [sanei_usb] sanei_usb_control_msg: libusb complained: error sending control mesage: No such device [genesys_gl841] gl841_bulk_write_register: failed while writing command: Invali argument scanimage: open of device genesys:libusb:001:023 failed: Invalid argument [genesys] sane_exit: start [genesys] sane_exit: exit Any suggestions? Looks like we need an usb log from windows. Register 6 cannot be the problem(its just state), so i guess the write to register 7 leads to an immediate reset. Regards, Pierre
[sane-devel] scanning problem for HP 2400
Parag N() schrieb:
Hello Pierre,
On 12/29/05, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote:
Hello Parag,
[...]
--- genesys_gl646.c 2005-12-29 15:32:52.078821000 +0100
+++ genesys_gl646.c.patched 2005-12-29 15:30:29.209892250 +0100
@@ -1772,6 +1772,17 @@
return status;
}
+ /* sends slope table 0 (move before scan area) */
+ status = gl646_send_slope_table (dev, 0, dev-slope_table1,
+ reg[reg_0x6b].value);
+ if (status != SANE_STATUS_GOOD)
+{
+ DBG (DBG_error,
+ gl646_park_head: failed to send slope table 1: %s\n,
+ sane_strstatus (status));
+ return status;
+}
+
/* sends slope table 1 (move before scan area) */
status = gl646_send_slope_table (dev, 1, dev-slope_table1,
reg[reg_0x6b].value);
Revert that patch, it is obviously not helping. Looking at the
description for hp 2300c, i see it does not use park_head. Please remove
GENESYS_FLAG_USE_PARK from the flags.
--- genesys.c 2005-12-28 14:45:00.751717000 +0100
+++ genesys.c.patched 2005-12-29 15:41:08.445842000 +0100
@@ -914,7 +914,8 @@
same_speed, yres);
if (dev-model-motor_type == MOTOR_5345
- || dev-model-motor_type == MOTOR_HP2300)
+ || dev-model-motor_type == MOTOR_HP2300
+ || dev-model-motor_type == MOTOR_HP2400)
return genesys_create_slope_table2 (dev, slope_table, steps,
step_type, exposure_time,
same_speed, yres);
I did what you said but still i am getting no. of lines to scan as
3510 whereas what i found exactly 1755 lines scanning head stops at
other end.
The scan head is still moving too fast. Please check if there is a slope
table that ends on 2750 for full steps or 1375 for half steps. The slope
table generation code advertises that setting. step_type = 0 means full
steps, step_type = 1 means half steps. It is also encoded in register 2,
lowest 2 bits.
I have some questions
1) in genesys_read_ordered_data function theres debug messages
DBG (DBG_info, genesys_read_ordered_data: %d lines left by output\n,
((dev-total_bytes_to_read - dev-total_bytes_read)*8)/
((dev-settings.pixels)*channels*depth));
DBG (DBG_info, genesys_read_ordered_data: %d lines left by input\n,
((dev-read_bytes_left+dev-read_buffer.avail)*8)/
(src_pixels*channels*depth));
I want to know what is this formula to calulate lines
scanned/remainging to scan?
also what is making each call to genesys_read_ordered_datato print
lines left with difference of 13 lines but not line by line.
genesys_read_ordered_data always processes multiple lines. The actual
number of lines depends on how much buffering capacity we provide and
the size of the buffer we got from the frontend.
To calculate the number of lines from a number of bytes we use the
number of pixels per line, the image depth and number of channels:
lines=(bytes*8)/(pixels*channels*depth)
pixels, channels and depth must be correct for the data counted by bytes.
So, for input we use the data we are still expecting from the scanner,
the data in our read buffer and the source pixel count. From this we can
calculate how many lines we still need to process.
For output we calculate how many bytes are left to output to the
frontend, and then use the pixel count requested by frontend.
2) want to know what must be no. lines for my HP 2400 to scan 3510 or
1750 or anyother?
The correct number probably is 3510. You are scanning at 300dpi, your
scan area is about 11.7 in height, so 11.7*300dpi=3510.
3) i have taken log for 3510 lines where from 1755 lines onward
scanner head still want to move forward from other end and made a
noise but i let it upto lines finishes.
my linux log for last few lines
[more log]
[genesys] sanei_genesys_read_register (0x41, 0xc5) completed
[genesys] sanei_genesys_read_register (0x41, 0xc5) completed
[genesys] sanei_genesys_read_register (0x41, 0xc5) completed
[genesys] sanei_genesys_read_register (0x41, 0xc5) completed
[genesys] sanei_genesys_read_register (0x41, 0xc5): failed while
setting register: Invalid argument
[genesys_gl646] gl646_park_head: failed to read home sensor: Invalid argument
[genesys] sane_cancel: failed to move scanhead to home position:
Invalid argument
[genesys] sane_close: start
[genesys] sane_close: exit
[genesys] sane_exit: start
[genesys] sane_exit: exit
Looks like gl646_park_head is really broken. Remove
GENESYS_FLAG_USE_PARK from the flags, this will make the backend use a
different function.
Regards,
Pierre
[sane-devel] scanning problem for HP 2400
Hello Parag,
Parag N() schrieb:
Hello,
On 12/29/05, Parag N() panem...@gmail.com wrote:
Hello Pierre,
[...]
here i am attaching my windows USB log + linux debug log where after
modification(i already mailed to list) + new frontend structre from my
windows log is
[0x01] = 0x000
[0x02] = 0x031
[0x03] = 0x01f
[0x04] = 0x013
[0x06] = 0x008
[0x08] = 0x002
[0x09] = 0x016
[0x20] = 0x020
[0x21] = 0x080
[0x22] = 0x010
[0x24] = 0x080
[0x25] = 0x000
[0x26] = 0x000
[0x28] = 0x001
[0x29] = 0x0ff
[0x2a] = 0x093
This is a completely different type of frontend, incompatible with
current code. You will probably need to modify gl646_set_fe(). Making it
only write the above values for your frontend should be enough.
Please kindly tell me why head is not moving back as i make it to
scanner 1755 lines instead its default 3510 which exceeds. I then have
to disconnect scanner then only genesys debug message logging stops.
Looks to me like there is a bug. Please try park_head.diff.
I want to know relationship between scanning no. of lines. In
genesys backend for HP 2400 i got no. of lines to scan are 3510. does
that mean scanner has to scan 1755 lines from start to other end and
then remaining 1755 from other end to start ?
The problem is, the first slope generation function is severly broken.
The second version works better. create_slope.diff will make your
scanner use the second version.
Regards,
Pierre
-- next part --
--- genesys_gl646.c 2005-12-29 15:32:52.078821000 +0100
+++ genesys_gl646.c.patched 2005-12-29 15:30:29.209892250 +0100
@@ -1772,6 +1772,17 @@
return status;
}
+ /* sends slope table 0 (move before scan area) */
+ status = gl646_send_slope_table (dev, 0, dev-slope_table1,
+ reg[reg_0x6b].value);
+ if (status != SANE_STATUS_GOOD)
+{
+ DBG (DBG_error,
+ gl646_park_head: failed to send slope table 1: %s\n,
+ sane_strstatus (status));
+ return status;
+}
+
/* sends slope table 1 (move before scan area) */
status = gl646_send_slope_table (dev, 1, dev-slope_table1,
reg[reg_0x6b].value);
-- next part --
--- genesys.c 2005-12-28 14:45:00.751717000 +0100
+++ genesys.c.patched 2005-12-29 15:41:08.445842000 +0100
@@ -914,7 +914,8 @@
same_speed, yres);
if (dev-model-motor_type == MOTOR_5345
- || dev-model-motor_type == MOTOR_HP2300)
+ || dev-model-motor_type == MOTOR_HP2300
+ || dev-model-motor_type == MOTOR_HP2400)
return genesys_create_slope_table2 (dev, slope_table, steps,
step_type, exposure_time,
same_speed, yres);
From henn...@meier-geinitz.de Thu Dec 29 17:54:07 2005
From: henn...@meier-geinitz.de (Henning Meier-Geinitz)
Date: Thu Dec 29 17:54:18 2005
Subject: [sane-devel] Agfa Scanner
In-Reply-To: 20051227160207.ga1...@daniel.bse
References: 20051226221530.ga10...@daniel.bse
20051227133702.gj14...@meier-geinitz.de
20051227160207.ga1...@daniel.bse
Message-ID: 20051229175407.ga11...@meier-geinitz.de
Hi,
On 2005-12-27 17:02, Daniel Gl?ckner wrote:
On Tue, Dec 27, 2005 at 02:37:02PM +0100, Henning Meier-Geinitz wrote:
Which Agfa scanners excatly you are writing about? The 1212P and ...?
http://www.agfa.com/digicam_scanner_drivers/faq/index.html
lists four scanners which are not supported in WinXP but have a beta
driver for Win2k.
Thanks for your explanation. I added the missing scanners to our lists
and added a summary page pointing to your mail.
If you haven't noticed yet: Somebody claimed that the Agfa 1212P works
with the plustek_pp backend:
http://lists.alioth.debian.org/pipermail/sane-devel/2005-December/015658.html
Bye,
Henning
[sane-devel] Does the Canon Lide 80 work?
Hi, golan...@aol.com schrieb: I made the changes you suggested and troubleshot a few things and got the scanner to be found as a LiDE 60 with scanimage. I got an invalid argument error when I tried to do 'scanimage image.pnm'. Below is a debugging log after I issued 'export SANE_DEBUG_GENESYS_GL841=255' and 'export SANE_DEBUG_SANEI_USB=255'. Sometimes SANE_DEBUG_GENESYS=255 is interesting, too. ---Log--- [sanei_usb] sanei_usb_init: found libusb device (0x04a9/0x2214) interface 0 at libusb:001:009 [sanei_usb] sanei_usb_init: found 1 devices [sanei_usb] sanei_usb_open: trying to open device `libusb:001:009' [sanei_usb] sanei_usb_open: configuration nr: 0 [sanei_usb] sanei_usb_open: interface nr: 0 [sanei_usb] sanei_usb_open: alt_setting nr: 0 [sanei_usb] sanei_usb_open: endpoint nr: 0 [sanei_usb] sanei_usb_open: direction: 128 [sanei_usb] sanei_usb_open: address: 1 transfertype: 2 [sanei_usb] sanei_usb_open: found bulk-in endpoint (address 0x01) [sanei_usb] sanei_usb_open: we already have a bulk-in endpoint (address: 0x81), ignoring the new one [sanei_usb] sanei_usb_open: endpoint nr: 1 [sanei_usb] sanei_usb_open: direction: 0 [sanei_usb] sanei_usb_open: address: 2 transfertype: 2 [sanei_usb] sanei_usb_open: found bulk-out endpoint (address 0x02) [sanei_usb] sanei_usb_open: we already have a bulk-out endpoint (address: 0x02), ignoring the new one [sanei_usb] sanei_usb_open: endpoint nr: 2 [sanei_usb] sanei_usb_open: direction: 128 [sanei_usb] sanei_usb_open: address: 3 transfertype: 3 [sanei_usb] sanei_usb_open: found interrupt-in endpoint (address 0x03) [sanei_usb] sanei_usb_open: we already have a int-in endpoint (address: 0x83), ignoring the new one [sanei_usb] sanei_usb_open: opened usb device `libusb:001:009' (*dn=0) [sanei_debug] Setting debug level of genesys_gl841 to 255. [genesys_gl841] gl841_init [genesys_gl841] gl841_init_registers [genesys_gl841] gl841_setup_sensor [genesys_gl841] gl841_init_registers complete [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 12, value = 135, index = 0, len = 1 [sanei_usb] : 04 [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 12, value = 131, index = 0, len = 1 [sanei_usb] : 0E [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 12, value = 133, index = 0, len = 1 [sanei_usb] : 00 [genesys_gl841] gl841_bulk_write_register (size = 208) [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index = 0, len = 2 [sanei_usb] : 01 A0 [genesys_gl841] reg[0x01] = 0xa0 [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index = 0, len = 2 [sanei_usb] : 02 38 .8.. [genesys_gl841] reg[0x02] = 0x38 [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index = 0, len = 2 [sanei_usb] : 03 5F ._.. [genesys_gl841] reg[0x03] = 0x5f [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index = 0, len = 2 [sanei_usb] : 04 10 [genesys_gl841] reg[0x04] = 0x10 [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index = 0, len = 2 [sanei_usb] : 05 40 .@.. [genesys_gl841] reg[0x05] = 0x40 [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index = 0, len = 2 [sanei_usb] : 06 18 [genesys_gl841] reg[0x06] = 0x18 [sanei_usb] sanei_usb_control_msg: rtype = 0x40, req = 4, value = 131, index = 0, len = 2 [sanei_usb] : 07 00 USB error: error sending control message: Protocol error [sanei_usb] sanei_usb_control_msg: libusb complained: error sending control message: Protocol error [genesys_gl841] gl841_bulk_write_register: failed while writing command: Invalid argument scanimage: open of device genesys:libusb:001:009 failed: Invalid argument I'm not sure if this is a problem with the backend not supporting my scanner or if I have made a mistake in the setup of the scanner. Any help would be appreciated. This happens either with faulty usb equipment, or the scanner resets itself. This happens when it short-circuits itself(i guess) responding to an errorneous register write. I suspect register 0x03 is responsible(lamp power etc.). The attached patch should clarify this, by giving the scanner more time to react on the register writes. The last successfull write should be the one leading to the reset. Regards, Pierre -- next part
[sane-devel] How far to go for the CanoScan LiDE 500F
Michael Roitzsch schrieb: Since the CanoScan LiDE 500F is still unsupported and I consider to buy such a thing, I would like to now, how much work is still missing on this. I have some usable programming skills, but I have no experience in reverse engineering USB protocols, so it would be nice, if I had some idea about the task ahead. Thanks. Basic reflective scanning may work with only adding the usb-id and a new device definition to the backend. But getting infrared scan and transparency adapter to work will require capturing and analysis of usb logs of a scan with the windows driver. I think these are the steps needed for full support: - acquire logs from windows scans - extract registers+motor tables - find differences - add support for reflective scanning for this model - implement basic transparent scanning - add calibration for transparent scanning - add support for infrared scanning mode(probably a gray scanning mode with a gpio pin set) We do have some scripts for analysing usb logs. I can help finding the differences between the register sets and motor tables of LiDE 500F and mine LiDE35. Getting reflective scanning to work should be easy, but there is currently no support for transparent scanning and infrared scanning in the gl841 part. Regards, Pierre
[sane-devel] How far to go for the CanoScan LiDE 500F
Michael Roitzsch schrieb: I think these are the steps needed for full support: - acquire logs from windows scans Would that be possible from Mac OS X, too? I only have an old Win98 and I am not sure that the scanner will work there. Win98 should be fine. Thats where my logs are from. I don't know about Max OS X.
[sane-devel] GL646 part and 1.0.17 upcoming release
Hi all, I moved the genesys backend in experimental cvs to sane-backends cvs yesterday evening. I tried to send a notification to the list twice, but haydn didn't want to relay that mail(it didn't relay the commit mails either). Changes are in ChangeLog. St?phane VOLTZ schrieb: I finally fixed the last two known bugs in the genesy backend related to GL646 scanners. The experimental version is now ready for the next release for this part. Please move those changes over to sane-backends cvs. I forgot you were still hunting bugs. Regards, Pierre
[sane-devel] genesys backend update
Hi all, Seems like the mailing system on haydn had an outtime. At least the cvs commit mails didn't arrive here, and i couldn't send this mail the first try. I updated the genesys backend in cvs. It is in sync with experimental cvs now again. If you own a genesys based scanner which should be supported, please test. Thanks to all contributing bug reports. Regards, Pierre
[sane-devel] GL646 part and 1.0.17 upcoming release
Hi Henning Meier-Geinitz schrieb: On Tue, Dec 06, 2005 at 10:59:51AM +0100, Pierre Willenbrock wrote: I moved the genesys backend in experimental cvs to sane-backends cvs yesterday evening. I tried to send a notification to the list twice, but haydn didn't want to relay that mail(it didn't relay the commit mails either). Changes are in ChangeLog. I didn't get a notice/bounce for your first mail. What was the error message? haydn uses greylisting, so the first mail sent is always rejeceted with a temporary error message. Also according the #alioth, subnet 58.180.0.0/16 is currently blocked because of massive spamming. I got a permanent error from mailer-dae...@haydn.debian.org at 05.12.2005 22:15: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: sane-devel@lists.alioth.debian.org local delivery failed I am coming from a subnet of Deutsche Telekom AG, so i will probably not end up in that Korean subnet ;-) You second mail was hold for moderation because pierre at linux-net.dnsalias.org is not subscribed to the list. I'll approve it now. Wrong sender address, sorry. Took that for a failed send. Did you get any bounces for the missing sane-commit mails? No bounces for sane-commit mails. Regards, Pierre
[sane-devel] Canon LiDE 60: Semi-success report
Henning Meier-Geinitz schrieb: I only get backtracking here with high load of the computer. However I can confirm the horizontal lines. Looks like something connected to backtracking at 16 bit doesn't fully work yet. I don't have these lines in 8 bit mode. Those corrupted horizontal lines are the result of a buffer overrun. I thought i did setup the words per line parameter correctly, but obviously i did not. In this case word seems to mean 1 byte while in other contexts it means 2 bytes. I will look into that, forcing backtracking in 16bit modes should not be too hard. Regards, Pierre
[sane-devel] Canoscan LIDE35 on 23nov CVS
Hi Pierre, Do you have genesys in your dll.conf? To my knowledge sane now uses libusb for usb support, so the scanner module is not needed. Regards, Pierre Pierre Lambion schrieb: Hi, I have a cansocan lide35. I use it with a test program written by Pierre Willenbrock but it seems it is now supported in cvs. So I installed today's CVS. - lsusb sees my scanner: Bus 001 Device 004: ID 04a9:2213 Canon, Inc. LiDE 50/LiDE 35 - sane-find-scanner sees it too found USB scanner (vendor=0x04a9 [Canon], product=0x2213 [CanoScan], chip=GL841) at libusb:001:004 - but scanimage --list-devices only show my tv card and my webcam: device `v4l:/dev/video1' is a Noname Logitech QuickCam Pro 4000 virtual device device `v4l:/dev/video0' is a Noname BT878 video (Hauppauge (bt878)) virtual device I'm on a 2.6 kernel, slackware current. scanimage -V gives scanimage (sane-backends) 1.0.16-cvs; backend version 1.0.16 I noticed the id of my scanner (as printed by sane-dind-scanner) was not in /etc/sane.d/genesys.conf, so I added it but it still does not work. Actually I noticed sane-backends and frontends packages do notinclude any /etc file so I might be left with old ones here. Also, I found a doc that suggests I should do a modprobe scanner vendor=0x04a9 product=0x2213 (values taken from sane-find-scanner) but the scanner module is not found and I understood from other docs I should not use it anyway? What am I missing here? Cheers, Pierre
[sane-devel] genesys backend
Hi, Henning Meier-Geinitz schrieb: Hi, Thanks for all your work! As far as I know, you use a LiDE 35. So i marked this scanner's support as good. If you think the level of support is different, please change it in genesys.desc. It is working for me in daily use, so good seems to be okay. I tested a Canon LiDE 50. To get it running, I had to uncomment its id in genesys.conf. I changed this in CVS. I Also changed the name of the scanners to also show the Canon LiDE 40. Also I used a build number of 7, because the last one in CVS was already 6. The test results for my Canon Lide 50: Generelly: Sometimes I have a dark vertical stripe near the left border (about 1 cm width, over the complete image). This happens in Preview but very seldomly. Also I have vertical stripes, especially in medium-bright areas. Color: 75: Works, images are a bit too bright (over-imposed). Black looks grayish and some brighter colors are nearly white. Seems like the shading calibration does not work correctly for you. Grayish black is okay, i don't want to cut the color range. But brighter colors getting near white is not. When using SANE_DEBUG_GENESYS=255 there should be an image named black_white_shading.pnm in the current working directory. It contains a scan of the calibration area. Please send it to me. 150: Sometimes works, most of the time the scan hangs at about 95%. I.e. there is a normal scan but the scan head stops and xsane never displays the image. Also tested with scanimage. When it works, the image looks like at 75 dpi. The problem depends on image width. E.g. at a width of 20 mm, it always works at 150 dpi but not with the full width. Sledomly, I also get a segmentation fault. Mine does not expose such behaviour. Could you please send a complete log with SANE_DEBUG_GENESYS=255 and SANE_DEBUG_GENESYS_GL841=255? I already see one problem: The result of genesys_fill_read_buffer really should not be ignored. The log shows that this part is repeated endlessly in case of a freeze: [log] After the freeze or segmentation fault, the scanner is sometimes not found anymore. Replugging fixes that. 300, 600 dpi: Works (overimposed) in full width. Doesn't work at e.g. width 100 mm (see above). 1200 dpi: Doesn't work in full width (see above). Works at e.g. a width of 20 mm. This is much darker and has vertical stripes (calibration problem?) 2400 dpi: Same as 1200 dpi. In addition, the image is too long (factor 2). I.e., in modes like 1200x2400 dpi the x resolution must be inflated by either just duplicating pixels or, better yet, interpolating them. I must admit that i never tested 2400dpi. But looking at my logs, i see that scanimage requests 1200x2400dpi, and we are delivering that. So, the correct behaviour if we get different resolutions for x and y is to use them internally, and interpolate to create an image with the maximum of x and y resolution(2400dpi in that case)? Gray: 75 dpi: Works, but is over-imposed. 150-600: see color 1200, 2400: see color 1200/2400 Lineart: similar to gray I also did a spot check on color 16 bit and this seems to be less over-imposed. 16 bit doesn't use any gamma. For 8 bit there is a gamma of 2.2 or 0.4(don't remember which one), which should match what Canon does(at least i am sending a very similar gamma table). Thanks for your testing. Regards, Pierre
[sane-devel] genesys backend
Hi, St?phane VOLTZ schrieb: Hello, there are quite some issues with gl646: - 250, 400 and 500 dpi modes fail with 'invalid argument'. At least in the log you sent me it fails in gl646_search_start_position, trying to read the last 64 bytes of a scan. I am not aware of any changes affecting that function. - lineart mode is broken . I could change read_ordered_data to convert gray data to lineart. But the changes to make the scanner output lineart are small: Set lineart bit, modify read_bytes_left and words_per_line to correctly take lineart into account(which would be setting depth correctly). At least that did the trick for my scanner. I cannot test on a gl646, so i am just attaching my idea of the changes needed. Please test. - after a few scan, especially when changing dpi, I get 'color noise' instead of pictures. Restarting the scanning program fix it. Sounds like memory corruption. Thats always hard to track down.. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: lineart_gl646.diff Type: text/x-patch Size: 630 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20051121/4b8ecaf0/lineart_gl646.bin From martin.olof.anders...@gmail.com Mon Nov 21 00:22:02 2005 From: martin.olof.anders...@gmail.com (Martin Olof Andersson) Date: Mon Nov 21 00:22:16 2005 Subject: [sane-devel] Brother MFC-610 CLN scanner with network cable In-Reply-To: 20051120151245.gh3...@meier-geinitz.de References: d29b20cd0511200431oc1188...@mail.gmail.com 20051120142501.gf3...@meier-geinitz.de d29b20cd0511200651r315bd4...@mail.gmail.com 20051120151245.gh3...@meier-geinitz.de Message-ID: d29b20cd0511201622t537bf8...@mail.gmail.com Henning You are fast to reply, it is so amazing. I will now contact to Brother and probably I will use my printer/scanner for printing only with Linux. I still have xp on other machines so I can still scan, no problem. If I find any news, I will let you know. If you hear nothing from me, then they just dont support Linux for this scanner yet. Again, thank you. Martin 2005/11/21, Henning Meier-Geinitz henn...@meier-geinitz.de: Hi, On Sun, Nov 20, 2005 at 11:51:46PM +0900, Martin Olof Andersson wrote: When I searched like you did on the sane page, I found MFC-620CN at the bottom in the brother2 group. I am sorry that I mistyped the model number. Although I misspelled, I think there might be a misspell in the sane list as well, and that it shoul be MFC-620CLN. I copied this from the brother2 page and they claim the MFC-620CN is supported by brother2. A CLN is not mentioned on their page at all. So I guess I'll add a MFC-620CLN as unsupported? In the list it says usb for all scanners, even the supported ones. In the list there is nothing about network cable connections. I am trying to set it up with a network cable, I think it is ethernet (normal Internet cable). I have read the man pages of sane and saned but it did not help me yet. I will ask to Brother like you advised me. The Brother page says: This SANE driver will only work with devices connected through the USB interface.. That's why I listed all of these scanners only as USB. Bye, henning -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20051121/f186b3a3/attachment-0001.html From ulrich.deit...@uni-koeln.de Mon Nov 21 09:32:15 2005 From: ulrich.deit...@uni-koeln.de (Ulrich Deiters) Date: Mon Nov 21 09:32:32 2005 Subject: [sane-devel] Epson Perfection 3490 on Ubuntu Breezy 5.10? In-Reply-To: 43808c8b.9020...@haskinferguson.net References: 437f44cb.2060...@haskinferguson.net 20051119165044.db875350.a...@scii.nl 437f73ff.80...@haskinferguson.net 43808c8b.9020...@haskinferguson.net Message-ID: Pine.HPX.4.61.0511211023570.28532@xenon On Sun, 20 Nov 2005, Denis Haskin wrote: Very weird. Looks like what's happening is that the scanner keeps resetting itself (every few seconds) and gets assigned a new USB device number. I thought maybe the problem was I hadn't specified any firmware file, so I got that off the Windows install CD and modified snapscan.config to add it, but hasn't seemed to change behavior. a) Look up the device file(s) under /proc/bus/usb, they should have a write permission for everyone (nou relevant if you scan with su privileges) b) Has the firmware file got the correct permissions? c) Did you install SANE to /usr/local ? Sometimes it helps to link the sane.d directory to /etc: ln -s /usr/local/etc/sane.d /etc/sane.d Regards, Ulrich Deiters
[sane-devel] Canon CanoScan LiDE 35
Cameron Harris schrieb: On 10/30/05, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: Does it always stop there? It looks like the usb connection somehow broke while transfering data. Does the scanner re-register with your system at the moment the transmission stops? There will be some kernel messages about a new usb device in that case. Yeah it always stops there, nothing in dmesg about it. Then i would like to have a full log, with SANE_DEBUG_GENESYS=255, SANE_DEBUG_GENESYS_GL841=255, SANE_DEBUG_SANEI_USB=255. That log will get large. Please compress it and send it to me(The list won't accept messages larger than 50k). If the compressed log is larger than 4MB we need to find a different transport channel. Regards, Pierre
[sane-devel] Canon CanoScan LiDE 35
Cameron Harris schrieb: Right.. got a full compressed log, attached it to this message. Thanks :) Thanks for the log. Please try the attached patch. I don't know if it helps. The backend is trying to read 156 bytes from the scanner, but libusb does not provide that much. We need to find out where the data is lost. The patch addresses one possible cause. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: bulkin.diff Type: text/x-patch Size: 514 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20051030/cd1d1128/bulkin.bin From fba...@gmx.net Sun Oct 30 17:26:46 2005 From: fba...@gmx.net (Franz Bakan) Date: Sun Oct 30 18:27:18 2005 Subject: [sane-devel] Build system changes -- please test! In-Reply-To: 20051029201432.ga1...@meier-geinitz.de Message-ID: mailman.86.1130696838.11105.sane-de...@lists.alioth.debian.org On Sat, 29 Oct 2005 22:14:32 +0200, Henning Meier-Geinitz wrote: I have just committed some changes regarding the Makefiles to the sane-backends CVS. Please test if sane-backends can still be built and installed on your system (especially OpenBSD and MacOS X). still builds on OS/2 :-) Franz
[sane-devel] Canon CanoScan LiDE 35
Cameron Harris schrieb: On 10/30/05, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: Thanks for the log. Please try the attached patch. I don't know if it helps. The backend is trying to read 156 bytes from the scanner, but libusb does not provide that much. We need to find out where the data is lost. The patch addresses one possible cause. Regards, Pierre U.. well... good and bad news. The patch made it get past where it was stopping before, and now loads of rubbish appears on the terminal when I do scanimage. I ran xsane to see if it was scanning anything, hit acquire preview. The loads of rubbish actually are the requested image. scanimage outputs on stdout per default. The scanner made a few noises, then went bp until the scan was done. While it was beeping, the scanner head was lit green. Did the head move? xsanes default is to scan in grey mode, which is translated into a monochrome green scan. The image produced was just grey lines on a black-ish background. One good thing is that if I open the scanner lid mid-scan, it seems to have an effect on the image appearing on screen. Sane Screenshot: http://htsc01.b3ta.org/scan.png Where it gets lighter is where I opened the lid, and darker again when I closed it. I guess the calibration step failed. Each scan should look like this: - (optionally)move head home - blink lamp - move head away from home - blink lamp - move head home - (maybe) blink lamp - move head away from home - blink lamp - move head home - do a short scan - move head home - do the real scan If the head moved in the short scan part, please compress and send me black_white_shading.pnm. That image should be generated while using scanimage with SANE_DEBUG_GENESYS=255. I'll try getting it onto a Windows system and actually making sure the scanner works properly :|, maybe I could get a USB snoop while I'm at it, just in case. Regards, Pierre
[sane-devel] Canon CanoScan LiDE 35
Cameron Harris schrieb: Fantastic! I just messed around with the lock button on the bottom of the scanner, locking and unlocking a few times, then tilting it to the side a bit.. and it works now! All I can guess is that someone picked up the scanner when it was unlocked and I wasn't looking and it made the scanner head lock in a funny position... but now it works, so that's cool. :D It was the bulkin patch that seemed to actually make it scan. Thanks for your help :) Thanks for your valuable input. I commited the change. Regards, Pierre
[sane-devel] genesys backend
John William Dalton schrieb:
I've managed to get sane/xsane working with my Canon LiDE 60.
I did this by compiling the experimental CVS genesys
backend (including Pierre's recent support for the LiDE35/40/50).
Before compilation I replaced every instance of the LiDE 35
USB ID (0x2213) with the USB ID for the LiDE 60 (0x221c).
I tested preview mode and scanning at 75dpi, 150dpi, 300dpi, 600dpi,
1200dpi and 2400dpi. All worked.
There were a few minor issues noticed. Unless mentioned the
scan area was set to 'full':
1) In some modes there is a 'klunk' noise after the scanning head
finishes scanning and before it starts its return journey.
Possibly the scan head is travelling just a little too far
and hitting the end of the track? This 'klunk' is not there when
the same operation is done under windows.
The nature of the klunk varies with the scan mode as below:
Preview: soft klunk
Preview is just a regular scan(75dpi in most cases). We (currently)
don't handle that in a different way.
75dpi: soft klunk
150dpi: nasty klunk and short grinding noise as the scan head hits
the end of it's travel. I think the grinding noise is the gear
drive of the scan head skipping a couple of teeth as the scan head
can't go any further.
300dpi: no klunk. Nice and smooth. If the scan area is set to the
bottom quarter of the page, there is a 'klunk' as the scan head reaches
the end of its travel. The scanning is a little noisier than windows
(but it's faster??)
At 150 and 75dpi modes the stepper motor is driven at highest speed,
which is indeed faster than with the windows driver. I did a bit of hand
tuning of the acceleration/deceleration curve.
I think the deceleration is too fast(At least the first few steps. Many
later steps will then be misaligned, until the motor is at a speed below
its max start speed). Could you try to change the maximum final speed in
genesys_devices.c, lines 383 and 389. The speed there is expressed in
time per step, therefore higher value means lower speed.
Another value which can be tuned is the step count. This is the total
number of steps used for acceleration/deceleration.
genesys_devices.c:381
{{
3000, //maximum start speed, time/step
1300, //maximum final speed, time/step
50, //step count
0.8,
},
After changing anything in tat file you need to update the timestamp of
genesys.c, using touch or saving it again.
Another place you could look at is the y size of the scan area
(genesys_devices.c:456), if the scan head really hits its upper position.
600dpi: no klunk. The stepper motor makes a medium noise. Under
windows it is audible, but much a quieter low level hum.
1200dpi: no klunk. The stepper motor makes a lot of noise. Under
windows it is almost silent.
I need to research that a bit. I can imagine two problems:
-The scanners feature some kind of power selection for the stepper
motor, so it should be set differently for high resolution modes.
-The motor is used in full step mode although it should be used in half
step mode.
2) Before each scan the scan head spends some time dithering backwards
and forwards, before commencing the scan. Some sort of a calibration
run? Under windows the scanner does not do this. I did observe though
that when the windows software was installed it spend a minute or so
doing a calibration run and storing the results.
That is indeed the calibration, which is done before every scan. This is
because we do not cache the calibration results.
I'm not sure if the above issues are LiDE 60 specific, or also
present with the LiDE 35. Either way, the driver seems to be a great
piece of work and just needs some fine tuning for the LiDE 60.
When I get a chance I'll try a usbsnoop on the windows driver,
put the log on my website and post a link. (I gather you are
experienced at reverse engineering USB logs Pierre? Do you
have any interest in looking at an LiDE 60 log, or guiding me
though the process?)
Getting a usb log is easy. Start the sniffer, select the device, replug
it, and there you go. The larger Problem is analyzing the resulting log.
I created a script for that, which reformats the log and does some
interpretation. That output was the base for my test program.
I also plan to do an audio recording of the scanner driven by both
sane and its windows drivers. Hopefully I can then accurately
compare scan times and by doing an FFT, and looking at the audio
spectrum, figure out whether there is any difference in the rate
at which the stepper motor is being driven.
An additional issue. When xsane starts up, it presents a list
of found scanners for em to chose from. The LiDE 60 does not appear
in this list. I have to explicitly provide the device
genesys:libusb:005:006, as reported by sane-find-scanner, on
the xsane command line. Does anyone know how to get a USB scanner
to appear in the list of available scanners?
No idea, why it
[sane-devel] Lide50 - Flashing Colours
Ashley Caire schrieb: I'm trying to test my Canon LIDE50 scanner with the latest CVS, but all the scanner does is flash pink, then red, then yellow quickly, then a continuous white.. Is there anything obvious i'm doing wrong? If you got this with the code from experimental cvs i am interested in the output of scanimage with SANE_DEBUG_GENESYS_GL841=255 and SANE_DEBUG_GENESYS=255. The image data is not needed(if you get any), just stderr. Regards, Pierre
[sane-devel] genesys backend
Brian J Densmore schrieb: Pierre Willenbrock wrote: I did a major restructuring on the gl841 part. You may want to take a look at that. Are you referring to the patch you created? I've already applied that. Just wanted to make sure you are not working with old code ;-). Essentially to add support for a gl841/gl842 based scanner you need to find out the motor acceleration curve and type(half-step, quarter step capable), ccd settings and analog frontend settings. Well as for the motor acceleration, I'm not sure I need to do anything there except use the code that the Medion 6228 uses. At least for resolution up to 2400 xdpi. If these settings work, use them. But for optimal performance you need to tweak the settings. AFAIR the settings for all scanners except Canon LiDE 35/40/50 are guessed, and rather pessimistic. Provided you use the new slope generation code(The old code doesn't fit with the gl841 part very well). The acceleration curve is completely independent of the horizonzal resolution. It is even independent of the vertical resolution. The new code uses the time per (full-, half-, quarter-, eighth-)step, derived from the exposure time at a given resolution. Further it uses a predefined acceleration slope, defined by its start and end speed(in time per full step) and an exponent to make the slope slightly non-linear. The acceleration curve for a given minimum time per step is the predefined curve capped at that minimum time per step. I'm currently building a Windows machine with USB support so I can do some USB sniffing. I am still trying to get the datasheet for the GL843, I am hopeful of getting that from a tech at genesys soon. I'm sure the registers are different from the 842. Also the 8400 is eighth step capable. My guess is that the allowed values of STEPSEL/FSTPSEL (in register 0x67/0x68) are expanded to include the value of 3 for eighth step. At least that's what i hope, as that fits with the current code. Transparent adapter support is completely missing. Any ideas on where I could steal some code from to try to make work. I've seen the registers in the 842 specs that need to be populated. If you'd like I could work on adding that to the existing scanners. Not sure if any of them are capable. On the gl841 side there are no scanners currently supported which have a transparent adapter. Perhaps there is a scanner with transparent adapter in the gl646 part. We will need to add support for horizontal resolutions which do not directly map to one of the gl841 settings(600, 1200, 2400dpi). Using these settings the chip decides which memory layout to use, and how to treat the dpiset setting. Technically, in 2400dpi mode you can equip the scanner with a 43690 pixel ccd with arbitrary resolution, in 1200dpi mode half of that. I noticed you were using a 'non-supported' resolution on the LiDE. Why not not just use the resolutions that the GL84x are designed for? There is also the possibility of using the deletion type bit in the AVEENB register (bit 6 of reg 3)? That is the one you were talking about right? The 842 chip should have 1200,600,400,300,200,150,120,80 for a 1200 xdpi scanner, by setting registers 44 and 45 (0x2C, 0x2D) and clearing the AVEENB bit. I don't know what the bit settings are for those resolutions though. They aren't defined in the spec, that I can see. Cleared AVEENB bit means use of deletion. With deletion the range for DPISET(reg 0x2c/0x2d) is not limited. Using averaging(AVEENB is set) you are only allowed to set DPISET to 1/1, 1/2, 1/3, 1/4, 1/5, 1/6, 1/8, 1/10, 1/12, 1/15 of the hardware dpi setting DPIHW. You simply set these values in DPISET(eg. DPISET=600 for DPIHW 1200 and 1/2 averaging). What i tried to explain was, that you cannot set DPIHW for 3200dpi in hardware. We will need to add code, which adjusts DPISET to gain the correct averaging values(eg for DPIHW 2400, real hardware 3200xdpi, requested 1600xdpi you would need to set DPISET to 1200). There is already a similar problem: for speed reasons most ccd/cis chips can be switched to a half resolution mode, making scanning a single line twice as fast as in full resolution mode. When we switch to half resolution, we don't change the DPIHW setting, so we need to adjust DPISET accordingly. That code can be expanded to account for hardware resolutions the scanner doesn't support in DPIHW. Using half resolution mode i get averaged resolutions of 1200xdpi, 600xdpi, 300xdpi, 200xdpi, 150xdpi, 120xdpi, 100xdpi, 75xdpi, 60xdpi, 50xdpi and 40xdpi for my DPIHW 1200 scanner. I hope i explained that more understandable now. Regards, Pierre
[sane-devel] Canon LiDE60/GL841 support?
Pierre Willenbrock schrieb: Hi Philip, The LiDE60 scanner probably is a LiDE35/40/50 with a modified case. There may be some technical differences, which would require changes in the backend, but i can't tell without any reports. Regards, Pierre I do have a report that the LiDE60 is indeed a LiDE35/40/50 with a different product ID. So no changes needed for the genesys backend, apart from adding the device to the list. Regards, Pierre
[sane-devel] Preparation of the next release of sane-backends
Hi Currently we have a working backend for either gl646 or gl841. The code in experimental cvs only allows scans on gl646 at low resolutions, but apart from that is ready for the rest of gl841 support, without breaking gl646 support even more. But we certainly don't want to include code which breaks a currently working backend, so the problem needs to be solved. To my knowledge there are no new gl646 based scanners supported. Regards, Pierre
[sane-devel] Canon LiDE60/GL841 support?
Hi Philip, The LiDE60 scanner probably is a LiDE35/40/50 with a modified case. There may be some technical differences, which would require changes in the backend, but i can't tell without any reports. Regards, Pierre
[sane-devel] genesys backend - device I/O's
Hi
I guess this error is triggered by my powersaving code. Playing with
those gpios can (hard-)reset the scanner causing it to reconnect on usb.
Please try the attached patch(against patched experimental module).
Next time please send output with
SANE_DEBUG_GENESYS_GL841=255
SANE_DEBUG_GENESYS=255
Mathias Lang schrieb:
Hi,
Pierre Willenbrock wrote:
It is now ready to be extensively tested.
i don't know if this is my lack of skills to set up the backend properly
(tested it on my two boxes), but i get device I/O's with the genesys-cvs
backend patched with the patch from Pierre's site: The device is first
opened (the scan head moves a little back and forth) - then i get a
device I/O.
My apologies if this has nothing to do with the backend - just wanted to
give some feedback (GENESYS and SANE_DEBUG_USB logs down...).
Bye,
Mathias
Regards,
Pierre
-- next part --
--- sane-backends-1.0.16/backend/genesys_gl841.c2005-09-23
21:07:01.963073000 +0200
+++ experimental/genesys/genesys_gl841.c2005-09-27 18:48:46.735009250
+0200
@@ -2991,36 +2991,6 @@
if (enable)
{
- if (dev-model-gpo_type == GPO_CANONLIDE35)
- {
-/* expect GPIO17 to be enabled, and GPIO9 to be disabled,
- while GPIO8 is disabled*/
-/* final state: GPIO8 disabled, GPIO9 enabled, GPIO17 disabled,
- GPIO18 disabled*/
-
- sanei_genesys_read_register(dev, 0x6D, val);
- sanei_genesys_write_register(dev, 0x6D, val | 0x80);
-
- usleep(1000);
-
- /*enable GPIO9*/
- sanei_genesys_read_register(dev, 0x6C, val);
- sanei_genesys_write_register(dev, 0x6C, val | 0x01);
-
- /*disable GPO17*/
- sanei_genesys_read_register(dev, 0x6B, val);
- sanei_genesys_write_register(dev, 0x6B, val ~REG6B_GPO17);
-
- /*disable GPO18*/
- sanei_genesys_read_register(dev, 0x6B, val);
- sanei_genesys_write_register(dev, 0x6B, val ~REG6B_GPO18);
-
- usleep(1000);
-
- sanei_genesys_read_register(dev, 0x6D, val);
- sanei_genesys_write_register(dev, 0x6D, val ~0x80);
-
- }
gl841_set_fe (dev, AFE_POWER_SAVE);
From lauri.pirtti...@luukku.com Tue Sep 27 18:15:25 2005
From: lauri.pirtti...@luukku.com (Lauri Pirttiaho)
Date: Tue Sep 27 18:15:34 2005
Subject: [sane-devel] USB recordings MD6190 available
Message-ID:
1127844925649.lauri.pirttiaho.126577.nuedvtdx9xi_rcbtkkm...@luukku.com
Lauri Pirttiaho on Mon Sep 26 18:25:44 UTC 2005
Bertrik Sikken on Sun Sep 25 20:35:55 UTC 2005
Lauri Pirttiaho wrote:
-- value 0040 returns state of a state machine driven by ie1 as its
first byte and I suspect that state machine to be the motor control.
The second byte is port 1 bit 0 which I suspect to be he head home
detector. Additionally there are 3 more bytes of info (I con't
know the meaning of these yet), 0xAA and then 0's.
I noticed some increasing number at bytes 2 and 3 and suspect that
this is the current line number of the carriage.
That, too, may be different from the CanoScan one...
Bytes 2 and 3 are a counter in ie1 handler. That counter is used
to trigger events in the state machine and it goes steadily up and
down in certain states interrupt-by-interrupt. I believe Bertrik's
interpretation is correct. Confirmation comes from checking the
trigger values against known parameters (e.g. in value 0030 command
-- the scan command).
With best regards,
Lauri Pirttiaho
Oulu
Finland
...
Luukku Plus paketilla p??set eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat el?m??si. http://www.mtv3.fi/luukku
[sane-devel] genesys backend
Hi I spent some time on fixing the last few bugs in the gl841 part known to me and preparing the backend for the final inclusion of gl841 support needed for my scanner. The attached patch primarily adds yet another shading calibration method, using the black and white strips at the top of the scanning area. It also adds support for led exposure calibration needed for cis scanners and instant power saving features. The latter is needed because my scanner uses some gpio to completely shut down some circuits like motor drivers and led drivers. The function slot is called from sane_start and sane_cancel, as these seem to be the functions at the begin and end of each scan. The version in the patch mainly shuts down the afe. The patch is not a full patch to get a Canon LiDE 35/50 scanner to work. There is a patch on my private webspace which does that(see below). Regarding the problem of the scanner not delivering any data i found that it's only a problem of the first read after opening the scanner. So my solution is to prepare a simple one line read, setting the usb timeout to 1 second and then read, without checking the result(timeout is reset to 30s afterwards). If the transmission fails, the scanner will still think it succeeded, and later reads will work. It is not clear to me why the scanner sometimes missends the first bulk transfer originated from the scanner, but i suspect a bad usb transmission, although the transfer does not generate any log messages. I tried to implement real lineart, and got it to work most of the time. It was a matter of setting the scanner to do lineart and then simply pass the data on to the frontend, inverting all bits. There are still some combinations of settings which may lead to a failed scan, as there are some more complicated things still missing(stagger correction, line shrinking). Powersaving for the Canon LiDE 35(and hopefuly LiDE 50) works now, too. I don't know if it is complete, but i could not measure a difference between the scanner just plugged in and after a scan. My measuring method was rather inaccurate, so i may be missing something. As always a full patch to get Canon LiDE 35/50 to work can be found here(will be updated to match experimental cvs): http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2 It is now ready to be extensively tested. I guess using lineart will reveal some problems, as mentioned above. But i stress tested the color and gray modes to some extend using xsane and zooming the preview. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_calibration.diff.gz Type: application/x-gzip Size: 6525 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050923/1a0204aa/genesys_calibration.diff.bin From x.mo...@gmail.com Fri Sep 23 23:20:38 2005 From: x.mo...@gmail.com (Martin Haag) Date: Fri Sep 23 23:21:03 2005 Subject: [sane-devel] USB recordings MD6190 available Message-ID: f9a986b805092316207bc6f...@mail.gmail.com Hi, I've recorded some USB traffic with SniffUSB from the Medion MD6190 scanner tonight. I am going to analyse them in the near future, but if one can't wait the scans are available on http://mibix.de/wiki/index.php/MD6190_USB_Recording . By the way, maybe someone can give me some hints how to analyse such a huge amount of data :) I thought about comparing always two of the files with a block orientated compare tool such as beyond compare on wind-ws. ( hm I can't belive that I sayed this. Ok let's use diff *g* ) cya Martin Haag -- http://mibix.de mailto:x.mo...@gmail.com
[sane-devel] Re: HP 4570c - any progress?
Hi Daniel Franke schrieb: On Sunday 11 September 2005 18:29, I wrote: Is currently anyone working on this specific driver? If not, is there any code to pick up? Any docs from HP someone already acquired? I would also appriciate some hints/documentation about GL841/GL646 (which seems to be related) [3]. Links to documentation on the gl841 and gl646 chips can be found here: http://www.meier-geinitz.de/sane/genesys-backend/ But the log looks different to the ones i get from my gl841-based scanner. This does not mean it is completely incompatible. We don't have any documentation about the usb protocol, just about the register and memory layout of the gl841 and gl646. To view the log you can try to run SnoopyPro in wine. Wine constantly complains about not knowing usbsnpys.vxd, but otherwise it works for viewing the log. Re-hi all, in reply to my own mail: no answer within 48 hours presumely means that nobody works on this specific driver, that there are no docs available and that there's no code to pick up - correct?! If you want to experiment with your scanner without using sane you could extract code from my canon lide35 test program: http://www.pirsoft-dsl-dropzone.de/ Regards, Pierre
[sane-devel] genesys backend
This one should have been sent to the list. I double-checked the From: field, but didn't realize i just removed the wrong To: field. (sent on 2005-09-07 to St?phane VOLTZ stef...@modulonet.fr) Hi St?phane VOLTZ schrieb: Hello, it looks genesys_reorder_components_cis_8 and genesys_reorder_components_cis_16 are missing from your patch. They do exist. Both are generated from FUNCNAME(genesys_reorder_components_cis) in genesys_conv_hlp.c. FUNCNAME(fn) is #defined in genesys_conv.c to be either fn_8 or fn_16. This is very useful for shrink_lines and reverse_ccd, as those only need to know the type of the components(u_int8_t or u_int16t), and apart from that are exactly the same, so the code exists only once, but is included twice, first with u_int8_t as internally used data type and second with u_int16_t. The #defines around the #include define which functions will be generated. The quick test I did hang at the end of scan (which happens when we try to read more data than the scanning area holds). Is there a test case where a scan succeeds ? I'd like to time how it takes for a scan. Because my main concern is that (as you wrote in a previous mail) data may be copied too much. For the rest, I gone through your code, and it looks sensible to me. There is still the possibility that i misunderstood the code in genesys_gl641.c. Could you try to reduce dev-current_setup.lines to lincnt - 1? dev-current_setup should store the format of the data coming from the scanner. If the reading process is missing data, one of the settings is wrong, and reducing the line number should at least enable you to do one scan, and check that the pixel count is right. You may have a raw.pnm generated while reading the data. It should be helpful for determining which settings are bad. It uses the line count and pixel count from dev-current_setup. To view the image you probably need to reduce the line count in the file. Concerning the copying: The data is copied at most 4 times: (reading)- data reordering - line distance/stagger - line shrink - memcpy to destination That is worse than the current solution, where we have (reading)- line shrink - final reordering etc. into destination The best case stayed mostly the same: (reading)- memcpy to destination versus (reading)-final reordering etc. into destination Adding cis support to the current solution would add a reordering before line shrink, because of the planar nature of cis data. What I need is a test case that allow me to compare speed to make up my mind. Regards, Stef Regards, Pierre
[sane-devel] genesys backend
Hi As you might guess, i'm having another patch ready for review. St?phane VOLTZ schrieb: Hello, I have applied your slope table patch in the experimental/genesys. I tested it wtih my MD6571 and everything I tried worked fine. The 'stagger' pattern is indeed : ...0...0 ..0...0. .0...0.. 0...0... Currently the pattern is restricted to this one: .0.0 0.0. because the old code seemed to do it that way, and there is no variable storing the actual width. I've reread the 'genesys_read_ordered_data'. It has 2 phases. First it fills buffer with enough raw data for the second stage, which then copies data to the backend. The complexity comes from all the possible cases when copying raw data in the form required by the backend and frontend combination. One thing that come to my mind is that splitting that copy in a dozen of simple functions (one for each case) would be enough. But, since you're going after something better, I'll wait for it. I doubt it is that much better. I produced about 6 new functions, all in two variants for single and double byte data. There are 5 steps now: step 0: Reading data from scanner. Delegated into its own function, but may be moved back. step 1: genesys_reorder_components_(cis|cis_bgr|bgr)_(8|16) convert byte order, planar and bgr data. genesys_reorder_components_endian_16 converts byte order, and is only available on big endian systems. step 2: genesys_reverse_ccd_(8|16) reverses the effects of ccd layout. It takes line offsets per component for multiple pixels, thus doing line distance correction and unstaggering in one pass. We could convert any stagger pattern (up to 4 pixels width currently) that way. step 3: genesys_shrink_lines_(8|16) shrinks/enlarges lines. step 4: copy result to frontend buffer. This is needed because the conversion functions work on line aligned data, and we may have lines longer than 32768 bytes, thus needing a output buffer. I used the preprocessor to generate the 8/16 bit versions, and i think it is a good idea to put that into an extra file, leading to two extra files. I could expand genesys_conv.c to contain all the mentioned functions, but then there would be two very similar implementations to be kept in sync. The functions may be useful for other backends, too. I changed the way the information about the format of the scanner output is stored. I think it is more understandable this way. I needed 4 buffers. To handle that efficiently i added a set of buffer management functions. Then i completely removed dev-exposure_time. It was still used at quite some places. If that is not okay, i can revert that. Finally i moved the byte order detection from run time detection to compile time detection, using the WORDS_BIGENDIAN macro defined(or undefined) in include/config.h. I think it is high time you get CVS access to SANE. The one thing we will have to mind is to discuss or warn for changes in the common code. Simple fixes and chipset specific changes should be OK. How do i get cvs access? I am already having a user on alioth. I am going to tune the gl646 part for the HP2400. I believe that the changes I have in mind (mostly constants tweaking) shouldn't disturb your current work. Regards, Stef If this patch is okay, we need to discuss calibration. My scanner has as black and a white strip at the beginning of the scanning area, while other scanners seem to be different. I also need additional calibration steps to calibrate the led exposure times to get nearly equal scanning results for all three colors before doing shading. That improves the quality of 16bit scans. The attached patch still is not moving the gl841 part to any working state. As soon as there are checkins into experimental cvs i will update the patch on my website. It still is too large for this mailing list. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_conversion.diff.gz Type: application/x-gzip Size: 16097 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050904/ff511c15/genesys_conversion.diff-0001.bin From mmuel...@gmx.de Mon Sep 5 13:01:28 2005 From: mmuel...@gmx.de (Markus Mueller) Date: Mon Sep 5 13:01:59 2005 Subject: [sane-devel] Astra 3400 Mac OS X References: 20050904180615.gb22...@meier-geinitz.de Message-ID: 26036.1125925...@www72.gmx.net --- Urspr?ngliche Nachricht --- Von: Henning Meier-Geinitz henn...@meier-geinitz.de Hi Henning and all the others! Thanks for your hints!! [sanei_access] sanei_access_lock: open /usr/local/var/lock/sane/ LCK..libusb:005:002-1606-0060-00-00 failed: No such file or directory [plustek] sanei_access_lock failed: 11 This looks a bit strange. Does /usr/local/var/lock/sane/ exist and can files be created by the user you run the frontend with? This was indeed the problem.
[sane-devel] genesys backend
Jens Luedicke schrieb: Hiya... I get the following compiler errors when trying to build the genesys backend: ... genesys.c:2144: error: structure has no member named `bulk_write_register' genesys.c:2191: error: structure has no member named `bulk_write_register' genesys.c: In function `genesys_white_shading_calibration': genesys.c:2367: error: structure has no member named `bulk_write_register' genesys.c: In function `genesys_start_scan': genesys.c:3160: error: structure has no member named `bulk_write_register' genesys.c: In function `genesys_read_ordered_data': genesys.c:3536: error: structure has no member named `bulk_read_data' genesys.c: In function `sane_genesys_close': genesys.c:4530: warning: passing arg 1 of `free' discards qualifiers from pointer target type make[1]: *** [genesys.lo] Error 1 make[1]: Leaving directory `/home/jens/devel/sane-backends/backend' make: *** [all-recursive] Error 1 Looks like a really old genesys_low.h to me. St?phane, there is still the old version in experimental cvs. Jens, please copy this file, too. At least bulk_write_register is already defined in experimental cvs. Regards, Pierre
[sane-devel] genesys backend
Jens Luedicke schrieb: St?phane VOLTZ wrote: I checked the geneys_low.h that I forgot this morning. btw, the current changes don't work at all for me (LiDE 50): scanimage: open of device genesys:libusb:001:006 failed: Error during device I/O I prefer to not change too much at a time. The genesys_gl841.c code is mostly the old one. The final patch will replace a large amount of code there, but my codebase is not yet stable enough. I updated the patch on my website, but there are no improvements over the patch posted on this list. http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2 Regards, Pierre
[sane-devel] genesys backend
Hi St?phane VOLTZ schrieb: Le Lundi 29 Ao?t 2005 20:01, Pierre Willenbrock a ?crit : ... Next i'd like to rewrite genesys_read_ordered_data to be more maintainable and able to convert the cis style planar data to chunky data. It is indeed a rather complicated function. Data doesn't come in an easy form. But I don't exactly see why you want to convert to planar data first. What i meant was that the function needs to be able to convert from planar data to chunky data. CIS color scans work mostly like grey scans, but the led color is changed every line, and scancnt is incremented every third line. This leads to whole lines of a single component in the output data of cis scanners: cis: ... ... ... ccd: RGBRGB... For that i need to know what the stagger effect exactly is. I am not sure i got that one right. At high motor resolution, lines are staggered, ie they aren't horizontal lines. On pixel is on a line, the folowing colunm is on another ... A drawing may be more evident: 'O' are pixel of on horizontal line, '.' other lines data ...O.O.O.O.O.O.O ..O.O...O.O...O.O...O.O...O.O...O.O...O. .O...O.O...O.O...O.O...O.O...O.O...O.O.. O.O.O.O.O.O.O... Is that a property of the ccd-array? The high motor resolution can't possibly be the reason for that pattern. The most error i would expect from motor activity is a difference of a single line between the first and the last pixel in the scanned data. Is that pattern correct? I would expect something more like this: ...0...0 ..0...0. .0...0.. 0...0... But i would guess it heavily depends on the physical layout of the optical cells on the ccd chip. In the end this is a multiline operation like line distance correction, so i will do line distance correction directly after un-staggering. ... Regards, Stef Regards, Pierre
[sane-devel] genesys backend
Hi
As promised
Pierre Willenbrock schrieb:
Next i will implement the slope table generation in the way St?phane
suggested.
i am sending the result of this work. I introduced a new flag
GENESYS_FLAG_ALT_SLOPE_CREATE to indicate that the alternate slope
creation functions should be used.
Apart from that the patch contains my version of
sanei_genesys_exposure_time(called sanei_genesys_exposure_time2 to not
collide with uses of the other function) and a few bug fixes:
* size argument of sanei_genesys_create_gamma_table changed from float
to int
* sanei_genesys_read_reg_from_set and sanei_genesys_set_reg_from_set
check for address of current register. If this is 0 they should stop.
* fixed raw data dumping: should write first set of data and close file
* moved call to sanei_genesys_init_structs to before init_options as
init_options depends on an initialized device struct.
Next i'd like to rewrite genesys_read_ordered_data to be more
maintainable and able to convert the cis style planar data to chunky data.
For that i need to know what the stagger effect exactly is. I am not
sure i got that one right.
The conversion stack i have in mind looks like this:
1. (opt)uncis (assumes color components to be laid out planar)
2. (opt)unstagger (assumes pixels to be depth*channels/8 bytes,
unshrinked)
3. (opt)shrink_lines (assumes pixels to be depth*channels/8 bytes)
4. (opt)reverse_RGB (assumes pixels to be BGR or BBGGRR))
here we should save the finished lines for use with line distance correction
5. (opt)line_distance_correction (assumes RGB or RRGGBB)
My implementation currently used for Canon LiDE 35 does quite a lot byte
moving which considerably slows down the conversion, and is probably not
correct regarding the stagger effect.
Regards,
Pierre
-- next part --
diff -ur experimental/genesys/genesys.c transit/backend/genesys.c
--- experimental/genesys/genesys.c 2005-08-28 16:49:58.415784750 +0200
+++ transit/backend/genesys.c 2005-08-29 17:32:04.443483750 +0200
@@ -149,6 +149,7 @@
/* */
/* Write data to a pnm file (e.g. calibration). For debugging only */
+/* data is RGB or grey, with little endian byte order */
SANE_Status
sanei_genesys_write_pnm_file (char *filename, u_int8_t * data, int depth,
int channels, int pixels_per_line, int lines)
@@ -214,7 +215,7 @@
{
SANE_Int i;
- for (i = 0; i GENESYS_MAX_REGS; i++)
+ for (i = 0; i GENESYS_MAX_REGS reg[i].address; i++)
{
if (reg[i].address == address)
{
@@ -231,7 +232,7 @@
{
SANE_Int i;
- for (i = 0; i GENESYS_MAX_REGS; i++)
+ for (i = 0; i GENESYS_MAX_REGS reg[i].address; i++)
{
if (reg[i].address == address)
reg[i].value = value;
@@ -298,6 +299,8 @@
return status;
}
+ *val = 0;
+
status =
sanei_usb_control_msg (dev-dn, REQUEST_TYPE_IN, REQUEST_REGISTER,
VALUE_READ_REGISTER, INDEX, 1, val);
@@ -421,6 +424,7 @@
}
/* returns pixels per line from register set */
+/*candidate for moving into chip specific files?*/
static int
genesys_pixels_per_line (Genesys_Register_Set * reg)
{
@@ -440,7 +444,7 @@
/** read the number of valid words in scanner's RAM
* ie registers 42-43-44
*/
-
+/*candidate for moving into chip specific files?*/
static SANE_Status
genesys_read_valid_words (Genesys_Device * dev, int *words)
{
@@ -487,6 +491,253 @@
return sanei_genesys_write_register (dev, 0x0f, 0x00);
}
+/* main function for slope creation */
+/**
+ * This function generates a slope table using the given slope
+ * truncated at the given exposure time or step count, whichever comes first.
+ * The reached step time is then stored in final_exposure and used for the rest
+ * of the table. The summed time of the acerleation steps is returned, and the
+ * number of accerelation steps is put into used_steps.
+ *
+ * @param devDevice struct
+ * @param slope_tableTable to write to
+ * @param max_step Size of slope_table in steps
+ * @param use_steps Maximum number of steps to use for acceleration
+ * @param stop_atMinimum step time to use
+ * @param vstart Start step time of default slope
+ * @param vend End step time of default slope
+ * @param steps Step count of default slope
+ * @param g Power for default slope
+ * @param used_steps Final number of steps is stored here
+ * @param vfinal Final step time is stored here
+ * @return Time for acceleration
+ * @note all times in pixel time
+ */
+static SANE_Int
+genesys_generate_slope_table (
+u_int8_t * slope_table, unsigned int max_steps,
+unsigned int use_steps, u_int16_t stop_at,
+u_int16_t vstart, u_int16_t vend, unsigned int steps, double g,
+unsigned int *used_steps, unsigned int *vfinal)
+{
+ double t
[sane-devel] genesys backend
Hi The attached patch against experimental cvs leads to a mostly working Canon LiDE 35. There is support for color and grey scans at arbitrary resolutions. There are some shortcomings in the code, but those are mostly structural. Currently known bugs: 1 You need to replug the scanner every other retry 2 Sometimes the calibration process hangs 3 Some scanning rects lead to stange behaviour 4 Lineart not supported 5 No powersaving(after first use draws about 100mA) 5 should be easy, as i already figured out the needed gpios and registers. But powersaving is rather optional, and other problems are more pressing. 4 is some work, as a lot of functions need to be made aware of single bit data. 2 and 3 fall in the category (sometimes) reproducible, but no clue why these happen. Does anyone have a patch for valgrind to work with libusb? For 1 i guess i need more documentation on the usb interface of the scanner. The windows driver does some things(other than register and bulk transfers) i don't understand, so i didn't implement them in the backend. If there is any documentation on the usb interface, please point me to it. The documentation on the chips does not include this. Next i will implement the slope table generation in the way St?phane suggested. The attached patch needs to be uncompressed with bunzip2. gzip did compress only to about 50kb. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_gl841.diff.bz2 Type: application/x-bzip2 Size: 40637 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050827/0b35d8f4/genesys_gl841.diff-0001.bin From ni...@feltham-family.co.uk Sat Aug 27 11:20:13 2005 From: ni...@feltham-family.co.uk (Nigel Feltham) Date: Sat Aug 27 12:09:35 2005 Subject: [sane-devel] Super CoolScan Slide Feeders Message-ID: 200508271220.13903.ni...@feltham-family.co.uk I cannot help with info on the SF-100 but the LS-1000 scanner itself works fine under SANE. The only Nikon film scanner to avoid is the original LS-10 as it's a real pain to get it to work (the reason I gave up and upgraded to LS-1000) - I have one and it's impossible to use reliably on either windows or linux unless using an ISA SCSI controller (so needs an old PC) and is unsupported by SANE. It does work intermittenyly under Vuescan on Linux on a PCI card (according to Nikon's website it doesn't work at all under windows on PCI so one point for Linux there) but only for actual scanning - automatic calibration fails. The reason appears to be that it only supports SCSI 1 data speeds and PCI cards try to transfer data too quick (they only support SCSI II and later) and corrupt it. You may want to email the makers of Vuescan ( http://www.hamrick.com/ ) about support for the Slide feeders - the software's not free but does support many scanners (mostly SCSI) that SANE doesn't as they have proprietry info that the manufacturers won't give SANE coders access to (due to NDA's that mean the resulting Source cannot be distributed).
[sane-devel] genesys backend
Hi stef schrieb: On Sat, Aug 27, 2005 at 12:43:38AM +0200, Pierre Willenbrock wrote: ... Currently known bugs: 1 You need to replug the scanner every other retry 2 Sometimes the calibration process hangs ... Hello, I got the same 1 an 2 issue. I don't know if you have the same problem, but it appeared that the backend has to read 1 more data line than indicated in the LINCNT register. Before I figured this out, the first scan for calibration succeeded, but not the in following runs, and it hanged in shading calibration while reading data. Regards, Stef That is not quite the problem i am having. The scanner does not send any extra lines. For #1 i am plugging in the scanner, use scanimage. The next try of scanimage succeeds in 50% of all cases. If it does not succeed, scanimage simply hangs on first read. From the debugging output i see that the scanner should be willing to send data(VALIDWORD != 0), but the bulk read never finishes. I also experience this with my test program, but that will recover on a third try, while scanimage does not. When #2 occurs the scan should theoretical begin, the MOVE register is written to, but the scanner does not do anything, and VALIDWORD never changes from 0. Either the scanner does not receive the write, or the transmitted data is corrupt. From the logs i guess there are two usb operations which report the state of the register interface and the bulk interface. But the returned data of these operations is always the same, and the scanner can operate without them, so i don't know how to use them. I will try to find out whether the data changes when starting my test program multiple times. I was hoping someone could provide more information about the usb interface. The chip documentation does not tell anything on how to actually access a register on the control message level. There is another bug(just to extend the bug list): When the scan buffer runs full and the scanner moves back there will be errors in the following line. I don't know if this is because the scan buffer runs full, or because the scan buffer runs empty shortly after(the scanner does not go forward fast enough to reach the last scanning position before the buffer runs empty). Regards, Pierre
[sane-devel] genesys backend
Jens Luedicke schrieb: On 8/15/05, Pierre Willenbrock pie...@pirsoft.dnsalias.org wrote: Hi [proposed changes to slope generation] I attached the code i am using. Could you create a patch for use with current CVS? I tried to apply your code, but some things don't work out for me and I'm not a developer and not familiar with the API + changes. With anonymous cvs working again i can now provide a patch against current cvs. genesys_slope.diff.gz (gzipped) contains the changes to slope generation(against current cvs). If you want to test on a gl646 based scanner, you will probably need to (largely) tweak the values in the motor structs in genesys_devices.c to get it to work(if you get it to work at all, the exposure time and assumed step count in gl646 code may be completely wrong). I was unable to derive good numbers from the code alone. All step times are for full steps, even when used for half or quarter step mode. The code currently does the needed shifting for times and step count. I did not change anything inside genesys_gl646.c, mainly because i do not own a scanner with this chip. The attached code in my last mail was not meant to be complete, i attached it for clarification. For a partly working Canon LiDE 35 you will need to apply genesys_gl841.diff.gz (gzipped) to experimental cvs. The patch already contains the slope generation code. Only color mode is working currently. And not even bugfree. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_slope.diff.gz Type: application/x-gzip Size: 3980 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050819/a3ddd7f8/genesys_slope.diff-0001.bin -- next part -- A non-text attachment was scrubbed... Name: genesys_gl841.diff.gz Type: application/x-gzip Size: 31784 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050819/a3ddd7f8/genesys_gl841.diff-0001.bin From kenwh...@21cn.com Fri Aug 19 10:29:15 2005 From: kenwh...@21cn.com (kenwhale) Date: Fri Aug 19 02:36:32 2005 Subject: [sane-devel] About dll backend In-Reply-To: yb949180976987.16...@receive3.inner-21cn.com References: yb949180976987.16...@receive3.inner-21cn.com Message-ID: 4305b47b.60...@21cn.com Nicer (and the default) is the case where the dll backend is linked as a shared library to the frontend and the dll backend loads backends with dlopen (on demand). This way you just have to add your backend library to /usr/lib/sane (or whereever it's found) and add the name of your backend to dll.conf. Bye, Henning So,Is there any dll backend I can link to?Or I need write it myself? If there are some dll backend which can open all available backends on runtime,how can they do this ? Open every backend and call it's sane_get_devices() ? Thanks a lot.
[sane-devel] genesys backend
Hi The canon lide 35 is now scanning in color at any resolution. No calibration yet. I'd like the calibration code to use a more generic interface to the scanning logic before. But that will have to wait. This time i want to propose a new mechanism for generating slope tables in the genesys backend, which i implemented for my work. In my opinion it is sufficient to describe one slope for each step type. This slope is truncated as soon as the exposure time is reached. This leads to a variable step count, which can be used to shorten the acceleration/deceleration considerably. I used slopes derived from a start step time(vstart), a final step time(vend), a power(g) and a step count(steps): p[i] = (i/(steps-1))^g t[i] = vstart*(1-p[i])+vend*p[i] For i in 0..(steps-1). Pros: + less Constants + a means for calculating exposure time(which is limited by maximum motor speed and number of pixels processed per line) Cons: - variable step count - may be not applicable to all supported scanners - breaks the current code I attached the code i am using. Related to this and just out of interest: Does the gl646 expect its slope tables to contain STEPNO*2 resp. FASTNO*2 steps, too? Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_gl841_part.c Type: text/x-csrc Size: 1927 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050815/fc225754/genesys_gl841_part.c -- next part -- A non-text attachment was scrubbed... Name: genesys_part.c Type: text/x-csrc Size: 3916 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050815/fc225754/genesys_part.c From o...@member.fsf.org Mon Aug 15 05:17:55 2005 From: o...@member.fsf.org (Olaf Meeuwissen) Date: Mon Aug 15 05:10:50 2005 Subject: [sane-devel] Epson Perfection 3490 PHOTO In-Reply-To: m3ek911kar@pacbell.net (Bjorn Solberg's message of Wed, 10 Aug 2005 15:47:24 -0700) References: m37jet91od@pacbell.net 200508102259.52110.oliver.schwa...@gmx.de m3ek911kar@pacbell.net Message-ID: 87d5of4xoh@qed.penguin.lib.org Bjorn Solberg bjorn_s...@hekneby.org writes: Oliver Schwartz writes: Hi, I recently got the Epson Perfection 3490 PHOTO scanner. Does anyone else have any experience with this scanner, and/or can tell me whether it is (or will be in the near future) supported by SANE? Any pointers on how I can make it work with SANE is much appreciated. I got some infos and a patch concerning this scanner. I'll add support for it to the snapscan backend in the next few days. I'll let you know if the code is in CVS, so you can test it. The 3490 and 3590 are similar to the 2480 and 2580 respectively. You should not have much trouble getting these to work with the snapscan backend. That sounds like good news, I hope the patch is simple and that it'll work well. So it will use the snapscan backend, not the epson one? Yes, it will use the snapscan backend. This scanner does not speak the EPSON ESC/I protocol which the epson backend assumes. -- Olaf Meeuwissen FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 30EF893A/2774 815B DE83 06C8 D733 6B5B 033C C857 30EF 893A Penguin's lib! -- I hack, therefore I am -- LPIC-2
[sane-devel] genesys gl841 patch
Hi, This is the newest and hopefully final version of my genesys_com patch. This patch makes the bulk transfer functions chip specific and completes the gl841 side with a gamma bulk transfer function. It also moves the last two occurances of send_slope_table inside the chip specific init functions. Lastly it corrects the register arrays for gl841. Please check it does not break anything on the gl646 side. If there are no complaints this patch can go into cvs. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_com.diff.gz Type: application/x-gzip Size: 6982 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050808/d6811883/genesys_com.diff-0001.bin From an...@pfeiffer.edu Mon Aug 8 13:26:35 2005 From: an...@pfeiffer.edu (m. allan noah) Date: Mon Aug 8 13:27:33 2005 Subject: [sane-devel] latest sane screwed up my hoary box In-Reply-To: c18d39a20508060936df4f...@mail.gmail.com References: c18d39a20508060936df4f...@mail.gmail.com Message-ID: pine.lnx.4.61.0508080922130.25...@limos.pfeiffer.edu On Sat, 6 Aug 2005, Jon Dodson wrote: so i downloaded the latest sane to support my astra scanner. i ran configure, no worries, ran make, no worries. ran sudo checkinstall -D and my whole box went crazy. windows started popping up, then all my gnome icons were X'ed out. finally i can not login in it says Cannot cd to /home/jdodson I cant login with any other user. I downloaded sane via your website, WTF kind of software is this? Some sort of trojan? it was the sanebackend 1.0.15 from here: ftp://ftp.sane-project.org/pub/sane/sane-backends-1.0.15/ I am using an old laptop because all I can do it go into single user mode on my ubuntu machine, a little help here as you caused the issue in the first place? woah, back off buddy. checkinstall is not part of sane. if running the command 'checkinstall' caused all sorts of crazy problems, then i recommend you start with that, since it presumably does not _run_ any part of sane either. btw I install packages from source all the time, first issue i have ever had. if you do this all the time, wtf is up with you not following the directions that come with the source? the directions that dont mention checkinstall, i might add. you went off into the weeds own your own, now you get to find your way back to the trail on your own. allan -- 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] Genesys gl841
St?phane VOLTZ schrieb: Le Mercredi 3 Ao?t 2005 16:35, Pierre Willenbrock a ?crit : So i conclude that the gl646 expects the shortest pixeltime first, while the gl841 wants the longest pixeltime first. Is this correct or am i doing something wrong? GL646 behaves like GL841 in this case, higher values first. Thanks for the answer. I will have a closer look at sanei_genesys_create_slope_tables to find out how to use it correctly. I did some more work for my Canon LiDE 35. Bulk access differs in all cases between gl646 and gl841. genesys_com.diff.gz moves the bulk functions into the chip specific source files. I also moved the last two occurences of send_slope_table in genesys.c to genesys_gl646.c and genesys_gl841.c, since the gl841 uses 5 tables instead of 2(and therefore should initialize them). I was able to get the scanner past most stages in scanning a page with scanimage, though i doubt it scans anything correctly. Sane now hangs while trying to read data from the scanner. It gets a block of data, but never request another one. I will investigate this one further. If anyone is interested, the changes are in genesys_gl841.diff.gz. genesys_gl841.diff.gz must be applied after genesys_com.diff.gz. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_com.diff.gz Type: application/x-gzip Size: 6249 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050805/6a238bc3/genesys_com.diff-0001.bin -- next part -- A non-text attachment was scrubbed... Name: genesys_gl841.diff.gz Type: application/x-gzip Size: 16826 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050805/6a238bc3/genesys_gl841.diff-0001.bin From henr...@yahoo.fr Fri Aug 5 15:17:55 2005 From: henr...@yahoo.fr (Julien HENRY) Date: Fri Aug 5 15:25:02 2005 Subject: [sane-devel] Is reverse engineering legal ? Message-ID: 20050805151755.6199.qm...@web26604.mail.ukl.yahoo.com Hi, In order to write a backend, I sniff USB logs, and I use disassembler to inspect Windows driver. I have to admit that many functions will be translation Windows ASM-SANE C. Is this legal, and can I say my code is under GPL ? ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger T?l?chargez cette version sur http://fr.messenger.yahoo.com
[sane-devel] Genesys gl841
Pierre Willenbrock schrieb: Bulk access differs in all cases between gl646 and gl841. genesys_com.diff.gz moves the bulk functions into the chip specific source files. I also moved the last two occurences of send_slope_table in genesys.c to genesys_gl646.c and genesys_gl841.c, since the gl841 uses 5 tables instead of 2(and therefore should initialize them). Sorry, i missed one sanei_genesys_bulk_read_data. Corrected patch attached. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: genesys_com.diff.gz Type: application/x-gzip Size: 6300 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050805/3b32ccaf/genesys_com.diff-0001.bin From p...@smedley.info Sat Aug 6 08:48:45 2005 From: p...@smedley.info (Paul Smedley) Date: Sat Aug 6 08:49:22 2005 Subject: [sane-devel] Epson Perfection 2400 Problems Message-ID: 42f4796d.7010...@smedley.info Hi All, Wondering if anyone can suggestion possible reasons for an Epson Perfection 2400 not working on OS/2. Code is built from latest CVS, and many other scanners that use the Snapscan backend are reported to work. Epson Perfection 2400 seems to have problems uploading the firmware - the log ends with: [snapscan] usb_request_sense: usb command error: Error during device I/O [snapscan] usb_request_sense: usb command error: Error during device I/O [snapscan] sane_snapscan_open: download_firmware command failed: Error during device I/O scanimage: open of device snapscan:usbcalls:1 failed: Error during device I/O Full log is at http://smedley.info/epson2400debugoutput.zip Any ideas appreciated. Cheers, Paul.
[sane-devel] Genesys gl841
Hi Yesterday i got gl841_slow_back_home to work correctly. I noticed that sanei_genesys_create_slope_tables generates a slope table which starts at about 100 and ends at 2100. This table is unusable (at least with my canon lide 35). The windows driver sends a linear table starting with a value of 5152 and ending with 1596. So i conclude that the gl646 expects the shortest pixeltime first, while the gl841 wants the longest pixeltime first. Is this correct or am i doing something wrong? Currently i am using a simple for-loop to generate my tables, but this cannot be a long term solution. I found the slope table handling code to be not endian-safe, at least in experimental cvs. The slope tables are always sent in machine endianness. Regards, Pierre
[sane-devel] genesys gl841
I did some minimal work on the driver recently. My goal was to get the scanner(canon lide35) to physically do something. The gl841 does not understand the bulk register transfer used for gl646, so i modified sanei_genesys_bulk_write_register to do single register writes. After fixing gl841_init_registers and gl841_send_slope_table (and modifying some other places) the scanner began to move its head. I also introduced the functions gl841_bulk_write_data_gamma and gl841_set_buffer_address_gamma, because the gamma memory is seperate from the rest. Although the head moves, the motor control is not complete, and scanning still is not working. I attached a patch against experimental cvs for anyone interested. pierre -- next part -- A non-text attachment was scrubbed... Name: genesys.diff.gz Type: application/x-gzip Size: 12116 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050729/858fbf37/genesys.diff.bin From o...@member.fsf.org Fri Jul 29 23:42:41 2005 From: o...@member.fsf.org (Olaf Meeuwissen) Date: Fri Jul 29 23:36:17 2005 Subject: [sane-devel] some more libsane.usermap additions In-Reply-To: 87br4lyl7s@frigate.technologeek.org (Julien BLACHE's message of Fri, 29 Jul 2005 12:12:39 +0200) References: 2097352...@web.de 8764v3uwu4@frigate.technologeek.org 87d5p2tqnc.fsf...@zen.epkowa.co.jp 87br4lyl7s@frigate.technologeek.org Message-ID: 87br4l18ni@qed.penguin.lib.org Julien BLACHE j...@jblache.org writes: Olaf Meeuwissen olaf.meeuwis...@avasys.jp wrote: +# Epson Corp.|GT-15000 (ES-7000) +# Epson Corp.|Expression 1XL (ES-1G) +# Epson Corp.|Perfection 4990 (GT-X800) -# Epson Corp.|Stylus CX3650 +# Epson Corp.|Stylus CX3500/CX3600/CX3650 (PX-A550) +# Epson Corp.|Stylus CX4500/CX4600 -# Epson Corp.|Stylus RX620 +# Epson Corp.|Stylus RX620/RX630 (PM-A870) +# Epson Corp.|Stylus RX700 (PM-A900) +# Epson Corp.|(PM-A700) +# Epson Corp.|AcuLaser CX11 (LP-A500) All added/fixed, thanks. Thanks. I believe there are a few more descriptions that can be fixed and/or extended. I'll see if I can find some time to check them later this weekend. Guess I should also prepare a diff to add them to the list of supported scanners in the epson backend (epson_usb.c). Later, -- Olaf Meeuwissen FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 30EF893A/2774 815B DE83 06C8 D733 6B5B 033C C857 30EF 893A Penguin's lib! -- I hack, therefore I am -- LPIC-2
