[sane-devel] Problems in ARM (atmel) linux - Travelscan 662 (sane-plustek)
Am Dienstag, 27. November 2007 03:05:44 schrieb m. allan noah: sounds like somewhere there is an array of 3-byte R,G,B structs, which will be padded on arm to 4 bytes. this problem was discovered by DAKA and myself when building sane for the nslu2/openembedded platform. the attached patch added some packing directives to correct the issue, but this was sane 1.0.17, not current. Hi, you are right, this is the problem, in CVS should be a corrected version, but I had no chance to test it on my SLUG. Let us know if Allans patch helps and/or try the CVS version and tell us if this works too... TIA Gerhard
[sane-devel] Question about pixel packing
Hi all. I'm still trying make scanner working on unix. I created program that replaying usbsnoop logs and get image data, but i don't know how i can see scanned image. I has information about image data from twain debug log: BUFFER_INFO Bytes Per Line = 5100 Pixel Width = 850 Pixel Height = 1170 SCANNER PARAMETERS PixelLeft = 0 PixelTop = 0 PixelWidth = 2552 PixelLength = 3510 Bits Per Channel = 16 Pixel Packing = PACKED Pixel Order = RGB Gamma Bytes Per Entry = 2 I tried to save data as pnm file (adding pnm header to the raw data), but because of image packing (i think :)) i get garbage. Where i can read more information about image packing or can somebody help me with my problem? Image data located here http://hp46xx.narod.ru/img.dat.bz2 (4.3Mb) -- Best Regards. Alexander Bechikov
[sane-devel] Question about pixel packing
Alexander Bechikov goo at t72.ru wrote: Hi, Others here will know better than me, but anyway. BUFFER_INFO Bytes Per Line = 5100 Pixel Width = 850 So that's 6 bytes / line, which is coherent with the info below. Pixel Height = 1170 So you should get 5.0 MB of data. SCANNER PARAMETERS Bits Per Channel = 16 Coherent with the data above. Pixel Packing = PACKED Pixel Order = RGB So that's RRGGBB, assuming the byte ordering is OK. Gamma Bytes Per Entry = 2 And here I'm not sure what this is. Others here should know :) Where i can read more information about image packing or can somebody help me with my problem? I've probably told you what you already knew, but one simple test you can do is scan sheets of red paper, blue paper and green paper and look at the data you get. Should make it easy to spot the color components, and determine if there's anything else besides color components in the data you get from the scanner. I'd do it this way :) JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] USB to parallel port converters
I have a Mustek 1200CP parallel scanner, which appears to be supported by SANE, but no parallel port on my system. I do have a USB to parallel port converter, which works fine with my printer, but I can't get it to recognise my scanner. sane-find-scanner -p -vv /dev/usb/lp0 doesn't find any scanners. Is there something else I should try, or won't it work with a converter? Neil Youngman
[sane-devel] Canon LIDE 90
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 __ Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131
[sane-devel] Problems in ARM (atmel) linux - Travelscan 662 (sane-plustek)
I'm using the current version. So I wasn't able to apply the patch using the patch utility. However, I manually edited the plustek-usb.h file to refect the changes in the patch that allan provided. It doesn't help. I still have the same issue. Gerhard, Should I use the latest version from CVS? (ie 1.0.18?). thanks -sk - Original Message - From: Gerhard Jaeger Sent: Mon, 11/26/2007 11:30pm To: sane-devel at lists.alioth.debian.org Cc: m. allan noah ; saravakr at cisco.com Subject: Re: [sane-devel] Problems in ARM (atmel) linux - Travelscan 662 (sane-plustek) Am Dienstag, 27. November 2007 03:05:44 schrieb m. allan noah: sounds like somewhere there is an array of 3-byte R,G,B structs, which will be padded on arm to 4 bytes. this problem was discovered by DAKA and myself when building sane for the nslu2/openembedded platform. the attached patch added some packing directives to correct the issue, but this was sane 1.0.17, not current. Hi, you are right, this is the problem, in CVS should be a corrected version, but I had no chance to test it on my SLUG. Let us know if Allans patch helps and/or try the CVS version and tell us if this works too... TIA Gerhard
[sane-devel] Problems in ARM (atmel) linux - Travelscan 662 (sane-plustek)
I checked out the latest version from CVS. I still have the same issue. thanks -sk - Original Message - From: sane-devel-bounces+saravakr=cisco.com at lists.alioth.debian.org on behalf of sarav...@cisco.com Sent: Tue, 11/27/2007 10:12am To: Gerhard Jaeger ; sane-devel at lists.alioth.debian.org Subject: Re: [sane-devel] Problems in ARM (atmel) linux - Travelscan 662 (sane-plustek) I'm using the current version. So I wasn't able to apply the patch using the patch utility. However, I manually edited the plustek-usb.h file to refect the changes in the patch that allan provided. It doesn't help. I still have the same issue. Gerhard, Should I use the latest version from CVS? (ie 1.0.18?). thanks -sk - Original Message - From: Gerhard Jaeger Sent: Mon, 11/26/2007 11:30pm To: sane-devel at lists.alioth.debian.org Cc: m. allan noah ; saravakr at cisco.com Subject: Re: [sane-devel] Problems in ARM (atmel) linux - Travelscan 662 (sane-plustek) Am Dienstag, 27. November 2007 03:05:44 schrieb m. allan noah: sounds like somewhere there is an array of 3-byte R,G,B structs, which will be padded on arm to 4 bytes. this problem was discovered by DAKA and myself when building sane for the nslu2/openembedded platform. the attached patch added some packing directives to correct the issue, but this was sane 1.0.17, not current. Hi, you are right, this is the problem, in CVS should be a corrected version, but I had no chance to test it on my SLUG. Let us know if Allans patch helps and/or try the CVS version and tell us if this works too... TIA Gerhard -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org
[sane-devel] Canon LIDE 90
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
[sane-devel] SQ11 aka SCAN11 aka Mii-S11
Hello, I have updated sane-find-scanner to test for what I believe is SQ11 chip. can anyone else with the same chip try out the patch (sane.sq11.test.diff) and see if they get the same result? I have attached full output of run at check-usb-chip-sq11.log. Below is non-verbose output : # ./tools/sane-find-scanner found USB scanner (vendor=0x05da, product=0x30d9, chip=SQ11) at libusb:004:002 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. Adam -- next part -- A non-text attachment was scrubbed... Name: sane.sq11.test.diff Type: text/x-patch Size: 9045 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071127/3ae8c852/attachment-0002.bin -- next part -- A non-text attachment was scrubbed... Name: check-usb-chip-sq11.log Type: text/x-log Size: 19854 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071127/3ae8c852/attachment-0003.bin
[sane-devel] Problems in ARM (atmel) linux - Travelscan 662 (sane-plustek)
calibration data from file [plustek] /root/.sane/Syscan_TravelScan_662-fine.cal [plustek] File /root/.sane/Syscan_TravelScan_662-fine.cal not found [plustek] usb_switchLampX(ON=1,TPA=0) [plustek] Switch Lamp: 1, regs[0x5b] = 0x09 [plustek] sane_start done [plustek] cano_DoCalibration() done [plustek] - [plustek] Static Gain: [plustek] REG[0x3b] = 10 [plustek] REG[0x3c] = 10 [plustek] REG[0x3d] = 10 [plustek] Static Offset: [plustek] REG[0x38] = 0 [plustek] REG[0x39] = 0 [plustek] REG[0x3a] = 0 [plustek] - [plustek] calibration done. [plustek] usb_SetScanParameters() [plustek] usb_GetMCLKDivider() [plustek] usb_GetMCLKDiv() [plustek] * PhyBytes = 612 [plustek] * PhyLines = 225 [plustek] * TotalBytes = 137700 [plustek] usb_SetScanParameters() done. [plustek] Warmup: skipped for CIS devices [plustek] ImageProc is: ColorDuplicate8_2 [plustek] * scan-dwFlag=0x4400 [plustek] usb_ScanBegin() [plustek] usb_MapDownload() [plustek] * brightness = 0 - 0 [plustek] * contrast = 0 - 1.000 [plustek] * downloading map 0... [plustek] * downloading map 1... [plustek] * downloading map 2... [plustek] usb_MapDownload() done. [plustek] usb_DownloadShadingData(0) [plustek] -- BYPASS [plustek] usb_ScanBegin() done. [plustek] SampleY Flag set (50 != 75, wSumY=25) [plustek] Reading the data now! [plustek] PhyDpi.x = 50 [plustek] PhyDpi.y = 75 [plustek] UserDpi.x= 50 [plustek] UserDpi.y= 50 [plustek] NumberOfScanBufs = 428 [plustek] LinesPerScanBufs = 13696 [plustek] dwPhyBytes = 612 [plustek] dwPhyPixels = 202 [plustek] dwTotalBytes = 137700 [plustek] dwPixels = 202 [plustek] dwBytes = 606 [plustek] dwValidPixels= 202 [plustek] dwBytesScanBuf = 19584 [plustek] dwLinesDiscard = 0 [plustek] dwLinesToSkip= 1 [plustek] dwLinesUser = 150 [plustek] dwBytesLine = 606 [plustek] usb_IsDataAvailableInDRAM() [plustek] Data is available [plustek] reader_process: READING [plustek] IPC: Transferrate = 100 Bytes/s [plustek] reader_process: finished reading data [plustek] (SIG) Child is down (signal=17) [plustek] drvclose() [plustek] TIME END 1: 7s [plustek] usbDev_stopScan() [plustek] usbDev_ScanEnd(), start=1, park=1 [plustek] Lamp-Timer started (using ITIMER) [plustek] usbDev_close() [plustek] close_pipe (r_pipe) [plustek] sane_cancel [plustek] do_cancel [plustek] TIME END 2: 8s [plustek] sane_close [plustek] sane_exit [plustek] Shutdown called (dev-fd=-1, libusb:004:083) [plustek] Waiting for scanner-ready... [plustek] Switching lamp off... [plustek] LAMP-STATUS: 0x0001 (on) [plustek] Switching Lamp off [plustek] usb_switchLampX(ON=0,TPA=0) [plustek] Switch Lamp: 0, regs[0x5b] = 0x01 [plustek] LAMP-STATUS: 0x (off) [plustek] Lamp-Timer stopped [root at localhost ~]# -- next part -- A non-text attachment was scrubbed... Name: plustek-output.diff Type: application/octet-stream Size: 3231 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071127/75dc4195/attachment-0001.obj
[sane-devel] Canon LIDE 90
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 ___ Jetzt neu! Sch?tzen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00
[sane-devel] Canon LIDE 90
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. __ XXL-Speicher, PC-Virenschutz, Spartarife mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130
[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
Can you send a small image? The image shows the cover of a book... __ XXL-Speicher, PC-Virenschutz, Spartarife mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130 -- next part -- A non-text attachment was scrubbed... Name: out2.jpg Type: image/jpeg Size: 20528 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071127/578aa353/attachment-0001.jpg
[sane-devel] LiDE 90
-Urspr?ngliche Nachricht- Von: Kent Whitten kent at fawkesengineering.com Gesendet: 27.11.07 21:22:03 An: Ralf Haueisen ralf.haueisen at web.de Betreff: Sorry I can't hit the sane lis from here. I caught these on the LiDE 90 with a catc analyzer. They are set a bunch of times, but always to the same values. Kent 52 - 02 53 - 04 54 - 02 55 - 04 56 - 02 57 - 04 Hope they help! I tried these values, only noise. 52 = 05, 53=07, 54-57=0 give the result als mailed a bit earlier. Registers 54-57 seem to have no effect at all. I added my genesys_devices.c to this mail. All modifications can be found unter the LiDE 60. Sorry for the ugly code. _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114 -- next part -- A non-text attachment was scrubbed... Name: genesys_devices.c Type: text/x-csrc Size: 23324 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071127/b6c3d5a1/attachment.c
[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] Canon LIDE 90
-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. ___ Jetzt neu! Sch?tzen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- next part -- A non-text attachment was scrubbed... Name: out3.jpg Type: image/jpeg Size: 15955 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071127/d9eed0ef/attachment-0001.jpg
[sane-devel] Canon LIDE 90
-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. the black_white_shading.pnm is just noise without structure __ Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131
[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] ndiswrapper
I've not seen this obvious question come up recently... Is it possible to conceive of solving the general scanner problem by going down a route like ndiswrapper used by the wireless-device people (or would one perhaps end up emulating too many ntoskernel functions...) Dons tyro's asbestos overcoat :-) Bob
[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] ndiswrapper
robert w hall bobh at n-cantrell.demon.co.uk wrote: Hi, Is it possible to conceive of solving the general scanner problem by going down a route like ndiswrapper used by the wireless-device people (or would one perhaps end up emulating too many ntoskernel functions...) ndiswrapper, as the name indicates, is a wrapper for ndis device drivers, that is, exclusively, network device drivers. So, no, it won't work. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Microtek ScanMaker 4900 and mustek_usb2 backend.
Hello, I took the mustek_usb2 back-end, and made it look for Microtek ScanMaker 4900 (05da:30d9) The result was the output as shown below and an 320x240 black and white image with noise. There was no motor action, but there also was no aborts like I had with a3p1. The question is, would it suggest that mustek_usb2 is a promising starting point, or just about any backend will give me such results? comments? - % /usr/local/sane/bin/sane-find-scanner found USB scanner (vendor=0x05da, product=0x30d9, chip=SQ11) at libusb:004:004 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. % /usr/local/sane/bin/scanimage -L device `mustek_usb2:libusb:004:004' is a Mustek BearPaw 2448 TA Pro flatbed scanner % /usr/local/sane/bin/scanimage sq11.img - http://www.missl.cs.umd.edu/~adam/sq11/sq11.pgm -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers
[sane-devel] [Fwd: Re: ndiswrapper]
-- next part -- An embedded message was scrubbed... From: robert w hall b...@n-cantrell.demon.co.uk Subject: Re: [sane-devel] ndiswrapper Date: Tue, 27 Nov 2007 22:21:56 + Size: 1375 Url: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071127/8af5d04d/attachment.eml
[sane-devel] Canon LIDE 90
-Urspr?ngliche Nachricht- Von: Pierre Willenbrock pierre at pirsoft.dnsalias.org Gesendet: 27.11.07 23:03:13 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: -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 52=4 53=8 gives a picture with much less noise. setting for the registers 16 to 1d i can not get out of my usb log. I guess there register set the clock for the read out. Maybe someone else has them? But now it close to midnight. cu. Ralf ___ Jetzt neu! Sch?tzen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00
