[sane-devel] hp backend fails to detect HP SCSI scanner
Hello, I got a bug report from a user where his HP SCSI scanner was not found by default by the hp backend, see https://bugzilla.novell.com/show_bug.cgi?id=350688 in particular starting at https://bugzilla.novell.com/show_bug.cgi?id=350688#c8 It worked with openSUSE 10.2 but fails for openSUSE 10.3. Both 10.2 and 10.3 provide sane-backends version 1.0.18. I cannot reproduce it myself because I don't have the needed hardware so that I can only guess that the problem happens also for sane-backends 1.0.19. Since openSUSE 10.3 we use libata for IDE devices which makes IDE devices appear as generic SCSI devices. The user has a HP disk drive which gets /dev/sg2 and his HP C2520A 3503 ScanJet gets /dev/sg4. It seems the hp backend detects the HP disk drive and of course fails to access it as a SCSI scanner but then it seems the hp backend gives up to further scan the SCSI bus for the HP SCSI scanner. It helps when the user changes the default entry scsi HP in /etc/sane.d/hp.conf to a more specific entry scsi HP C2520A so that the hp backend detects only the SCSI scanner. The problem might not happen only with libata but also when there is another real HP SCSI device before the HP SCSI scanner. I am really no SCSI expert so that I don't know if the root cause of the problem is within the hp backend or if it is perhaps a general problem in the lower-level SANE SCSI functions. Perhaps it is possible to work around the problem with a better default entry in /etc/sane.d/hp.conf so that only HP SCSI scanners are detected or perhaps one might have by default a complete explicite list according to the SCSI models in man sane-hp like scsi HP C1130A scsi HP C1750A scsi HP C1790A scsi HP C2500A scsi HP C2520A scsi HP C2570A scsi HP C5100A scsi HP C5110A scsi HP C6270A scsi HP C7670A What do you think? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] hp backend fails to detect HP SCSI scanner
can you get the original poster to put it back to stock, and get a debug log like this: SANE_DEBUG_SANEI_SCSI=5 SANE_DEBUG_HP=128 scanimage -L allan On 3/27/08, Johannes Meixner jsmeix at suse.de wrote: Hello, I got a bug report from a user where his HP SCSI scanner was not found by default by the hp backend, see https://bugzilla.novell.com/show_bug.cgi?id=350688 in particular starting at https://bugzilla.novell.com/show_bug.cgi?id=350688#c8 It worked with openSUSE 10.2 but fails for openSUSE 10.3. Both 10.2 and 10.3 provide sane-backends version 1.0.18. I cannot reproduce it myself because I don't have the needed hardware so that I can only guess that the problem happens also for sane-backends 1.0.19. Since openSUSE 10.3 we use libata for IDE devices which makes IDE devices appear as generic SCSI devices. The user has a HP disk drive which gets /dev/sg2 and his HP C2520A 3503 ScanJet gets /dev/sg4. It seems the hp backend detects the HP disk drive and of course fails to access it as a SCSI scanner but then it seems the hp backend gives up to further scan the SCSI bus for the HP SCSI scanner. It helps when the user changes the default entry scsi HP in /etc/sane.d/hp.conf to a more specific entry scsi HP C2520A so that the hp backend detects only the SCSI scanner. The problem might not happen only with libata but also when there is another real HP SCSI device before the HP SCSI scanner. I am really no SCSI expert so that I don't know if the root cause of the problem is within the hp backend or if it is perhaps a general problem in the lower-level SANE SCSI functions. Perhaps it is possible to work around the problem with a better default entry in /etc/sane.d/hp.conf so that only HP SCSI scanners are detected or perhaps one might have by default a complete explicite list according to the SCSI models in man sane-hp like scsi HP C1130A scsi HP C1750A scsi HP C1790A scsi HP C2500A scsi HP C2520A scsi HP C2570A scsi HP C5100A scsi HP C5110A scsi HP C6270A scsi HP C7670A What do you think? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- 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
[sane-devel] hp backend fails to detect HP SCSI scanner
ok, i can confirm that this is a bug in sanei_scsi_find_devices(),
around line 2885:
if (lx_chk_devicename (number, dev_name, sizeof (dev_name), bus,
channel, id, lun)
((*attach) (dev_name) != SANE_STATUS_GOOD))
{
fclose (proc_fp);
return;
}
if the attach callback returns anything other than SANE_STATUS_GOOD,
then the function returns, instead of continuing on to look at
subsequent devices. instead, the fclose and return should be replaced
with a warning:
{
DBG(1,sanei_scsi_find_devices: bad attach\n);
}
this fixes the problem for me.
allan
--
The truth is an offense, but not a sin
[sane-devel] SANE2 standard completion
Hello, before any work can start on SANE 2, the current proposal has to be completed. The major change is the image data format. SANE 2 will be able to handle new formats easily (which matches the current needs, especially regarding ir channel). There will be 2 major image format, one pixel oriented and the other will give images as a mime attachment. There is also standard part for button handling. Here is a summary of the differences between SANE 1 and SANE 2 proposal standards: structures changes: - the SANE_Device struct has more fields, giving contact information about the devices in case of bug, and the ability to send device capability flags - the SANE_Parameters changes to suit the image format improvement. It also gives new informations such as a proposed filename and X/Y dpi. options changes: - capability hidden and allways settable added - more commonly used options are now part of the standard SANE operations changes: - sane_open has a SANE_Device ** parameter - scanner's button handling newtwork operation: The Network Protocol chapter seems to lag behind the SANE 1 chapter, and the SANE_NET_OPEN call needs to be updated to reflect sane_open evolution. The current proposal is in good shape, and the change regarding image format seems to suit the current need for new formats. Converting current backends to SANE2 doesn't seem that difficult. But before starting, there are some things I'd like to see in the new standard: - the current code flow is sane_init sane_open sane_start sane_read sane_cancel sane_close sane_exit rather than calling sane_cancel at the end of scan, I'd like to have a sane_end function. Leaving the use of sane_cancel for canceling the scan like it allready does. This new function would do about the same, but code flow would be cleaner and easier to understand: sane_init sane_open sane_start sane_read sane_end sane_close sane_exit - the proposed button handling would surely be better if we create sane_lock_buttons(), sane_update_buttons() and sane_unlock() buttons, instead of doing this with control options. - we should also add something about panels. Would some control options be enough, or do we also need some lock/update/unlock behavior ? - there are some issues about backends configuration. In order to be detected, some backends need their configuration files tweaked. I think that having well-known configuration options would improve the situation and would also let us have a common way of accessing configuration parameters across backends. - do we want to improve warmup handling ? Currently there is no feedback when warming-up is going on, which is sometime confusing, we can have the feeling that nothing is happening. Do we want a sane_warm_up() or a SANE_STATUS_WARMING_UP would be enough ? There are other points that I feel they could be improved, but could be done as we develop SANE2: - we need a sane type for scanner buttons. Either we rename the SANE_TYPE_BUTTON to SANE_TYPE_SOFT_BUTTON and use SANE_TYPE_BUTTON for physical buttons, or we create a SANE_TYPE_HARD_BUTTON. So that a frontend can easily detect hardware buttons. There should be a list of well-known buttons description to use when possible. - a SANE_TYPE_PANEL would be handy - since there are well-know options there should be well-known groups, and the SANE_CAP of these options should also be given. - a SANE_STATUS_LOCKED could be added to handle the case where the hardware lock of a scanner has been left. Regards, Stef
[sane-devel] Canon LiDE 90
Hello, Selon Pierre Willenbrock : Guillaume Gastebois schrieb: Hello, Yesterday I added CCD_CANONLIDE90 in genesys.c. I did two successive scans (result on http://ggastebois.free.fr/lide90_snoop/25_test1.zip). The first one gives a bright image (1_test1.txt), the second a dark image (3_test1.txt). Which log seeems to be the best for calibration ? (in 3_test1.txt, I see device I/O errors !!!) What are good values for offset_calibration: black/white pixels ? Another thing : Pierre, you send me few weeks ago a code named entropy2D.c. I compile it with : gcc -c entropy2D.c, gcc -lm -o entropy2D entropy2D.o. No errors. I call it with entropy2D ./offset1_1.pnm and it makes nothing and newer gives hand back !!! What did I wrong ??? (I want to test common nibbles). it accepts data on stdin, and outputs a pgm on stdout: ./entropy2D ./offset1_1.pnm histogram.pgm OK, works. Can you tell me what you think about attached image (entropy2D of offset1_1.pnm) ? For scanner locks up writing 0x41=0xf4, It signify that scanner things he's not hat home position. (home position : 0x41=0xfc). I thing it will be interessting to move a little bit head. How to do that ? My explanation is that on previous scan, the head has pressed home switch, but if head after that moves (less than a millimeter is enought) switch can no more be pressed. So moving back head may be usefull (but Isn't still made ?) To my knowledge, if the backend tests register 0x41, it thinks the scanning head should be moving, but it apparently is not. I didn't see something important : it only apears on scanner powerup. Locks up is away after pressing button 3 or 4 (not 1 ou 2 !). It's a power up issue. I did another ant work : comparing all regs from windows snoop to sane and I find these differences : addr |sane |windows|comments _|___|___|__ 09 |10 |21 |MCNTSET[1:0] CLKSET[1:0] BACKSCAN ENHANCE SHORTTG NWAIT 16 |20 |02 |CTRLHI TOSHIBA TGINV CK1INV CK2INV CTRLINV CKDIS CTRLDIS 19 |50 |ff |EXPDMY[7:0] 1a |00 |24 |X X MANUAL3 MANUAL1 CK4INV CK3INV LINECLP X 1d |02 |04 |CK4LOW CK3LOW CK1LOW TGSHLD[4:0] 52 |02 |02 |RHI[4:0] 53 |07 |04 |RLOW[4:0] 54 |00 |02 |GHI[4:0] 55 |00 |04 |GLOW[4:0] 56 |00 |02 |BHI[4:0] 57 |00 |04 |BLOW[4:0] 5d |00 |20 |HISPD[7:0] 5e |02 |41 |DECSEL[2:0] STOPTIM[4:0] 5f |00 |40 |FMOVDEC[7:0] 67 |00 |40 |STEPSEL[1:0] MTRPWM[5:0] 68 |00 |40 |FSTPSEL[1:0] FASTPWM[5:0] 69 |00 |08 |FSHDEC[7:0] 6a |00 |04 |FMOVNO[7:0] 70 |21 |05 |X X X RSH[4:0] 72 |00 |07 |X X X CPH[4:0] 73 |00 |09 |X X X CPL[4:0] 75 |00 |01 |CK1MAP[15:8] 76 |00 |ff |CK1MAP[7:0] 79 |00 |3f |CK3MAP[7:0] 7c |00 |1e |CK4MAP[7:0] 7d |00 |11 |CK1NEG CK3NEG CK4NEG RSNEG CPNEG BSMPNEG VSMPNEG DLYSET 7f |00 |50 |BSMPDLY[1:0] VSMPDLY[1:0] LEDCNT[3:0] 82 |00 |0f |ROFFSET[7:0] 84 |00 |0e |GOFFSET[7:0] 86 |00 |0d |BOFFSET[7:0] I think regs 09, 16, 19, 1a, 1d, 52, 53, 54, 55, 56, 57, 70, 72, 73, 75, 76, 79, 7c, 7d, 7f may be interessting, but I'll try to modify all. If i write 0x16=02, 0x1a=24 and 0x1d=04 : I get some bad image (gray with horizontal black lines). With others regs, no change. My next work will be analysing windows snoop for gpio transaction. gpio18 and gpio17 are always 1. 0x6d 0x6e and 0x6f have alwase same values (80 7f e0). Only 0x6c moves but I don't now how to know in windows snoop when (before/after calibration/scanning...) Regards Guillaume Regards Guillaume -- next part -- A non-text attachment was scrubbed... Name: test.pnm.tar.gz Type: application/x-gzip Size: 4650 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080327/55f581d1/attachment.bin
[sane-devel] hp backend fails to detect HP SCSI scanner
Allan,
thank's for investigating. Glad to hear that it is not a problem with
hp-backend and the hp.conf needs not to be changed.
Kind regards
Peter
m. allan noah schrieb:
ok, i can confirm that this is a bug in sanei_scsi_find_devices(),
around line 2885:
if (lx_chk_devicename (number, dev_name, sizeof (dev_name), bus,
channel, id, lun)
((*attach) (dev_name) != SANE_STATUS_GOOD))
{
fclose (proc_fp);
return;
}
if the attach callback returns anything other than SANE_STATUS_GOOD,
then the function returns, instead of continuing on to look at
subsequent devices. instead, the fclose and return should be replaced
with a warning:
{
DBG(1,sanei_scsi_find_devices: bad attach\n);
}
this fixes the problem for me.
allan
--
Peter Kirchgessner
http://www.kirchgessner.net
mailto:peter at kirchgessner.net
