[sane-devel] LiDE 90 half ccd

2008-04-20 Thread Guillaume Gastebois
Hello,

 Guillaume Gastebois schrieb:
 Hello,

 Me again !

 I'm trying to find what are GPIO14,13,12 and 11 for.

 I find GPIO11=home switch and must be 0.
 I thought I found GPIO14 was half CCD but by adding :
 /* gpio part. here: for canon lide 90 */
 if (dev-model-gpo_type == GPO_CANONLIDE90)
 {
 r = sanei_genesys_get_address (reg, 0x6c);
 if (half_ccd)
 r-value |= 0x20;
 else
 r-value = ~0x20;
 }

With code before and command scanimage, I get half sized image.
Scanimage gives me these parameters :
 pixels: 2574
 lines: 3531
 depth: 8
 channels: 1
 exposure_time: 5600
 xres: 300
 yres: 300
 half_ccd: yes
 stagger: 0
 max_shift: 0

Why is half ccd activated ?

I tryed with 0x1a=0x20 and it doesn't change anything. Doese it mean 
that clk3 is not used ?

 in genesys_gl841.c line ~2053 I had image compressed x2 in the left and
 second right part black with 0x6c=12 and not with 0x6c=1a. Strange.

 I decided to comment out these lines yet for tests.

 In genesys_841.c I see conditions with GPO_CANONLIDE35 for gl841_feed
 function (lines ~4309 and ~4913). I added GPO_CANONLIDE90 too. What is
 this function for ? Is it usefull to add lide 90 ?
 
 no, these don't help your scanner. the feed is used to position the 
 scanning head at the white calibration strip. This is(should not) be 
 needed for your scanner.
 

Regards
Guillaume



[sane-devel] Question on HP 6200C

2008-04-20 Thread Dieter Jurzitza
Dear listmembers,
today I got a new -well, say an used- HP Scanner 6200C. The configuration 
dialog tells me to use  the HP-backend, the scanner is detected. But then, in 
the very moment I try to scan something, the scanner moves somewhat and after 
a while scanimage times out with an error message:

scanimage: sane_read: Error during device I/O

Along with this mail I attached the logging output after setting both the 
debug variables to 127. The scanner has both an USB and a SCSI interface, 
they both behave identical, therefore I think it is not an issue with 
physics.
Thank you very much for looking into this,
take care



Dieter Jurzitza


Apologies for attaching the file as bzip2, but the original one has 1.2MByte 
and I didn't want to bother everybody on the list with such a huge file.


-- 
---

   |
\
 /\_/\   |
| ~x~ |/-\   /
 \   /-   \_/
  ^^__   _/  _     /
 ??__ \- \_/ |  |/|  |
  ||  || _| _|_| _|

if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
---
-- next part --
A non-text attachment was scrubbed...
Name: scan.bz2
Type: application/x-bzip2
Size: 8947 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080420/c1266fff/attachment.bin
 


[sane-devel] LiDE 90 half ccd

2008-04-20 Thread Pierre Willenbrock
Hi,

Guillaume Gastebois schrieb:
 Hello,
 
 Guillaume Gastebois schrieb:
 Hello,

 Me again !

 I'm trying to find what are GPIO14,13,12 and 11 for.

 I find GPIO11=home switch and must be 0.
 I thought I found GPIO14 was half CCD but by adding :
 /* gpio part. here: for canon lide 90 */
 if (dev-model-gpo_type == GPO_CANONLIDE90)
 {
 r = sanei_genesys_get_address (reg, 0x6c);
 if (half_ccd)
 r-value |= 0x20;
 else
 r-value = ~0x20;
 }

 With code before and command scanimage, I get half sized image.
 Scanimage gives me these parameters :
  pixels: 2574
  lines: 3531
  depth: 8
  channels: 1
  exposure_time: 5600
  xres: 300
  yres: 300
  half_ccd: yes
  stagger: 0
  max_shift: 0
 
 Why is half ccd activated ?

The parameters above represent what the backend tries to program. If you 
put a x-resolution below half of the optical resolution into scanimage, 
the backend determines it can use the faster scanning mode, i.E. half_ccd.

If you do not do anything to enable half_ccd-mode, you should get only 
half of the scanning area in x-direction for resolution below half 
optical resolution, and the full scanning area for resolutions above. Is 
it possible that your scanner is able to use not only a half-ccd-mode, 
but even a quarter-ccd-mode?

 I tryed with 0x1a=0x20 and it doesn't change anything. Doese it mean 
 that clk3 is not used ?

If you did that with ck3map and ck4map == 0, it would seem that clk3 and 
clk4 are unused. No idea why the windows driver sets these, then.

This is how i think your scanner works:

WM81xx  | | GL84x
OP[3:0] +-o-+ OP[3:0]
 |  |   .. |
 |  |   | 4-bit- | |
   MCLK  |  '--+ latch  ++ OP[7:4]
^---'  '---^' |
 |  '-+ which clock?
 '+ MCLK

The 4-bit-latch is the VHC175.

This WM81xx frontend sends its 16bit data in 4 bit nibbles, changing 
state on the falling and rising edges of MCLK, or, more exactly, up to 
20ns later(from the WM8152 datasheet, this seems to be long considering 
the time for one MCLK period is 41ns):

MCLK __---
OP[3:0]  ##
|41ns-|
   || less than 20ns
^   ^   sample here

therefore, it is probably safe to sample exactly on the edges. The 
WM8152 sets bits 7 to 4 when seeing a falling edge of MCLK, so the 4 bit 
latch can sample these on the next rising edge of MCLK. Then, it holds 
its output stable for the rest of the period. bits 3 to 0 are set when 
receiving a rising edge, so the GL84x should sample on the falling edge. 
The VHC175 samples on rising edges. This means, the clock used for the 
latch could be MCLK.

How does our problem with the high nibble of the second byte being 
similar to the low nibble of the first byte fit into this?

The 4 bit latch could be sampling at the same time as the WM81xx changes 
its outputs, this would lead to a mix of both informations. Maybe this 
does not happen for the first high nibble, because the WM81xx has 
slightly different timing for that case. This could be fixed by figuring 
out which clock the latch uses, and adjusting the rising/falling edges. 
When the latch does not get a clock, the gl84x should get the same 4 
bits over and over again(perhaps 0?) as high nibble, but usable low 
nibbles. (Similar can happen with the gl84x sampling at bad times, but i 
think the result would look different.)

Some random ideas:
It may be helpful if we could get the AFE to output an alternating bit 
pattern for each nibble. Lacking this possibility, reducing the gain and 
fiddling with the offset may be an option, too.

The above(including disabling clocks) will very probably lead to no 
usable image or working calibration. Instead, we need to examine the 
results of offset/coarse calibration. These two steps dump raw image data.

 in genesys_gl841.c line ~2053 I had image compressed x2 in the left and
 second right part black with 0x6c=12 and not with 0x6c=1a. Strange.

 I decided to comment out these lines yet for tests.

 In genesys_841.c I see conditions with GPO_CANONLIDE35 for gl841_feed
 function (lines ~4309 and ~4913). I added GPO_CANONLIDE90 too. What is
 this function for ? Is it usefull to add lide 90 ?
 no, these don't help your scanner. the feed is used to position the 
 scanning head at the white calibration strip. This is(should not) be 
 needed for your scanner.

 
 Regards
 Guillaume
 

Regards,
   Pierre



[sane-devel] Canon imageClass MFP's

2008-04-20 Thread Dennis Lou
Attached are diffs and code for the imageClass multi-functions.  As discussed, 
I created a separate pixma_imageclass.c as it seemed different enough to 
warrant that approach.  I've run all combinations of DPI and color along with 
several sizes and boundaries and everything seems to be working.

However, there are a couple issues.  First, xscanimage shows options for both 
ADF and ADF duplex when I've only specified PIXMA_CAP_ADF in the device table.  
Second, glibc complains of a double free on (pixma_t *) s-subdriver-buf in 
iclass_finish_scan() and hangs if I scan grayscale at 150DPI and only with this 
combination.  I've traced the code and inserted debug statements and verified 
that only 1 call to iclass_finish_scan() is occurring, so I'm pretty sure it is 
not happening in my code.

Also, I've only  an MF4270 so all the other devices listed in the Windows 
driver are completely untested.

-Dennis

- Original Message 
From: Nicolas nicolas.mar...@freesurf.fr
To: Dennis Lou dlou99 at yahoo.com
Cc: sane-devel at lists.alioth.debian.org
Sent: Thursday, April 17, 2008 2:31:44 PM
Subject: Re: [sane-devel] Canon imageClass MFP's

Yep, after having a look at the log file you sent, messages look very
similar to MP730 series ones, so it should be a good start point. 
What might be more uncertain is the ADF management, this is a bit weak
in the pixma backend. 
Depending on modifications you add, you need to figure out if it could
break code, or you could create, like in mp730_t structure, a
mp-generation variable which can ease to separate differences between
models.

Nicolas 


Le jeudi 17 avril 2008 ? 13:58 -0700, Dennis Lou a ?crit :
 I dug around some more and I think I've decoded most of the commands and 
 protocols.
   Of the 3 pixma subfamilies, it most closely resembles the mp730.c code.  
 Lamp/calibration/busy flags seem to be moved around a little but the 
 has-paper 
 flag seems the same (on a side note, I have yet to observe a cold lamp on 
 this machine)
  and the step1() sequence is slightly different.  I think I have enough info 
 to start 
 writing the backend at this point.
 
 I agree that a seperate pixma_imageclass.c is the easiest (don't have to 
 worry about
  breaking existing code) and it'd be easier for end-users to find the right 
 driver 
 and/or add devices.  Besides, if imageclass should be merged to an existing 
 file, so 
 should mp150/mp730/mp750.  However, it might be close enough that all I have 
 to do is 
 add the USB PID's to mp730.c and change a couple lines here and there.
 
 I will be sending snoop logs in a separate email shortly.
 
 -Dennis
 
 - Original Message 
 From: Nicolas nicolas.martin at freesurf.fr
 To: Dennis Lou dlou99 at yahoo.com
 Cc: sane-devel at lists.alioth.debian.org
 Sent: Thursday, April 17, 2008 1:12:09 PM
 Subject: Re: [sane-devel] Canon imageClass MFP's
 
 Hi,
 
 Currently maintaining the pixma backend, I can give you tips and
 knowledge on it if you want to design a backend for those Canon MFPs. 
 
 Especially if the protocol used by them is similar to the PIXMA
 protocol, then it can be easy to integrate them either in the pixma
 backend (the easiest, let's say as a separate pixma_ImageClass.c file
 for instance), or in a separate imageclass backend, that would probably
 use most of the pixma code.
 
 To have a first idea of what it looks like, could you send me (at mail
 address) a zipped USB snoop of a typical scan session under Windows
 
 Then, we can discuss on the best solution to implement the backend.
 
 Nicolas
 
 Le mercredi 16 avril 2008 ? 18:04 -0700, Dennis Lou a ?crit :
  Hi,
  
  I recently acquired a Canon imageClass MF4270 and am interested in 
  contributing a sane backend for it.  This is my progress so far:
  
  +Examined Windows driver package.  Found references to:
  --Canon MF5650
  --Canon MF5630
  --Canon MF3110
  --Canon MF8100
  --Canon MF5730
  --Canon MF5750
  --Canon MF5770
  --Canon MF6500 Series
  --Canon MF3200 Series
  --Canon MF4100 Series
  --Canon MF4600 Series
  --Canon MF4010 Series
  --Canon MF4200 Series
  
  +Ran sane-find-scanner -v -v
  +Ran cat /proc/bus/usb/devices
  +Created various logs using USB snooper in Windows
  +Isolated sections of log pertaining to connect, init, scan and de-init
  +Generated C code from logs and replayed USB commands in Linux
  +Reversed engineered some commands and responses
  +Modified C code to generate PNM/BMP files; performed scans from code
  
  
  
  Attached are output from sane-find-scanner and /proc/bus/usb/devices
  
  Looking at the logs, it seems very similar to the pixma MP series.
  
  Is anybody else working on this series?
  
  -Dennis
  
  
  
  

  
  Be a better friend, newshound, and 
  know-it-all with Yahoo! Mobile.  Try it now.  
  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[sane-devel] Canon imageClass MFP's

2008-04-20 Thread Nicolas
Hi Dennis,

Thanks for the work on the ImageClass backend, I've just browsed
the code and it looks close to mp730 one, but I think it's fine to
have ImageClass in a separate file, as it concerns a large number
devices.

I'll incorporate it in CVS soon, as I have currently under test, several
modifications for MP970.

Concerning the issues:

- Did you try also with Xsane ? I did not notice with Xsane the ADF and
ADF duplex issue (only ADF appears if duplex not declared), but I don't
use xscanimage. Could you test with Xsane and check if you have still
the ADF duplex issue ?

- Concerning the free issue, I just compared code with mp150 file, the
finish_scan () function does not contain free () statements, they are
included in the close () function. Maybe this is why the free () gets
executed twice.
I would suggest to do as in the mp150 finish scan () function, remove
the 2 lines in iclass_finish_scan:
 free (mf-buf);
 mf-buf = mf-lbuf = mf-imgbuf = NULL;
and let the close () function do the free statement. 
Could you test this ?

-For grayscale at 150 dpi, this is rather weird. Could it be related to
the free statements ?

Nicolas

Le samedi 19 avril 2008 ? 23:28 -0700, Dennis Lou a ?crit :
 Attached are diffs and code for the imageClass multi-functions.  
 As discussed, I created a separate pixma_imageclass.c as it seemed 
 different enough to warrant that approach.  I've run all combinations 
 of DPI and color along with several sizes and boundaries and everything 
 seems to be working.
 
 However, there are a couple issues.  First, xscanimage shows options for 
 both ADF and ADF duplex when I've only specified PIXMA_CAP_ADF in the device 
 table.  
 Second, glibc complains of a double free on (pixma_t *) s-subdriver-buf in 
 iclass_finish_scan() and hangs if I scan grayscale at 150DPI and only with 
 this 
 combination.  I've traced the code and inserted debug statements and verified 
 that only 1 call to iclass_finish_scan() is occurring, so I'm pretty sure it 
 is 
 not happening in my code.
 
 Also, I've only  an MF4270 so all the other devices listed in the Windows 
 driver are completely untested.
 
 -Dennis
 
 - Original Message 
 From: Nicolas nicolas.martin at freesurf.fr
 To: Dennis Lou dlou99 at yahoo.com
 Cc: sane-devel at lists.alioth.debian.org
 Sent: Thursday, April 17, 2008 2:31:44 PM
 Subject: Re: [sane-devel] Canon imageClass MFP's
 
 Yep, after having a look at the log file you sent, messages look very
 similar to MP730 series ones, so it should be a good start point. 
 What might be more uncertain is the ADF management, this is a bit weak
 in the pixma backend. 
 Depending on modifications you add, you need to figure out if it could
 break code, or you could create, like in mp730_t structure, a
 mp-generation variable which can ease to separate differences between
 models.
 
 Nicolas 
 
 
 Le jeudi 17 avril 2008 ? 13:58 -0700, Dennis Lou a ?crit :
  I dug around some more and I think I've decoded most of the commands and 
  protocols.
Of the 3 pixma subfamilies, it most closely resembles the mp730.c code.  
  Lamp/calibration/busy flags seem to be moved around a little but the 
  has-paper 
  flag seems the same (on a side note, I have yet to observe a cold lamp on 
  this machine)
   and the step1() sequence is slightly different.  I think I have enough 
  info to start 
  writing the backend at this point.
  
  I agree that a seperate pixma_imageclass.c is the easiest (don't have to 
  worry about
   breaking existing code) and it'd be easier for end-users to find the right 
  driver 
  and/or add devices.  Besides, if imageclass should be merged to an existing 
  file, so 
  should mp150/mp730/mp750.  However, it might be close enough that all I 
  have to do is 
  add the USB PID's to mp730.c and change a couple lines here and there.
  
  I will be sending snoop logs in a separate email shortly.
  
  -Dennis
  
  - Original Message 
  From: Nicolas nicolas.martin at freesurf.fr
  To: Dennis Lou dlou99 at yahoo.com
  Cc: sane-devel at lists.alioth.debian.org
  Sent: Thursday, April 17, 2008 1:12:09 PM
  Subject: Re: [sane-devel] Canon imageClass MFP's
  
  Hi,
  
  Currently maintaining the pixma backend, I can give you tips and
  knowledge on it if you want to design a backend for those Canon MFPs. 
  
  Especially if the protocol used by them is similar to the PIXMA
  protocol, then it can be easy to integrate them either in the pixma
  backend (the easiest, let's say as a separate pixma_ImageClass.c file
  for instance), or in a separate imageclass backend, that would probably
  use most of the pixma code.
  
  To have a first idea of what it looks like, could you send me (at mail
  address) a zipped USB snoop of a typical scan session under Windows
  
  Then, we can discuss on the best solution to implement the backend.
  
  Nicolas
  
  Le mercredi 16 avril 2008 ? 18:04 -0700, Dennis Lou a ?crit :
   Hi,
   
   I recently acquired a Canon imageClass 

[sane-devel] fujitsu fi-5120c fail on scan after cancel a job

2008-04-20 Thread m. allan noah
Well, it took me a month, but last night i released an updated fujitsu
driver into sane cvs. It contains, among other things, proper
cancelling support. I dont have many different models, so testing has
been somewhat limited. Feedback would be most welcome.

allan

On Wed, Mar 19, 2008 at 3:19 PM, m. allan noah kitno455 at gmail.com wrote:
 i am not surprised. i dont think i ever got canceling to work right.
  i'll take a look at it. BTW- how many scanners do you own :)

  allan



  On Wed, Mar 19, 2008 at 3:07 PM, tobias alarcon extobias at gmail.com 
 wrote:
   Hi all,
  
iam having a problem with this scanner.
Everthing goes fine on scanning, but when a try to scan
after calling sane_cancel() can't open the scanner
  
this is what debur say
  
[fujitsu] sane_start: start
[fujitsu] scanner_control: start
[fujitsu] do_usb_cmd: start
[fujitsu] do_usb_cmd: finish
[fujitsu] scanner_control: finish
[fujitsu] calculateDerivedValues: start
[fujitsu] xres=200, tlx=0, brx=10224, pw=10200, maxx=10624
[fujitsu] yres=200, tly=0, bry=13200, ph=13200, maxy=40800
[fujitsu] xres=200, tlx=0, brx=10224, pw=10200, maxx=10624
[fujitsu] yres=200, tly=0, bry=13200, ph=13200, maxy=40800
[fujitsu] calculateDerivedValues: finish
[fujitsu] setup_buffers: start
[fujitsu] setup_buffers: finish
[fujitsu] set_window: start
[fujitsu] do_usb_cmd: start
[fujitsu] do_usb_cmd: finish
[fujitsu] set_window: finish
[fujitsu] object_position: start
[fujitsu] do_usb_cmd: start
[fujitsu] do_usb_cmd: finish
[fujitsu] wait_scanner: start
[fujitsu] do_usb_cmd: start
[fujitsu] do_usb_cmd: finish
[fujitsu] wait_scanner: finish
[fujitsu] object_position: finish
[fujitsu] start_scan: start
[fujitsu] do_usb_cmd: start
[fujitsu] do_usb_cmd: start
[fujitsu] do_usb_cmd: finish
[fujitsu] sense_handler: start
[fujitsu] Sense=0x5, ASC=0x26, ASCQ=00, EOM=1, ILI=0, info=
[fujitsu] Illegal request: invalid field in parm list
[fujitsu] Offending byte is 00
[fujitsu] start_scan: finish
[fujitsu] sane_start: ERROR: cannot start_scan
[fujitsu] do_cancel: start
[fujitsu] do_cancel: finish
  
and return from sane_start with SANE_STATUS_INVAL
but i don't change anything from before scan parameters
  
thanks in advance
  
Tobias.
  
--
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
  



  --
  The truth is an offense, but not a sin




-- 
The truth is an offense, but not a sin



[sane-devel] hp7400c won't work with latest sane ?

2008-04-20 Thread Tymoteusz
Tymoteusz pisze:
 Ren? Rebe pisze:
 Tymoteusz wrote:
 Ren? Rebe pisze:
 Hi,

 Tymoteusz wrote:
 Ren? Rebe pisze:
 Tymoteusz wrote:
 Rene Rebe pisze:
 Hi,

 On 04.04.2008, at 01:05, Tymoteusz wrote:

 m. allan noah pisze:
 On 4/3/08, Tymoteusz tymoteusz.drozd at gmail.com wrote:

 Yeah, just that X segfaulted, does not tell much.


 However, you could test with scanimage in a xterm (or 
 variant) or even
 the console text terminal to check your basic image processing
 functionality ...

 Yours,

 -- 
  Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | 
 http://rene.rebe.name

 Well scanimage doesn't  crashing xorg. In this moment i've 
 compiled old
 sane-backends 1.0.18
 and my scaner had return to previous state, it's working for 
 now, but i
 think that this situation is  not so fine. Is  there  anyway 
 to solve
 this problem ?

 yes- get a debug log like i asked for previously

 allan

 when i catch some more time i will try to investigate a

 bit more this issue.

 Regards


 -- 
 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




 oups sorry i had forgotten to add ur email adres to my 
 previous post
 log is here http://atelier1.website.pl/N-A
 It is just inf. waiting for light warmup. I just yesterday 
 found a similar
 problem with a newer hardware and will provide a workaround 
 when done.

 Can you test if you can scan successfully if you let the 
 scanner warm
 it's light before you scan with the Avision SANE backend?

 Yours,

 Well i have left scanner for warmup but this didn't give any 
 difference.
 Regards.

 Where is the log to take a look?

 Btw. I just noticed in the source I have on the screen the 7400
 is marked as AV_LIGHT_CHECK_BOGUS, which essentially ignores the
 light warmup state in the code. Can you review if your backend
 source you installed from contains this?

 Yours,

 Hmm

 AV_LIGHT_CHECK_BOGUS appears in:

 /backend/
767:avision.c
2477:avision.c
107:avision.h


 log is here http://atelier1.website.pl/N-A
 7400_old.log is previous log
 7400.log is new one.

 also i'm sure that something had triggered lamp warmup because 
 after 40min scanner was very hot (much warmer then after 30 scan's 
 committed with old version of avison).

 So, still waiting for the light. Can you add a return 
 SANE_STATUS_GOODM;
 in the beginning of your wait_4_light() function in avision.c?

 If I find some time I'll send you some workaround for testing, as
 maybe the silicon would report a correct status if polled less often.

 If you have free time you could also test upfront if changing the
 sleep(1) that should be in your function to sleep(10) or sleep(20)
 fixes light detection for your scanner.

 Yours,

 hmm i need some more info becuse i had

 avision.c: In function 'wait_4_light':
 avision.c:2439: error: 'SANE_STATUS_GOODM' undeclared (first use in 
 this function)


 i had puted this here:

 wait_4_light (Avision_Scanner* s)
 {
  return SANE_STATUS_GOODM; 
  Avision_Device* dev = s-hw;

  /* read stuff */
  struct command_read rcmd;


 Regards

 Sorry, the trailing M was a typo from my side. SANE_STATUS_GOOD
 (taking a 2nd look) it should be.

 Depending on your compiler you might have to move the return after
 the variable declarations ...

 Yours,

 Well thats gives difference.
 Scanner have moved his head and started initialization.
 But then stoped.
 new log (7400_1.log) is here http://atelier1.website.pl/N-A

 Regards


Hello after while. I would like to ask about this problem, did there is 
available any fix for this yet ?

Regards



[sane-devel] Sane Backends 1.0.19 breaks Microtek Scanmaker 4800

2008-04-20 Thread Subscriptions
I have a dual boot system with both Gentoo  FreeBSD. When sane-backends
got upgraded on both, sane stopped working. It seems to be a permissions
error. Here are the results on FreeBSD, they are identical on linux:

root at beastie ~ # sane-find-scanner -q
found USB scanner (vendor=0x05da, product=0x30cf) at
libusb:/dev/usb0:/dev/ugen0

root at beastie ~ # scanimage -L
device `sm3840:libusb:/dev/usb0:/dev/ugen0' is a Microtek ScanMaker 4800
flatbed scanner

root at beastie ~ # ls -la /dev/ugen0
crw-rw 1 root operator 0, 83 Mar 7 21:22 /dev/ugen0


root at beastie ~ # scanimage --format tiff  test.tiff
scanimage: open of device sm3840:libusb:/dev/usb0:/dev/ugen0 failed:
Access to resource has been denied

Now when I force a downgrade to 1.0.18 everything works as intended.
Since I experience this on both FreeBSD and Linux I would have to assume
that it is a bug in the new version of the backend.




[sane-devel] Canon imageClass MFP's

2008-04-20 Thread Dennis Lou
 is similar to the PIXMA
  protocol, then it can be easy to integrate them either in the pixma
  backend (the easiest, let's say as a separate pixma_ImageClass.c file
  for instance), or in a separate imageclass backend, that would probably
  use most of the pixma code.
  
  To have a first idea of what it looks like, could you send me (at mail
  address) a zipped USB snoop of a typical scan session under Windows
  
  Then, we can discuss on the best solution to implement the backend.
  
  Nicolas
  
  Le mercredi 16 avril 2008 ? 18:04 -0700, Dennis Lou a ?crit :
   Hi,
   
   I recently acquired a Canon imageClass MF4270 and am interested in 
   contributing a sane backend for it.  This is my progress so far:
   
   +Examined Windows driver package.  Found references to:
   --Canon MF5650
   --Canon MF5630
   --Canon MF3110
   --Canon MF8100
   --Canon MF5730
   --Canon MF5750
   --Canon MF5770
   --Canon MF6500 Series
   --Canon MF3200 Series
   --Canon MF4100 Series
   --Canon MF4600 Series
   --Canon MF4010 Series
   --Canon MF4200 Series
   
   +Ran sane-find-scanner -v -v
   +Ran cat /proc/bus/usb/devices
   +Created various logs using USB snooper in Windows
   +Isolated sections of log pertaining to connect, init, scan and de-init
   +Generated C code from logs and replayed USB commands in Linux
   +Reversed engineered some commands and responses
   +Modified C code to generate PNM/BMP files; performed scans from code
   
   
   
   Attached are output from sane-find-scanner and /proc/bus/usb/devices
   
   Looking at the logs, it seems very similar to the pixma MP series.
   
   Is anybody else working on this series?
   
   -Dennis
   
   
   
   
 
   
   Be a better friend, newshound, and 
   know-it-all with Yahoo! Mobile.  Try it now.  
   http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
  
  
  
  
  
  

  
  Be a better friend, newshound, and 
  know-it-all with Yahoo! Mobile.  Try it now.  
  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
 
 
   
 
 Be a better friend, newshound, and 
 know-it-all with Yahoo! Mobile.  Try it now.  
 http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-- next part --
A non-text attachment was scrubbed...
Name: pixma_imageclass.c.gz
Type: application/gzip
Size: 4999 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080420/7d3a4a69/attachment.bin
 


[sane-devel] Registered user allan-guest HP scanner interface troubles.

2008-04-20 Thread Allan Topp
I really (that is REALLY) want to get off my Windows PC and use Linux 
exclusively.

My last obstacle is scanning.

I am using ubuntu 6.06, Xsane 0.97 and an HP 4470C scanner.

Despite the scanner not being listed as supported it works just fine.  
Except it will only scan 300 dpi gray scale.  The pull downs for both 
are not there.

Does anyone have a work around for this?  Or ...?

TIA

Allan





[sane-devel] sane-epkowa backend for EPSON V500

2008-04-20 Thread n...@wideopenwest.com
As requested in the man page I'm reporting status.

The current backend (EPKOWA SANE Backend 2.11.0 - 2008-02-07) which can 
be downloaded from AVASYS 
(http://avasys.jp/hp/menu00500/hpg00442.htm) does *not* enable 
successful scanning for the EPSON V500 under Debian etch with kernel 
2.6.24.4. I have attempted installation both via alien and by building 
from source. In both cases installation was successful but the software 
fails at runtime. The os, 'lsusb', and 'sane-find-scanner' all correctly 
detect the V500. However, 'scanimage' and 'iscan' fail. With debugging 
enabled iscan fails as follows:

---
iscan
[sanei_debug] Setting debug level of epkowa to 128.
[epkowa] sane_init: iscan 2.11.0
[sanei_debug] Setting debug level of sanei_usb to 128.
[sanei_usb] sanei_usb_init: HAVE_LIBUSB
[sanei_usb] sanei_usb_init: can't stat /dev/usb/: No such file or directory
usb_set_debug: Setting debugging level to 255 (on)
usb_os_find_busses: Found 005
usb_os_find_busses: Found 004
usb_os_find_busses: Found 003
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_busses: Skipping non bus directory devices
usb_os_find_devices: Found 001 on 005
usb_os_find_devices: Found 001 on 004
usb_os_find_devices: Found 001 on 003
usb_os_find_devices: Found 001 on 002
usb_os_find_devices: Found 003 on 001
usb_os_find_devices: Found 002 on 001
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
[sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub
[sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub
[sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub
[sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub
[sanei_usb] sanei_usb_init: found libusb device (0x04b8/0x0130) 
interface 0  at libusb:001:003
[sanei_usb] sanei_usb_init: device 0x1058/0x0903, interface 0 doesn't 
look like a scanner (0/8)
[sanei_usb] sanei_usb_init: device 0x1058/0x0903, interface 1 doesn't 
look like a scanner (0/3)
[sanei_usb] sanei_usb_init: device 0x1058/0x0903: no suitable interfaces
[sanei_usb] sanei_usb_init: device 0x/0x looks like a root hub
[sanei_usb] sanei_usb_init: found 1 devices
[epkowa] sane_init, # epkowa.conf -- sample configuration for the 
EPKOWA SANE backend
[epkowa] sane_init, # Copyright (C) 2004  Olaf Meeuwissen
[epkowa] sane_init, #
[epkowa] sane_init, # See sane-epkowa(5), sane-scsi(5) and sane-usb(5) 
for details.
[epkowa] sane_init, 
[epkowa] sane_init, # SCSI scanners can be configured simply by listing 
the path to the
[epkowa] sane_init, # device.  For example, if your system claims to 
have a /dev/scanner
[epkowa] sane_init, # SCSI device, all you have to do is uncomment the 
following line:
[epkowa] sane_init, #
[epkowa] sane_init, #/dev/scanner
[epkowa] sane_init, #
[epkowa] sane_init, # In the interest of maintainability, most 
installations would have
[epkowa] sane_init, # /dev/scanner sym-linked to the real SCSI scanner 
device node.
[epkowa] sane_init, #
[epkowa] sane_init, # An alternative way that works for many operating 
systems and is a
[epkowa] sane_init, # little bit more generic, is to have the backend 
probe for your SCSI
[epkowa] sane_init, # scanner with the following configuration command:
[epkowa] sane_init, #
[epkowa] sane_init, #scsi EPSON
[epkowa] sane_init, 
[epkowa] sane_init, # On systems with libusb, the following line is 
sufficient to get the
[epkowa] sane_init, # backend to recognise your USB scanners.  It 
presumes, however, that
[epkowa] sane_init, # the scanner---more precisely, it's USB product 
ID---is known to the
[epkowa] sane_init, # backend.
[epkowa] sane_init, # For all USB scanners that are officially 
supported by this backend,
[epkowa] sane_init, # this presumption is true.  A list of such 
scanners can be found in
[epkowa] sane_init, # sane-epkowa(5).
[epkowa] sane_init, #
[epkowa] sane_init, #usb
[epkowa] sane_init, 
[epkowa] sane_init, # For any USB scanner not known to the backend 
(yet), you may, at your
[epkowa] sane_init, # own peril(!!), force the backend to recognise and 
use it via libusb.
[epkowa] sane_init, # You can do so by the following configuration 
command:
[epkowa] sane_init, #
[epkowa] sane_init, #   usb USB vendor ID USB product ID
[epkowa] sane_init, #
[epkowa] sane_init, # SEIKO EPSON's USB vendor ID is '0x04b8' (without 
quotes).  In order
[epkowa] sane_init, # to find the USB product ID, use lsusb(1) or, on 
Linux systems, peek
[epkowa] sane_init, # at the information in /proc/bus/usb/devices.
[epkowa] sane_init, # A sample configuration for the Perfection 1650 
(GT-8200), which has
[epkowa] sane_init, # a product ID of 0x0110, would look as follows:
[epkowa] sane_init, #

[sane-devel] Registered user allan-guest HP scanner interface troubles.

2008-04-20 Thread m. allan noah
oops- forgot to include sane-devel on this reply...

On Sun, Apr 20, 2008 at 8:49 PM, m. allan noah kitno455 at gmail.com wrote:
 your distro must include the hp_rts88xx backend with sane, as that is
  listed as only supporting 300dpi Gray on that scanner. recently, the
  new rts8891 backend was added to sane, and it is listed as supporting
  more features of that machine. you need to upgrade to a recent sane
  cvs snapshot, either from source, or perhaps your OS vendor has some
  testing package you can use.

  allan



  On Sun, Apr 20, 2008 at 4:34 PM, Allan Topp atopp at ncf.ca wrote:
   I really (that is REALLY) want to get off my Windows PC and use Linux
exclusively.
  
My last obstacle is scanning.
  
I am using ubuntu 6.06, Xsane 0.97 and an HP 4470C scanner.
  
Despite the scanner not being listed as supported it works just fine.
Except it will only scan 300 dpi gray scale.  The pull downs for both
are not there.
  
Does anyone have a work around for this?  Or ...?
  
TIA
  
Allan
  
  
  
--
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
  



  --
  The truth is an offense, but not a sin




-- 
The truth is an offense, but not a sin



[sane-devel] Canon imageClass MFP's

2008-04-20 Thread Dennis Lou
Regarding the ADF duplex issue, this line looks suspect:

Index: pixma.c
===
RCS file: /cvsroot/sane/sane-backends/backend/pixma.c,v
retrieving revision 1.11
diff -a -u -r1.11 pixma.c
--- pixma.c 2 Apr 2008 20:13:48 -   1.11
+++ pixma.c 21 Apr 2008 00:53:47 -
@@ -641,7 +641,7 @@
   i++;
 }
 #if 1
-  if (cfg-cap  PIXMA_CAP_ADFDUP)
+  if ((cfg-cap  PIXMA_CAP_ADFDUP) == PIXMA_CAP_ADFDUP)
 {
   ss-source_list[i] = SANE_I18N (ADF Duplex);
   ss-source_map[i] = PIXMA_SOURCE_ADFDUP;



-Dennis


- Original Message 
From: Nicolas nicolas.mar...@freesurf.fr
To: Dennis Lou dlou99 at yahoo.com
Cc: sane-devel sane-devel at lists.alioth.debian.org
Sent: Sunday, April 20, 2008 2:37:45 AM
Subject: Re: [sane-devel] Canon imageClass MFP's

Hi Dennis,

Thanks for the work on the ImageClass backend, I've just browsed
the code and it looks close to mp730 one, but I think it's fine to
have ImageClass in a separate file, as it concerns a large number
devices.

I'll incorporate it in CVS soon, as I have currently under test, several
modifications for MP970.

Concerning the issues:

- Did you try also with Xsane ? I did not notice with Xsane the ADF and
ADF duplex issue (only ADF appears if duplex not declared), but I don't
use xscanimage. Could you test with Xsane and check if you have still
the ADF duplex issue ?

- Concerning the free issue, I just compared code with mp150 file, the
finish_scan () function does not contain free () statements, they are
included in the close () function. Maybe this is why the free () gets
executed twice.
I would suggest to do as in the mp150 finish scan () function, remove
the 2 lines in iclass_finish_scan:
 free (mf-buf);
 mf-buf = mf-lbuf = mf-imgbuf = NULL;
and let the close () function do the free statement. 
Could you test this ?

-For grayscale at 150 dpi, this is rather weird. Could it be related to
the free statements ?

Nicolas

Le samedi 19 avril 2008 ? 23:28 -0700, Dennis Lou a ?crit :
 Attached are diffs and code for the imageClass multi-functions.  
 As discussed, I created a separate pixma_imageclass.c as it seemed 
 different enough to warrant that approach.  I've run all combinations 
 of DPI and color along with several sizes and boundaries and everything 
 seems to be working.
 
 However, there are a couple issues.  First, xscanimage shows options for 
 both ADF and ADF duplex when I've only specified PIXMA_CAP_ADF in the device 
 table.  
 Second, glibc complains of a double free on (pixma_t *) s-subdriver-buf in 
 iclass_finish_scan() and hangs if I scan grayscale at 150DPI and only with 
 this 
 combination.  I've traced the code and inserted debug statements and verified 
 that only 1 call to iclass_finish_scan() is occurring, so I'm pretty sure it 
 is 
 not happening in my code.
 
 Also, I've only  an MF4270 so all the other devices listed in the Windows 
 driver are completely untested.
 
 -Dennis
 
 - Original Message 
 From: Nicolas nicolas.martin at freesurf.fr
 To: Dennis Lou dlou99 at yahoo.com
 Cc: sane-devel at lists.alioth.debian.org
 Sent: Thursday, April 17, 2008 2:31:44 PM
 Subject: Re: [sane-devel] Canon imageClass MFP's
 
 Yep, after having a look at the log file you sent, messages look very
 similar to MP730 series ones, so it should be a good start point. 
 What might be more uncertain is the ADF management, this is a bit weak
 in the pixma backend. 
 Depending on modifications you add, you need to figure out if it could
 break code, or you could create, like in mp730_t structure, a
 mp-generation variable which can ease to separate differences between
 models.
 
 Nicolas 
 
 
 Le jeudi 17 avril 2008 ? 13:58 -0700, Dennis Lou a ?crit :
  I dug around some more and I think I've decoded most of the commands and 
  protocols.
Of the 3 pixma subfamilies, it most closely resembles the mp730.c code.  
  Lamp/calibration/busy flags seem to be moved around a little but the 
  has-paper 
  flag seems the same (on a side note, I have yet to observe a cold lamp on 
  this machine)
   and the step1() sequence is slightly different.  I think I have enough 
  info to start 
  writing the backend at this point.
  
  I agree that a seperate pixma_imageclass.c is the easiest (don't have to 
  worry about
   breaking existing code) and it'd be easier for end-users to find the right 
  driver 
  and/or add devices.  Besides, if imageclass should be merged to an existing 
  file, so 
  should mp150/mp730/mp750.  However, it might be close enough that all I 
  have to do is 
  add the USB PID's to mp730.c and change a couple lines here and there.
  
  I will be sending snoop logs in a separate email shortly.
  
  -Dennis
  
  - Original Message 
  From: Nicolas nicolas.martin at freesurf.fr
  To: Dennis Lou dlou99 at yahoo.com
  Cc: sane-devel at lists.alioth.debian.org
  Sent: Thursday, April 17, 2008 1:12:09 PM
  Subject: Re: