Frank Zago wrote:
>
> > In the logfile of the backend I see that the option
> > tstbackend is complaining about is not active:
> >
> > [microtek2] sane_control_option: option 21; action 1
> > [microtek2] sane_control_option: option 21 not active
> >
> > Therefore sane_control_option fails with SAN
Hi Frank,
I've tested your tstbackend from 08.04.2001. It showed me
nicely some bugs in my microtek2 backend :-). But after
correcting some of them, I'm now at the following point:
karsten@coyote:~ > tstbackend -d microtek2:/dev/scanner -l 1
2>tst.log
tstbackend, Copyright (C) 2002 Frank Zago
tst
> In the logfile of the backend I see that the option
> tstbackend is complaining about is not active:
>
> [microtek2] sane_control_option: option 21; action 1
> [microtek2] sane_control_option: option 21 not active
>
> Therefore sane_control_option fails with SANE_STATUS_INVAL.
tstbackend, for so
Hi,
On Thu, Mar 21, 2002 at 11:04:36PM -0600, Peter Fales wrote:
> Another bug?
>
> I'm hitting line 1265:
>
> if (resolution_mode_optnum) {
>
> with resolution_mode_optnum set to 11, (my highest legal option is
> 10). I think maybe get_optdesc_by_name should set *option_num to
Another bug?
I'm hitting line 1265:
if (resolution_mode_optnum) {
with resolution_mode_optnum set to 11, (my highest legal option is
10). I think maybe get_optdesc_by_name should set *option_num to zero in
addition to returning NULL if the option is not found.
--
Pete Fales
i
> I was getting strange results with the gphoto2 backend, and I've traced
> it to what I think is a bug in tstbackend. Early in the program,
> sane_get_devices() is called and the result is stored in device_list[].
> Then this block is executed:
>
> if (!devname) {
> if (de
I was getting strange results with the gphoto2 backend, and I've traced
it to what I think is a bug in tstbackend. Early in the program,
sane_get_devices() is called and the result is stored in device_list[].
Then this block is executed:
if (!devname) {
if (device_list[0])
> tstbackend -d mustek_usb -l1 (recursion = 1)
> TEST: options consistency
> warnings: 0 error: 0 checks: 1379
>
> tstbackend -d mustek_usb -l1 (recursion = 2)
> TEST: options consistency
> ERROR : cannot get boolean option 12 value (Invalid argument)
>
Hi,
On Tue, Mar 19, 2002 at 05:01:33PM -0600, Frank Zago wrote:
> > That doesn't mean that I don't find bugs but they are located in the
> > backends not in tst-backend currently. I'm looking into the net
> > backend and wire code currently. Lots of pleasure...
>
> Oh? I though you were only find
Hi,
On Tue, Mar 19, 2002 at 04:39:34PM -0600, Frank Zago wrote:
[option 0]
> What would be the correct value for opt->name:
> - NULL or ""
> - only ""
Only "" in my opinion. (SANE standard 4.5.1: Option Number Count:
"Option number 0 has an empty string as its name.")
Bye,
Henning
--Boundary-00=_9VN95SOBJV156645A72R
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Subject:
Henning Meier-Geinitz, Mittwoch, 20. März 2002 00:00:
...
> That doesn't mean that I don't find bugs but they are located in the
> backends not in tst-backend
Henning Meier-Geinitz wrote:
>
> Hi,
>
> On Tue, Mar 19, 2002 at 10:58:31PM +0100, Oliver Rauch wrote:
> > The testbackend prints a warning:
> > warning : invalid size for option halftone-pattern
> >
> > for this option:
> > /* halftone pattern */
> > scanner->opt[OPT_HALFTONE_PATTERN].name
Hi,
On Tue, Mar 19, 2002 at 02:19:21PM -0600, Frank Zago wrote:
> Your bug report looks smaller everytime. I take that as a good sign :)
That doesn't mean that I don't find bugs but they are located in the
backends not in tst-backend currently. I'm looking into the net
backend and wire code curre
is this in CVS now ?
___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Hi,
On Tue, Mar 19, 2002 at 10:58:31PM +0100, Oliver Rauch wrote:
> The testbackend prints a warning:
> warning : invalid size for option halftone-pattern
>
> for this option:
> /* halftone pattern */
> scanner->opt[OPT_HALFTONE_PATTERN].name = SANE_NAME_HALFTONE_PATTERN;
> scanner->opt[OP
Frank Zago wrote:
>
> > for (*option_num = 0; *option_num <= num_dev_options; (*option_num)++)
> > {
> >
> > Shouldn't this be "< num_dev_options"
>
> Fixed. New release uploaded.
>
> Your bug report looks smaller everytime. I take that as a good sign :)
>
> In your pnm backend, in sane_g
Hi,
On Mon, Mar 18, 2002 at 09:37:22PM -0600, Frank Zago wrote:
> New tstbackend available.
The pnm backend (with lower recursion level) bails out with -l2:
FATAL ERROR : cannot get option descriptor for option 27 (Success)
There are only 27 options (0-26) so there is something wrong here.
Also
Hi,
On Mon, Mar 18, 2002 at 09:37:22PM -0600, Frank Zago wrote:
> > Overflow somewhere?
>
> Yes. Now it is a long long.
Is long long supported everywhere? Compiling with gcc 2.95.4 returns:
tstbackend.c:73: warning: ANSI C does not support long long'
tstbackend.c: In function display_stats':
tst
Hi,
On Mon, Mar 18, 2002 at 09:07:11PM -0600, Peter Fales wrote:
> For the gphoto2 backend, it's complaining that my vendor string isn't
> recognized.
>
> 1) I can't find anything in the standard that says vendor strings must
>come from a finite list.
They should come from the vendor list if
> That doesn't mean that I don't find bugs but they are located in the
> backends not in tst-backend currently. I'm looking into the net
> backend and wire code currently. Lots of pleasure...
Oh? I though you were only finding bugs in tstbackend :)
> > In your pnm backend, in sane_get_parameters,
Hi Oliver,
> when for Option 0 the name is not defined (opt->name == NULL) then this code
> prints the warning about empty name. e.g. the additional "if (opt->name !=
> NULL)"
> solves the Problem, but then the opt->name != NULL of the check command also
> can be removed:
>
> if (opt->name != NUL
> for (*option_num = 0; *option_num <= num_dev_options; (*option_num)++) {
>
> Shouldn't this be "< num_dev_options"
Fixed. New release uploaded.
Your bug report looks smaller everytime. I take that as a good sign :)
In your pnm backend, in sane_get_parameters, you could return a slightly
d
Hi,
On Sun, Mar 17, 2002 at 10:09:13PM -0600, Frank Zago wrote:
>
> New version available.
>
> - more tests
> - displays warnings and errors instead of coredumping
> - fixes
Very interesting. Found some more oddities in my backends.
For mustek_usb the -l1 test lokks like this:
warnings: 0 err
Thanks for your testing Henning.
> Very interesting. Found some more oddities in my backends.
>
> For mustek_usb the -l1 test lokks like this:
> warnings: 0 error: 0 checks: 20837
> -l2:
> warnings: 0 error: 0 checks: -553292640
>
> Overflow somewhere?
Yes. Now it is a long long.
>
> mustek
Hi Peter,
Thanks for the testing.
> For the gphoto2 backend, it's complaining that my vendor string isn't
> recognized.
>
> 1) I can't find anything in the standard that says vendor strings must
>come from a finite list.
>
> 2) The gphoto2 backend supports cameras from many different vendors.
For the gphoto2 backend, it's complaining that my vendor string isn't
recognized.
1) I can't find anything in the standard that says vendor strings must
come from a finite list.
2) The gphoto2 backend supports cameras from many different vendors. What
is the right vendor string to use in t
Frank Zago wrote:
>
> Hi all,
>
> I've derived scanimage into a test for backend.
> Currently it does not much:
> - options check (get/set, consistent type/range, ...)
> - 2 scans per scan mode (read byte per byte, read random size)
>
> It is not (yet) a replacement for scanimage -T.
>
> Co
New version available.
- more tests
- displays warnings and errors instead of coredumping
- fixes
http://fz.eryx.net/sane/#testsuite
Hi,
On Sat, Mar 16, 2002 at 02:49:27PM +0100, mh wrote:
> I had the same problem with the plustek backend; IMHO the assumption, that a
> call to sane_control_option() must return SANE_STATUS_INVAL if the option is
> inactive, is simply wrong.
I'm not that sure. It depends on what's the meaning
From: mh
> At the moment, it's tstbackend that needs some bug fixes/improvements :-)
Indeed.
When I wrote it, I read the docs and I had to check how various
backends were working. Some assert are obviously incorrect as some of you
noticed. So do not modify your backend if you think the error is
i
Henning Meier-Geinitz, Samstag, 16. März 2002 14:09:
...
> Then tstbackend doesn't like that pnm doesn't return SANE_STATUS_INVAL
> when sane_control_option is called for an inactive option. I'm not
> sure if this is a violation of the standard. Should I change this in
> the pnm backend? The same i
Hi,
On Fri, Mar 15, 2002 at 12:05:17AM -0600, Frank Zago wrote:
> I've derived scanimage into a test for backend.
> Currently it does not much:
> - options check (get/set, consistent type/range, ...)
> - 2 scans per scan mode (read byte per byte, read random size)
While testing the pnm backen
Frank Zago wrote:
> I've derived scanimage into a test for backend.
> Currently it does not much:
> - options check (get/set, consistent type/range, ...)
> - 2 scans per scan mode (read byte per byte, read random size)
>
> It is not (yet) a replacement for scanimage -T.
>
> Comments?
I found
On Sat, Mar 16, 2002 at 11:54:09AM +0100, Bertrik Sikken wrote:
> Frank Zago wrote:
> > I've derived scanimage into a test for backend.
..
> > Comments?
>
> I found at least one bug in the niash backend (experimental backend
> for hp3300c) your program, thanks.
..
> The backend that I tested does
Hi,
On Fri, Mar 15, 2002 at 12:05:17AM -0600, Frank Zago wrote:
> I've derived scanimage into a test for backend.
> Currently it does not much:
> - options check (get/set, consistent type/range, ...)
> - 2 scans per scan mode (read byte per byte, read random size)
>
> It is not (yet) a replac
Hi all,
I've derived scanimage into a test for backend.
Currently it does not much:
- options check (get/set, consistent type/range, ...)
- 2 scans per scan mode (read byte per byte, read random size)
It is not (yet) a replacement for scanimage -T.
Comments?
http://fz.eryx.net/sane/#testsui
36 matches
Mail list logo
