[sane-devel] Plustek opticfilm 7600i
On Mon, Jan 6, 2014 at 9:07 PM, Stef wrote: > so this scanner can be added to the genesys backend in the > genesys_gl841.[ch] files (which in fact supports mainly GL842 based models). > However the reported resolution of 7200 doesn't match the 2400 max > resolution for the GL842 chip. Some custom sensor interleaving like for the > gl847 devices ? > Another hurdle is that no 2400 dpi support is done for this kind of > chip. I'm afraid this won't be trivial. > > Do you think you can record an usblog of a preview scan ? I'm using this scanner with an OS X machine, old Powerbook G4 running OS X 10.5.8. Are there any usb logging tools for OS X? (I haven't found anything with Google) -- Regards, Torfinn
[sane-devel] umax: cancel is broken on SCSI scanners
Hello, When I cancel a scan on a SCSI scanner using UMAX backend, the scanner keeps scanning for a couple of seconds. Then the scanner stops and XSane freezes for a couple of minutes (4 or so). Then suddenly everything comes alive and finishes (scanner goes to home position and XSane reports that the operation was cancelled). This happens with UC630 and PowerLook II scanners on two different systems. Seems that the problem is caused by SCSI command queueing - the stall occurs on sanei_scsi_req_flush_all() called by do_cancel() function. Not sure about how umax_reader_process() works - it seems to queue as many read commands as possible. But that shouldn't be a problem since they should complete quickly if they get to the scanner. I don't know what sanei_scsi_req_flush_all() does - just waits until the queue gets empty or tries to delete waiting commands from the queue? Did cancel ever work correctly with umax backend? -- Ondrej Zary
[sane-devel] Looking to get my Mustek A3 1200S flatbed Scanner with GL128 chip working with XSANE
On 06/01/2014 19:32, Aaron Silver wrote: > Stef - > > As part of my New Year's resolutions I'm trying to get back to my > project of scanning with my Mustek 1200 scanner and in digging back > through the emails I see your work back in June, but wasn't sure if > there had been any progress since the update I'm responding to > (included below). > > Were you able to finish updating the interface to work with the GL128 > chipset, or did Real Life intrude and derail you? > > If you could let me know I'd greatly appreciate it. > > Thanks, > > Aaron Silver > > > On Wed, Jun 26, 2013 at 5:52 PM, George Chriss <mailto:gschriss at gmail.com>> wrote: > > New files in the home directory: > > 6) mustek_a32400s_winXPSP3_100dpi_square.pcapng(.bz2) > 7) mustek_a32400s_winXPSP3_150dpi_square.pcapng(.bz2) > 8) mustek_a32400s_winXPSP3_300dpi_square.pcapng(.bz2) > 9) mustek_a32400s_winXPSP3_600dpi_square.pcapng(.bz2) > 10) mustek_a32400s_winXPSP3_1200dpi_square.pcapng(.bz2) > 11) mustek_a32400s_winXPSP3_2400dpi_square.pcapng(.bz2) > > ...the square sizes are only approximately the same size and are > imaged using the top right corner of the scan bed. Each capture > file starts a few seconds after the scanner was powered on. > > and, > 12) mustek_a32400s_winXPSP3_2400dpi_topslice.pcapng.bz2 > > 2400dpi is the highest optical resolution. This capture is > full-width, ~1 cm height. > > > Sincerely, > George > > > > > > On Wed, Jun 26, 2013 at 12:04 AM, Stef <mailto:stef.dev at free.fr>> wrote: > > On 17/06/2013 21:34, George Chriss wrote: >> On Mon, Jun 17, 2013 at 3:14 PM, Stef > <mailto:stef.dev at free.fr>> wrote: >> >> > it took me some time to adapt my decoding scripts from >> usbsnoop to pcap format. >> >> Are there substantial differences (e.g., timing precision) >> between the various formats (usbmon, pcap/ng, usbsnoop)? Is >> there a preferred choice? >> >> > I am now trying to find how much different it is from the >> GL124, which is the closest support chip in genesys backend. >> >> No problems keeping the livestream going for at least another >> month or so. Also open to the idea of swapping out scanners >> if there are other development targets. >> >> + A write-up on remote development: >> http://gchriss.tumblr.com/post/53081576632/remote-development >> >> Sincerely, >> George >> >> >> > Regards, >> > Stef >> > > Hello, > > you need some more logs: > - one at highest hardware CC resolution, full width, but > with minimal height to keep data amount low > - several scan of a small area at different dpi > > I'm trying to find if it is difficult to guess the usage > of the registers, since I don't have the datasheet. > > Using the same version of wireshark you used is OK now my > decoding scripts are modified. > > Regards, > Stef > > Hello, in fact I added support for a donated LiDE 80 first. Having the real device to work on is more practical and fun than remote access. There is also the fact that G124+ chips datasheet isn't available. This means more reverse engineering on one side, and the other side, I didn't make my mind on how to handle this since other chips registers are known. Regards, Stef -- next part -- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20140106/801a6c6a/attachment-0001.html>
[sane-devel] Plustek opticfilm 7600i
On 04/01/2014 15:37, Torfinn Ingolfsen wrote: > On Wed, Jan 1, 2014 at 9:22 AM, Stef wrote: >> running a recent version (from SANE 1.0.24) of the 'sane-find-scanner' >> tool should tell us if it is really a genesys chip inside. > As requested: > root at kg-core1# usr/local/bin/sane-find-scanner -q > found USB scanner (vendor=0x07b3 [Plustek INC], product=0x0c3b [Film > Scanner ], chip=GL842) at libusb:/dev/usb:/dev/ugen2.4 > > this was done under FreeBSD 8.4-stable: > tingo at kg-core1$ uname -a > FreeBSD kg-core1.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #0 r253646: Thu > Jul 25 10:12:31 UTC 2013 > root at kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 > > HTH Hello, so this scanner can be added to the genesys backend in the genesys_gl841.[ch] files (which in fact supports mainly GL842 based models). However the reported resolution of 7200 doesn't match the 2400 max resolution for the GL842 chip. Some custom sensor interleaving like for the gl847 devices ? Another hurdle is that no 2400 dpi support is done for this kind of chip. I'm afraid this won't be trivial. Do you think you can record an usblog of a preview scan ? Regards, Stef
[sane-devel] [PATCH] umax: UC630 supports 300 x 600 dpi
UC630 supports 300 x 600 dpi, not 400 dpi --- backend/umax-uc630.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/backend/umax-uc630.c b/backend/umax-uc630.c index b6c30a5..0fbc59f 100644 --- a/backend/umax-uc630.c +++ b/backend/umax-uc630.c @@ -113,13 +113,13 @@ static unsigned char UC630_INQUIRY[] = 0x00, /* 73 max optical res in 100 dpi */ - 0x04, + 0x03, /* 74 max x_res in 100 dpi */ - 0x04, + 0x03, /* 75 max y_res in 100 dpi */ - 0x04, + 0x06, /* 76-77 fb max scan width in 0.01 inch */ 0x03, 0x52, -- Ondrej Zary
[sane-devel] [PATCH] umax: disable negative for UC630
UC630 does not support negative function - disable it. --- backend/umax-uc630.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/backend/umax-uc630.c b/backend/umax-uc630.c index f3353ab..b6c30a5 100644 --- a/backend/umax-uc630.c +++ b/backend/umax-uc630.c @@ -76,7 +76,7 @@ static unsigned char UC630_INQUIRY[] = /* 60 -62 scanner capability */ 0xfd, - 0x8c, /* 0xbc ? */ + 0x80, 0x03, /* 63 reserved */ -- Ondrej Zary
[sane-devel] [PATCH] umax: disable gamma download for UC630
UC630 does not support gamma download - it aborts the command: [umax] sending 256 bytes of gamma data for color 1 [umax] send_gamma_data [umax] using gamma download curve format type 2 [umax] check condition sense handler (scsi_fd = 3) [umax] check condition sense: ILLEGAL REQUEST [umax] -> illegal field in CDB [umax] -> illegal parameter is in the data parameters sent during data out phase [umax] -> error detected in byte 2 It does not cause any harm but disable it anyway. --- backend/umax-uc630.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/backend/umax-uc630.c b/backend/umax-uc630.c index 5662330..f3353ab 100644 --- a/backend/umax-uc630.c +++ b/backend/umax-uc630.c @@ -83,7 +83,7 @@ static unsigned char UC630_INQUIRY[] = 0x00, /* 64 gamma */ - 0xa1, + 0x00, /* 65 reserved */ 0x00, -- Ondrej Zary
[sane-devel] [PATCH] umax: fix window descriptor block length for UC630
UC630 wants 49 bytes long window descriptor block, not 48. This fixes "too bright" image problem with this scanner. --- backend/umax-uc630.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/backend/umax-uc630.c b/backend/umax-uc630.c index 26c6831..5662330 100644 --- a/backend/umax-uc630.c +++ b/backend/umax-uc630.c @@ -167,7 +167,7 @@ static unsigned char UC630_INQUIRY[] = 0x00, /* 92-93 window descriptor block length */ - 0x00, 0x30, + 0x00, 0x31, /* 94 optical resolution residue (1dpi) */ 0x00, -- Ondrej Zary
[sane-devel] Looking to get my Mustek A3 1200S flatbed Scanner with GL128 chip working with XSANE
Stef - As part of my New Year's resolutions I'm trying to get back to my project of scanning with my Mustek 1200 scanner and in digging back through the emails I see your work back in June, but wasn't sure if there had been any progress since the update I'm responding to (included below). Were you able to finish updating the interface to work with the GL128 chipset, or did Real Life intrude and derail you? If you could let me know I'd greatly appreciate it. Thanks, Aaron Silver On Wed, Jun 26, 2013 at 5:52 PM, George Chriss wrote: > New files in the home directory: > > 6) mustek_a32400s_winXPSP3_100dpi_square.pcapng(.bz2) > 7) mustek_a32400s_winXPSP3_150dpi_square.pcapng(.bz2) > 8) mustek_a32400s_winXPSP3_300dpi_square.pcapng(.bz2) > 9) mustek_a32400s_winXPSP3_600dpi_square.pcapng(.bz2) > 10) mustek_a32400s_winXPSP3_1200dpi_square.pcapng(.bz2) > 11) mustek_a32400s_winXPSP3_2400dpi_square.pcapng(.bz2) > > ...the square sizes are only approximately the same size and are imaged > using the top right corner of the scan bed. Each capture file starts a few > seconds after the scanner was powered on. > > and, > 12) mustek_a32400s_winXPSP3_2400dpi_topslice.pcapng.bz2 > > 2400dpi is the highest optical resolution. This capture is full-width, ~1 > cm height. > > > Sincerely, > George > > > > > > On Wed, Jun 26, 2013 at 12:04 AM, Stef wrote: > >> On 17/06/2013 21:34, George Chriss wrote: >> >> On Mon, Jun 17, 2013 at 3:14 PM, Stef wrote: >> >> > it took me some time to adapt my decoding scripts from usbsnoop to >> pcap format. >> >> Are there substantial differences (e.g., timing precision) between the >> various formats (usbmon, pcap/ng, usbsnoop)? Is there a preferred choice? >> >> > I am now trying to find how much different it is from the GL124, which >> is the closest support chip in genesys backend. >> >> No problems keeping the livestream going for at least another month or >> so. Also open to the idea of swapping out scanners if there are other >> development targets. >> >> + A write-up on remote development: >> http://gchriss.tumblr.com/post/53081576632/remote-development >> >> Sincerely, >> George >> >> >> > Regards, >> > Stef >> >> >> Hello, >> >> you need some more logs: >> - one at highest hardware CC resolution, full width, but with minimal >> height to keep data amount low >> - several scan of a small area at different dpi >> >> I'm trying to find if it is difficult to guess the usage of the >> registers, since I don't have the datasheet. >> >> Using the same version of wireshark you used is OK now my decoding >> scripts are modified. >> >> Regards, >> Stef >> > > > -- > sane-devel mailing list: sane-devel at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-request at lists.alioth.debian.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20140106/8fbfe27d/attachment.html>
[sane-devel] NET BJNP Canon imageCLASS MF4880DW
Hi, I have a Canon imageCLASS MF4880DW and sane-backend git has been updated and working fine via USB (lsusb: Bus 003 Device 004: ID 04a9:2773 Canon, Inc.) Thanks! I was trying to use it via the net but it didn't worked at first. I noted with wireshark that this printer is not using BJNP on port 8612 but instead MFNP on port 8610. As such MFNP looks similar to BJNP. I changed the sane-backend/backend/pixma_bjnp_private.h/BJNP_STRING to "MFNP" and recompiled (#define BJNP_STRING "MFNP") .After that I forced the port to 8610 in pixma.conf by adding bjnp://"ip address":8610 When using the default dpi of 75 (eg with xscanimage), it work and get a good scan (tried flatbed only at this time). But if I am increasing the dpi to the 150, 300, or 600, it don't work and I am getting a buch of logs as follow; [bjnp] bjnp_recv_header:ERROR, Received response has cmd code 80, expected 33 [bjnp] Could not read response to command! [bjnp] bjnp_recv_header:ERROR, Received response has cmd code 10, expected 33 [bjnp] Could not read response to command! [bjnp] bjnp_recv_header:ERROR, Received response has cmd code 4, expected 33 [bjnp] Could not read response to command! [bjnp] bjnp_recv_header:ERROR, Received response has cmd code 1, expected 33 [bjnp] Could not read response to command! [bjnp] bjnp_recv_header:ERROR, Received response has cmd code 0, expected 33 Any suggestion what I should do next? Thanks in advance
