[sane-devel] XSane not showing full list of resolutions for Epson V500
Brett cda-kfmg at kaspop.com writes: On Mon, Jul 07, 2008 at 09:18:57AM +0900, Olaf Meeuwissen wrote: The advanced options show a full range of dpi for X but setting this has no effect. What option would that be? The epkowa backend doesn't do resolution ranges for this model, only lists. Or do you mean a full list? Sorry, I mean a full list. The option is Scan ModeX-resolution[dpi] It shows a list of values going up to 6400. That looks correct. Any suggestions would be most welcome. Create debugging output with both iscan and xsane and compare. You can also send me the debugging output (via this list) for xsane so I can take a look. If you do, please also provide information on your distribution and xsane and iscan versions used. I don't use a distribution - I have a Linux from Scratch system (gcc-4.2, binutils-2.8, glibc-2.7) xsane version: 0.995 iscan version: 2.11.0 OK, so you're probably comfortable with building stuff from source. You probably just want to start the application(s) and maybe change the document source (flatbed to ADF for example) or expose that advanced option you mention. You do not need to scan anything. Have done this and attached the zipped debug log. Hope you're able to help. Thanks for your time. There's nothing wrong in the logs. The bug is caused by an infelicity in the saneopts.h header file. The SANE_NAME_SCAN_RESOLUTION and SANE_NAME_SCAN_X_RESOLUTION are exactly the same. With Image Scan! I redefine the latter to x-resolution so things work as expected. If you really need xsane, you can fix this by recompiling with a fixed saneopts.h and I guess I should get that file fixed upstream ;-) Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] [BUG] Duplicate SANE_NAME in saneopts.h
Checking out why setting X/Y resolutions independently didn't quite work as expected, I discovered that saneopts.h has this: #define SANE_NAME_SCAN_RESOLUTION resolution #define SANE_NAME_SCAN_X_RESOLUTION resolution #define SANE_NAME_SCAN_Y_RESOLUTION y-resolution That means that trying to set the X resolution always does the same thing as setting the scan resolution. I think that is incorrect in the general case and suggest the above gets changed to: #define SANE_NAME_SCAN_RESOLUTION resolution #define SANE_NAME_SCAN_X_RESOLUTION x-resolution #define SANE_NAME_SCAN_Y_RESOLUTION y-resolution So that backend implementations can distinguish these cases if they want to. The corresponding descriptions for these option hint that setting the image's scan resolution is not necessarily the same as setting the horizontal scan resolution. In my particular situation, I have a use case where it makes sense to use SANE_NAME_SCAN_RESOLUTION with one set of allowed resolutions and different sets of allowed resolutions for the individual horizontal and vertical resolution settings. On a more general note, there is no point in having different option name macros that resolve to the same name. All of the SANE_NAME_* macros should be unique. At the moment (sane-backends-1.0.19), only SANE_NAME_SCAN_X_RESOLUTION is not unique. I don't think that the suggested change will break any of the current backends and frontends, but would like to ask everyone to take a look and comment on my suggestion before I file a bug report. Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] SANE 1.1.0 Release discussion
Le Tuesday 08 July 2008 21:42:09 K?re S?rs, vous avez ?crit?:
Hi,
On Mondayen den 7 July 2008 23:51:24 m. allan noah wrote:
ok guys- take 4:
Six general points for sane 1.1.x:
- no changes to function calls
- no changes to structures
- 1.0 backends forward compatible with 1.1
- improve backend consistency
- support more advanced scanners
- improve cooperation with modern system services
Specific proposals:
1. Consistent, translatable option groups:
'Standard' = source, mode, resolution
'Geometry' = x/y and paper size params
'Enhancement' = bright/gamma/contrast/thresh, rif, halftone, etc
'Advanced' = compression, calibration, feed controls, etc
'Sensors' = an option for every hardware button or sensor
2. Two new well-known options for ADF paper alignment: page-width and
page-height
3. Two new SANE_STATUS values: HW_LOCKED and WARMING_UP
4. Nine new SANE_FRAME values: TEXT, JPEG, G31D, G32D, G42D, IR, RGBI,
GRAYI, and XML
5. Several new well-known options for buttons and sensors. Backends
should use the closest one to the meaning of the label on the scanner
or the button's use in the manufacturer's software. Backends may also
use a different name if no suitable one is found.
well-known buttons:
scan, email, fax, copy, pdf, cancel
well-known sensors:
page-loaded, cover-open
6. Clarify standard text for SANE_CAP_HARD_SELECT to indicate it
should be used for polling the current state of hardware sensors and
buttons, with a refresh interval = 1 sec.
I haven't seen a discussion about adding an optional calback mechanism for
this (I might have missed it). Would it be feasible? I always try to avoid
polling if possible.
If it is not easy/fast to implement, it is no biggie for me :)
7. New DBGBM macro for bitmask debugging output (bit # listed below):
1 DBG_LVL_ERROR (errors only)
2 DBG_LVL_FUNC (function tracing 'enter xxx()' or 'exit xxx()')
3 DBG_LVL_DETAIL ('trying action X' or 'action succeeded' etc)
4 DBG_LVL_OPTION (any sane_option parsing code)
5 DBG_LVL_CALIB (calibration info)
6 DBG_LVL_IMAGE (dump image data read from scanner)
7 DBG_LVL_DATA (dump data packets read from scanner, other than
image or cal?)
8 DBG_LVL_FILE (write internal data files to disk from within
backend?)
8. Add common configuration reading function in sanei_* so that new or
maintained backends can benefit from it. Wholesale config file
restructuring?
9. Require backends to always accept the sanei device name as an
alternative to the backend generated name.
Most of this stuff is done or in progress, except I have not used tex
in years, so it's going to take me a little while to update the
standard, unless someone else steps up. And #7 needs some programmer
cycles- volunteers? If we can get those (and stef's sanei_config
improvements) into cvs, then we can take a look for backends that
might need updates, particularly on #9.
allan
--
The truth is an offense, but not a sin
Is anybody updating the test backend with the new features? I needed to add
a gamma table stub to the test backend to be able to implement gammatable
support in libksane.
--
K?re S?rs
Hello,
the test backend had been updated some time ago, and provides a
pnm:locked
and pnm:warmup backends that let one test for the new status that may be
returned by a backend.
I have an experimental version of libkscan that supports the new
SANE_STATUS_WARMING_UP by adding the lines after sane_start() in
acquire_data:
#ifndef SANE_CAP_ALWAYS_SETTABLE /* should better be done by detecting SANE's
version in configure and providing a
HAS_SANE_1_1 */
/* warming-up handling */
if( sane_stat == SANE_STATUS_WARMING_UP )
{
do
{
/* TODO some progress/ waiting dialog */
/* re-read to check if warming up is done */
sane_stat = sane_start( scanner_handle );
}
while (sane_stat == SANE_STATUS_WARMING_UP);
}
#endif
Regards,
Stef
[sane-devel] Fwd: Re: HP G2410 scanner
Oops, I hit the wrong button, should have reply to the list ... -- next part -- An embedded message was scrubbed... From: stef stef@free.fr Subject: Re: [sane-devel] HP G2410 scanner Date: Wed, 9 Jul 2008 06:36:12 +0200 Size: 3058 Url: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080709/1a45c696/attachment.eml
[sane-devel] SANE 1.1.0 Release discussion
On Wednesday 09 July 2008, m. allan noah wrote: Is anybody updating the test backend with the new features? I needed to add a gamma table stub to the test backend to be able to implement gammatable support in libksane. i dont recall seeing a patch from you for the gamma table support- did i miss it? http://lists.alioth.debian.org/pipermail/sane-devel/2007-September/019851.html :) -- K?re S?rs
[sane-devel] [BUG] Duplicate SANE_NAME in saneopts.h
m. allan noah kitno455 at gmail.com writes: On 7/8/08, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Checking out why setting X/Y resolutions independently didn't quite work as expected, I discovered that saneopts.h has this: #define SANE_NAME_SCAN_RESOLUTION resolution #define SANE_NAME_SCAN_X_RESOLUTION resolution #define SANE_NAME_SCAN_Y_RESOLUTION y-resolution That means that trying to set the X resolution always does the same thing as setting the scan resolution. I think that is incorrect in the general case and suggest the above gets changed to: #define SANE_NAME_SCAN_RESOLUTION resolution #define SANE_NAME_SCAN_X_RESOLUTION x-resolution #define SANE_NAME_SCAN_Y_RESOLUTION y-resolution So that backend implementations can distinguish these cases if they want to. The corresponding descriptions for these option hint that setting the image's scan resolution is not necessarily the same as setting the horizontal scan resolution. In my particular situation, I have a use case where it makes sense to use SANE_NAME_SCAN_RESOLUTION with one set of allowed resolutions and different sets of allowed resolutions for the individual horizontal and vertical resolution settings. On a more general note, there is no point in having different option name macros that resolve to the same name. All of the SANE_NAME_* macros should be unique. At the moment (sane-backends-1.0.19), only SANE_NAME_SCAN_X_RESOLUTION is not unique. I don't think that the suggested change will break any of the current backends and frontends, but would like to ask everyone to take a look and comment on my suggestion before I file a bug report. i agree with your assessment, but i am not sure i can envision a use case with all three controls active at the same time. or, are you going to have a locked/unlocked choice that switches between the two sets? Not sure I can either, at least not for a sensible use case. But then again, sometimes there are rather senseless use cases. In my particular case, I can query a number of devices for supported resolutions in two ways. One way gives a list of resolutions. These would correspond to the SANE_NAME_SCAN_RESOLUTION scenario, that is, horizontal and vertical resolutions are (and should be) identical. The other way gives a list with resolutions for both horizontal and vertical directions, corresponding to the SANE_NAME_SCAN_?_RESOLUTION scenario, where both resolutions can be selected independently. Fact is that all three list may contain values that are on neither of the other two lists. So I could end up with these (hypothetical) resolution lists SCAN_RESOLUTION : 100, 200, 300 SCAN_X_RESOLUTION: 80, 150, 360 SCAN_Y_RESOLUTION: 120, 240, 480 and the following set of valid resolution settings: (100,100) (200,200) (300,300) ( 80,120), ( 80,240), ( 80,480) (150,120), (150,240), (150,480) (360,120), (360,240), (360,480) There is no way that I can merge the SCAN_RESOLUTION with the other two options (or the other way) around that restricts a frontend to these resolution sets. # Yes, I'm aware backends may set a value other than that requested # and I have seen the SANE_NAME_RESOLUTION_BIND option. Whatever the sensibility of my particular use case, having two macros expand to the same string for options that correspond to *different* things is not a good idea. Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
[sane-devel] Re : Re: GL842
Hello, On Thu, Jul 03, 2008 at 02:52:22PM -0700, Donald Endres wrote: I got the attachment from http://lists.alioth.debian.org/pipermail/sane-devel/2008-March/021440.html ( is that the newest version ? ) and I will try to reproduce your work. Same for me. :-) A general question: Where is the code for canon-lide-90? Is it already completely in the CVS? Despite some problems, the code developed by Guillaume and Pierre is the best we current have. It would be a pity if that code got lost in the mailing list archive. I think it is not in CVS yet. I'll try to send new patch (to be added in CVS ?) despite no huge progress since month. (just fix first scan power up problem) More general: When are such contributions usually added to the CVS? Good question. Greets, Volker -- Volker Grabsch ---(())--- Administrator NotJustHosting GbR Regards Guillaume
[sane-devel] Epson cx3700 not recognized after upgrade to 1.0.19 (repost)
I didn't receive any replies to this, so I will try again. Everything worked absolutely flawlessly under 1.0.18. After the upgrade, which according to the ChangeLog added this device (usb 0x4b8 0x818) to backend/epson_usb.c (which I thought would make everything work better), I can't get scanimage (or any other program for that matter) to see the device (even though sane-find-scanner does). If I downgrade back to 1.0.18, then everything works again. I don't know what you need to diagnose this, but let me start with: # sane-find-scanner # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. # Also you need support for SCSI Generic (sg) in your operating system. # If using Linux, try modprobe sg. found USB scanner (vendor=0x04b8 [EPSON], product=0x0818 [USB MFP]) at libusb:004:012 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. # Not checking for parallel port scanners. # Most Scanners connected to the parallel port or other proprietary ports # can't be detected by this program. # scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). # sane-config --version 1.0.19 # sane-config --ldflags -L/usr/lib -Wl,-rpath,/usr/lib # sane-config --libs -lsane -lusb -lpthread -lm -ljpeg -ltiff -lieee1284 -lgphoto2 -lgphoto2_port -lexif -lm -lusb -ldl I did notice under 1.0.18, I got these messages in /var/log/messages: usb 4-2: usbfs: interface 1 claimed by usblp while 'scanimage' sets config #1 usb 4-2: usbfs: interface 1 claimed by usblp while 'scanimage' sets config #1 But under 1.0.19, I get this instead: usb 4-2: usbfs: interface 1 claimed by usblp while 'scanimage' sets config #1 usb 4-2: usbfs: interface 0 claimed by usbfs while 'scanimage' sets config #1 I would appreciate any help you can give me with this. Thank you in advance.
[sane-devel] TMC failure
Gentlemen: OS: Mandriva 2008 Sane: 1.0.19 Scanner: Microtek X6EL frontend: xsane Problem: TMA(lightlid) does not light up. The scanner appears to be working properly otherwise. It works well in reflective mode. When I select the option: Use the lightlid ? 35 mm adapterthe scanner scans with the flatbed light off, but the lightlid does not light up. Using an external light source yields an image. I cannot rule out a mechanical/physical failure; I have no way to test the lid for such a failure. However, the lid has had very little use over the years and it worked well the last time I used it with a dual installation of windows 98. My present motherboard does not support windows 98, so that is no longer an option. Thank you. Respectfully, George Herzog
[sane-devel] Epson cx3700 not recognized after upgrade to 1.0.19 (repost)
can you get a debug log? SANE_DEBUG_EPSON=255 scanimage -L 2epson.log and compress the log and send to list (if under 50K) allan On Wed, Jul 9, 2008 at 6:37 AM, Tom throw_away_2002 at yahoo.com wrote: I didn't receive any replies to this, so I will try again. Everything worked absolutely flawlessly under 1.0.18. After the upgrade, which according to the ChangeLog added this device (usb 0x4b8 0x818) to backend/epson_usb.c (which I thought would make everything work better), I can't get scanimage (or any other program for that matter) to see the device (even though sane-find-scanner does). If I downgrade back to 1.0.18, then everything works again. I don't know what you need to diagnose this, but let me start with: # sane-find-scanner # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. # Also you need support for SCSI Generic (sg) in your operating system. # If using Linux, try modprobe sg. found USB scanner (vendor=0x04b8 [EPSON], product=0x0818 [USB MFP]) at libusb:004:012 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. # Not checking for parallel port scanners. # Most Scanners connected to the parallel port or other proprietary ports # can't be detected by this program. # scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). # sane-config --version 1.0.19 # sane-config --ldflags -L/usr/lib -Wl,-rpath,/usr/lib # sane-config --libs -lsane -lusb -lpthread -lm -ljpeg -ltiff -lieee1284 -lgphoto2 -lgphoto2_port -lexif -lm -lusb -ldl I did notice under 1.0.18, I got these messages in /var/log/messages: usb 4-2: usbfs: interface 1 claimed by usblp while 'scanimage' sets config #1 usb 4-2: usbfs: interface 1 claimed by usblp while 'scanimage' sets config #1 But under 1.0.19, I get this instead: usb 4-2: usbfs: interface 1 claimed by usblp while 'scanimage' sets config #1 usb 4-2: usbfs: interface 0 claimed by usbfs while 'scanimage' sets config #1 I would appreciate any help you can give me with this. Thank you in advance. -- 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] [RFC][PATCH] sanei configuration framework extension
Le Monday 07 July 2008 22:25:34 m. allan noah, vous avez ?crit?: 2008/6/25 stef stef.dev at free.fr: here's the patch modified like you suggest. Now both descriptors and placeholders are given by the backend. There is no need for a free'ing function anymore. this looks very good, but i dont see much point in the helper functions. presumably the backend will maintain some sort of enum list of indexes (like most do with options), so it wont need to lookup by name, and the initializer would probably be fewer lines of code if done inside the backend, and you wont need the descriptor array to be null terminated. oh, and what about a backend that has only option lines in the config file, it would never call the callback. i guess the backend can still read the SANEI_Config structure pointer if it cached it somewhere, after calling sanei_configure_attach()? allan -- The truth is an offense, but not a sin Hello, I removed other functions other than the one for parsing configuration options given by the backend. It is now up to the backend to allocate and free the needed ressources, and to provie the option count in SANEI_Config. In case a backend doesn't provide an attach callback and had only option lines, the SANEI_Config structure is still filled with the values found during configuration parsing after the call. So it can be used by the backend. The attached patch implements all this and a sample usage in the rts8891 backend. All SANE_TYPE_* with their optional constraints are supported. Among the existing configuration file, only 'calibrate' and 'port' options of canon_pp.conf wouldn't be handled directly since they rely on 2 strings parameters. I developped and tested this patch using testsuites built with 'check' (http://check.sf.net). I can provide them in case of interest. Regards, Stef -- next part -- A non-text attachment was scrubbed... Name: proposal3.patch.gz Type: application/x-gzip Size: 5511 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080709/e203b29c/attachment.bin
[sane-devel] [RFC][PATCH] sanei configuration framework extension
excellent. this will make config parsing much easier. please commit! allan 2008/7/9 stef stef.dev at free.fr: Le Monday 07 July 2008 22:25:34 m. allan noah, vous avez ?crit : 2008/6/25 stef stef.dev at free.fr: here's the patch modified like you suggest. Now both descriptors and placeholders are given by the backend. There is no need for a free'ing function anymore. this looks very good, but i dont see much point in the helper functions. presumably the backend will maintain some sort of enum list of indexes (like most do with options), so it wont need to lookup by name, and the initializer would probably be fewer lines of code if done inside the backend, and you wont need the descriptor array to be null terminated. oh, and what about a backend that has only option lines in the config file, it would never call the callback. i guess the backend can still read the SANEI_Config structure pointer if it cached it somewhere, after calling sanei_configure_attach()? allan -- The truth is an offense, but not a sin Hello, I removed other functions other than the one for parsing configuration options given by the backend. It is now up to the backend to allocate and free the needed ressources, and to provie the option count in SANEI_Config. In case a backend doesn't provide an attach callback and had only option lines, the SANEI_Config structure is still filled with the values found during configuration parsing after the call. So it can be used by the backend. The attached patch implements all this and a sample usage in the rts8891 backend. All SANE_TYPE_* with their optional constraints are supported. Among the existing configuration file, only 'calibrate' and 'port' options of canon_pp.conf wouldn't be handled directly since they rely on 2 strings parameters. I developped and tested this patch using testsuites built with 'check' (http://check.sf.net). I can provide them in case of interest. Regards, Stef -- 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
