[sane-devel] In progress: TRUST Imagery 9600SP (TECO_VM6552)
Hello Andrej, Ralph sent me his code in April but went silent since then. I've attached what he send me, so you (or someone else) can start from there. Regards, Frank. -- next part -- A non-text attachment was scrubbed... Name: teco3.tgz Type: application/x-compressed Size: 14932 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080611/7b95f26b/attachment.bin
[sane-devel] SANE 1.1.0 Release discussion
> 6. Common debugging bitmask: > > 1 major errors > 2 minor errors > 4 function start/stop msgs > 8 function detail msg > 16 SANE_OPTION processing msgs > 32 calibration msgs > 64 outgoing command dump > 128 incoming data dump > > help me fix that... > Should these need to be bitmasks ? I think most backends are using levels instead. Bitmasks are more complicated to use for a normal user, while a level is pretty simple.
[sane-devel] SANE 1.1.0 Release discussion
> 6. Common debugging bitmask: > > 1 major errors > 2 minor errors > 4 function start/stop msgs > 8 function detail msg > 16 SANE_OPTION processing msgs > 32 calibration msgs > 64 outgoing command dump > 128 incoming data dump > > help me fix that... > Should these need to be bitmasks ? I think most backends are using levels instead.
[sane-devel] In progress: TRUST Imagery 9600SP (TECO_VM6552)
m. allan noah wrote: > On 4/3/08, Gerard Klaver wrote: > >> On Thu, 2008-04-03 at 14:56 +0200, Ralph D. Ungermann wrote: >> > > On Wed, Mar 5, 2008 at 8:41 AM, Ralph D. Ungermann wrote: >> > >> >> > >> I'm about to adapt the teco3 backend to the VM6552. >> > >> >> > >> My question: Is there still any public interest in backends for >> > >> such old scanners? >> > >> > >> > m. allan noah wrote: >> > > though there may not be much interest, we will accept patches if you >> > > get it working and it compiles cleanly. we might even make you >> > > maintainer of the code if you are not careful :) >> > >> > >> > My scanner now runs fine! But unfortunately, it turned out to be not a >> > patch, but a major rewrite (with 30% less lines). I presume, that my >> > backend also solves major issues for the other supported scanners, >> > chiefly with color scans and responsiveness (to cancel). But I have no >> > way to test it for other teco models, and I don't want to fool millions >> > of happy teco3 users. >> > >> > If there is anybody else out there using backend teco1, teco2, or teco3, >> > I'm willing to unify and maintain that driver. But now I sit idle, until >> > somebody googles and finds this email... >> > >> > Meanwhile: Anyone here need help coding or reviewing his code? >> > >> > -- ralph >> > >> > >> > >> > >> >> >> Hello Ralph, >> >> I am the maintainer of the teco2 backend, if you have a link (or send a >> zip file with data to mailbox) to your backend i can have a look and add >> improvements to the teco2 backend. >> >> http://gkall.hobby.nl/scanner.html >> >> >> >> PS. Frank Zago is the maintainer for the teco1 and teco3 backend. >> -- >> >> m.vr.gr. >> >> Gerard Klaver >> > > Gerard- Sorry, I thought these backends were all unmaintained. I stand > corrected. > > Can you say how similar the protocol is on all these machines? Is it > reasonable to combine the backends? > No. There is 3 backends for a reason. I could take a look at Ralph's code and make sure it's indeed different than the other scanners. In that case the best solution would be to create a teco4 backend. And since I don't have any scanner left I don't think it's a good idea to patch an existing backend besides fixing obvious bugs. Regards, Frank.
[sane-devel] How to avoid gcc warnings
jazz_johnson at verizon.net a ?crit :
> On Tuesday 20 November 2007, Mattias Ellert wrote:
>
>> 20 nov 2007 kl. 12.32 skrev Volker Grabsch:
>>
>>> On Mon, Nov 19, 2007 at 11:36:20AM -0500, m. allan noah wrote:
>>>
ok, lets start by saying that lots of other sane backends produce
warnings, and i am probably running a newer version of gcc than you,
so it's not a requirement that we remove all of them. it's just a pet
peev of mine.
1. if you put a little 'arg = arg;' line in the function, gcc will
shutup about the param.
>>> I'd rather recommend:
>>>
>>>(void)arg;
>>>
>>> because this command has no "action". ('arg = arg;' is an assigment)
>>> This solution also works better for 'const' arguments.
>>>
>> You can also leave the parameter unnamed in the declaration:
>>
>> sense_handler (int scsi_fd, u_char * result, void*)
>>
>> This will also get rid of the warning.
>>
>> Mattias
>>
>
> Leaving out the parameter name gives me an error:
>
> In file included from hs2p.c:95:
> hs2p-scsi.c: In function 'sense_handler':
> hs2p-scsi.c:384: error: parameter name omitted
> make[1]: *** [hs2p.lo] Error 1
> make[1]: Leaving directory `/var/tmp/portage/sane-backends-1.0.18/backend'
> make: *** [all-recursive] Error 1
>
>
You can use __sane_unused__ :
sane_init (SANE_Int * version_code, SANE_Auth_Callback __sane_unused__
authorize)
Or use UNUSEDARG (grep sources for that one)
Frank
[sane-devel] Panasonic KVSS905C SCSI driver
Julien BLACHE a ?crit : > Frank Zago wrote: > > Hi, > > >>> Apache 2.0, indeed, the license sucks big time ... >>> >>> >> If someone wants to do the work, may be he can get Google to relicense >> the code. >> > > It's only hosted on Google Code, which provides hosting services ala > sf.net, it's not written by Google :) > Here's one header : // Copyright 2007 Google Inc. All Rights Reserved. // Author: agl at imperialviolet.org (Adam Langley) // // Copyright (C) 2007 Google Inc.
[sane-devel] Panasonic KVSS905C SCSI driver
Julien BLACHE a ?crit : > Frank Zago wrote: > > Hi, > > >> I looked at the code. It a basic scsi scanner driver. It should take a >> couple hours work to make a backend, starting from the existing >> matsushita driver. >> >> The only problem IMHO is the license, and the testing. >> > > Apache 2.0, indeed, the license sucks big time ... > If someone wants to do the work, may be he can get Google to relicense the code. > But the license only covers the code, not the knowledge you can gain > by reading it. > Well, the code is so basic it's going to be a cut and paste. > I don't know how close these scanners are from the ones supported by > the matsushita backend already, so ... > AFAICT, the work flow is the same. But some of the SCSI commands used are more recent, and the window format is different. That's why a new driver should be written instead of using the existing one. > >> And when I see how simple these scanners are, I don't understand >> Panasonic's need for an NDA. >> > > Big companies and their NDAs ... > Precious IP that anyone why a scsi analyser can reverse in less than a day. Frank.
[sane-devel] [Fwd: Re: Panasonic KVSS905C SCSI driver]
Hello, Julien BLACHE a ?crit : > "Jeff Breidenbach" wrote: > > Hi, > > I've been told about a standalone driver for some Panasonic high-speed > scanners, see details at the URL below: > > >> Can you make sure the SANE team is aware of this Panasonic >> KV-SS905C SCSI driver? Thanks. >> >> http://code.google.com/p/kvss905c/ >> > > I'm told it works well but doesn't support all the features (yet?), > quality is good and reliability is good too. > > Maybe someone will be interested in turning that driver into a SANE > backend ? > I looked at the code. It's a basic scsi scanner driver. It should take a couple hours work to make a backend, starting from the existing matsushita driver. The only problem IMHO is the license, and the testing. And when I see how simple these scanners are, I don't understand Panasonic's need for an NDA. Frank.
[sane-devel] SANE2, time for a decision
Hello Alessandro Zummo, > Hello sane developers, > > Some weeks ago I introduced (once again) the discussion > about SANE future. Now is time to take action. > > The situation is that we have coders willing to implement > the SANE2 standard (whatever this will be) for a bunch of backends > but are missing the people required to revamp sanei, the build > system and the frontends. > > The standard itself is not complete, but this is something > that can be fixed. > > However, we already have lost too much time in this limbo. > Not even a decade :) > I would like to run a poll (suggestions for good poll web sites > are accepted) asking user and devs what they think about the > SANE future. > > The poll options will be: > > - Reopen development on SANE1 > - Fork SANE1 > - Wait SANE2 indefinitely > Or "evolve a fork of SANE1 into SANE2". > I will gladly accept suggestions for other options > as long as they are credible. i.e. "Develop SANE2" > will not be accepted unless it includes a list of > developers that are going to make it happen. > > I'm sorry for being a bit rough, but time is > passing by and we need to go somewhere. > All it takes is a motivated person. I can provide a some of my time to help, but I cannot commit to much. I have found an e-mail I wrote a few years back, which remains so true to me: http://lists.alioth.debian.org/pipermail/sane-devel/2003-August/008482.html Frank.
[sane-devel] SANE2 commitment
Alessandro Zummo wrote: > On Sun, 17 Dec 2006 19:33:51 +0100 > Frank Zago wrote: > > >>> some people has committed the time necessary to >>> port to sane2 the first bunch of drivers. >>> >>> we are currently missing coders for >>> - all of sanei/* (i'll take sanei_tcp) >>> - the build system (configure, makefile et al) >>> - X11 frontends >>> >>> > > >> I believe the right approach is to fork the existing tree and start >> fixing and adding functionalities to it. That way you'll keep something >> that works all the time, saving many headaches. >> As or for the sane2 standard, it's only just a piece of paper right now. >> Coding should determine what will stay and what will go away, not the >> opposite (cathedral vs bazaar). >> > > so you're saying to declare current sane as stable, > fork it and add features to the new tree, making > it "morphing" into something that will be the next sane? > Yes. I think sane1 can evolve into sane2 step by step so as to keep a working tree.
[sane-devel] SANE2 commitment
Alessandro Zummo wrote: > Hello developers, > >since there seems to be interest in developing sane2, I've decided > to start this thread in order to collect the commitment of each developer. > > I'm willing to port the epson driver to sane2, help porting the > coolscan driver and handle the command line frontend. > > I think Giuseppe Sacco has showed interest to do coolscan > bits. > > A friend of mine, Stefano Merlo, has committed himself > to the canon driver. > > I'd appreciate if everyone who is interested can reply > with their own commitments for the 2007.. ehm.. sane2 :) > > I can port mine. Frank.
[sane-devel] SANE2 commitment
Alessandro Zummo wrote: > On Sun, 17 Dec 2006 15:02:19 +0100 > Jochen Eisinger wrote: > > >> Hi, >> >> Alessandro Zummo wrote: >> >>> I'd appreciate if everyone who is interested can reply >>> with their own commitments for the 2007.. ehm.. sane2 :) >>> >> I'm quite surprised to hear there is a sane2 standard - at least one >> that we can easily start to implement. >> >> I don't think it's a good idea to start hacking something before it's >> clear we have a standard that will support us for the next few years. >> > > you're right. my idea is to rally up some developers > and then define the standard. only then we should start > hacking. > > however, defining the standard without the developers > will not lead us to anything useful. > > some people has committed the time necessary to > port to sane2 the first bunch of drivers. > > we are currently missing coders for > - all of sanei/* (i'll take sanei_tcp) > - the build system (configure, makefile et al) > - X11 frontends > > I believe the right approach is to fork the existing tree and start fixing and adding functionalities to it. That way you'll keep something that works all the time, saving many headaches. As or for the sane2 standard, it's only just a piece of paper right now. Coding should determine what will stay and what will go away, not the opposite (cathedral vs bazaar). Frank.
[sane-devel] old Agfa DuoScan / Floating point exception
Daniel Bauer wrote: >Am Sonntag, 16. April 2006 13:11 schrieb Frank Zago: > > >>Hello Daniel, >> >> >> >Hi Frank >thanks for looking at my problem! > > > >>As indicated by the trace you provided, the crash happenned at line 4017 >>in microtek.c: >> s->max_scsi_lines = SCSI_BUFF_SIZE / (s->pixel_bpl + s->header_bpl); >> >> >> >I now get a first idea of what all those messages mean... > > > >>So this is a division by 0. Which probably means that both s->pixel_bpl >>and s->header_bpl are 0. >> Looking at the other traces, it looks like your scanner could be >>supported. But you'll have to recompile the microtek backend to add more >>traces to understand why these values are not set. Do you know how to do >>that ? >> >> > >Unfortunately not. > > > >>Do you know a bit of C ? >> >> > >No, but I'm not afraid of it. I am willing to learn and try, but I guess I'd >need quite a lot of guiding thru the necessary steps. So, if you feel up to >help me, I'll be glad to take the opportunity, of course... > >(I have some programming skills from earlier times (COBOL) and know some >script languages (php4, JavaScript), however no object oriented languages, >but at least the "basic understandings" are given, I guess.) > > > First you have to uninstall sane-backend. Something such as "rpm -e --nodeps sane-backends" should do. Then download the sane-backends from sane-project.org. Untar in a suitable place, then type the usual "./configure", "make" and as root "make install". You should then be able to do the same (failing) test again and get the same results. After that we can move to the next stage. Frank.
[sane-devel] old Agfa DuoScan / Floating point exception
Daniel Bauer wrote: >Am Sonntag, 16. April 2006 16:17 schrieb Frank Zago: >... > > >>You should then be able to do the same (failing) test again and get the >>same results. >> >> > >not exactly, the differences are: >- the scanner is not detected anymore from a user prompt now (I've read about >that somewhere and will search again later, I guess this is not the main >problem) >- as root the floating point exception doesn't appear anymore, but the sanner >is "found twice": > >. > >addendum: > >when I add the device-name: >scanimage --device-name=microtek:/dev/sg0 >then the "floating point exception appears" same as before > >(scanimage --device-name=snapscan:/dev/sg0 gives: >scanimage: open of device snapscan:/dev/sg0 failed: Error during device I/O ) > >regards > >Daniel > > > > Before changing the code, set SANE_DEBUG_MICROTEK to 128 (type "export SANE_DEBUG_MICROTEK=128" under your shell) and redo your test. That will give more information. In particular get_scan_status() doesn't seems to return the correct information, which leads to linewidth being 0. Frank.
[sane-devel] old Agfa DuoScan / Floating point exception
Hello Daniel, As indicated by the trace you provided, the crash happenned at line 4017 in microtek.c: s->max_scsi_lines = SCSI_BUFF_SIZE / (s->pixel_bpl + s->header_bpl); So this is a division by 0. Which probably means that both s->pixel_bpl and s->header_bpl are 0. Looking at the other traces, it looks like your scanner could be supported. But you'll have to recompile the microtek backend to add more traces to understand why these values are not set. Do you know how to do that ? Do you know a bit of C ? Regards, Frank.
[sane-devel] [patch] sane-canon: Endian inverted data when scanning 48bbp raw mode pnm, little endian architectures only
>+#if defined(WORDS_BIGENDIAN)
> for (p = buf; p < buf + nread; p++)
> {
> b = *p;
> *p++ = *(p + 1);
> *p = b;
> }
>+#endif
> }
>
Why not use htons() which should be a little more efficient?
[sane-devel] mustek_usb2 backend ready for inclusion in CVS -- please test!
Henning Meier-Geinitz wrote: >Hi, > >On Sat, Oct 01, 2005 at 10:52:51PM +0200, s...@zago.net wrote: > > >>This code is in dire need of de-windowsification. Eg this kind of non >>portable code: >> typedef unsigned long UINT, DWORD, *LPDWORD; >> >> > >Unfortunately you are right. The code has been created by Mustek based >on their Windows source code. I'll see what size these types really >need. I'm pretty sure that "unsigned int" is ok for all of them. > > These types are 32 bits on all modern windows (including their 64 bits versions). >The idea is to keep the SANE and Windows driver as close as possible >to eachother to enable the Mustek people to add more scanners easier. > >On the other hand I already had to change a lot of stuff like their >split in separate libraries. > > If mustek intend to provide new code drops that's going to be painful. Couldn't you keep these files insulated from the rest of Sane? > > >>There's also some global variables that should be moved somewhere else >>(m_bDSOpen, ...) >> >> > >While I also think it's better to don't use global variables for all >the scanner states, changing this requires a lot more effort. Also it >makes the backend again more different to the Windows driver. I'm not >sure yet if that's worth the effort. > > Unless I'm mistaken, these variables can go into the sane handle. Frank.
[sane-devel] Lexmark X1100 backend available
Hi Fred, Good job. I have a few remarks about the the code: - option are prefixed by LXK_ (eg LXK_OPT_SCAN_SIZE). Backends usually don't use a prefix. - size_list[] doesn't have A4 and other standard formats. You can get some values at http://www.cl.cam.ac.uk/~mgk25/iso-paper.html - in sane_start(), sane_read(), and probably other, you check whether the handle is a valid one. While this is correct I think it's overkill. The frontend should be trusted. - bytes_read in sane_read() should be a long instead of ssize_t to avoid a cast. - in lexmark-x1000.c, there 6 global variables (transfer_buffer, ...). They should be per scanner instance. Same thing with at least eof, x_dpi and y_dpi in lexmark.c. - shouldnt the lexmark copyright be in lexmark-x1000.c too? - unless you intend to add more code to read_buffer_is_empty(), get rid of it. - you could replace "scan-size" with SANE_NAME_PAPER_SIZE which is already used by 2 other backends. I also get the following warnings when I compile (target is x86_64): lexmark-x1100.c:59:1: warning: "BACKEND_NAME" redefined :10:1: warning: this is the location of the previous definition lexmark-x1100.c: In function `x1100_read_scan_data': lexmark-x1100.c:2359: warning: unsigned int format, different type arg (arg 3) lexmark-x1100.c:2360: warning: unsigned int format, different type arg (arg 3) lexmark-x1100.c:2361: warning: cast from pointer to integer of different size lexmark-x1100.c:2395: warning: unsigned int format, different type arg (arg 3) lexmark-x1100.c:2396: warning: unsigned int format, different type arg (arg 3) lexmark-x1100.c: In function `read_buffer_bytes_available': lexmark-x1100.c:2728: warning: comparison between signed and unsigned Regards, Frank.
[sane-devel] good adf scanners
Jens Gulden wrote: > Brad Barnett schrieb: > >> >> Does anyone have any suggestions for a well supported ADF scanner, under >> Linux? The SANE support list doesn't specify such things in the summary, >> which makes it more difficult to pick a good one.. >> >> Any tales of success and words of wonder are welcome! >> > > See the thread "Good office scanners with ADF support?" just one week > ago on this list. > Some scanners in the Panasonic KV-SS serie are also well supported. I don't have any pending problems for the backend, and I know some people are using it :) These are nice and reliable scanners, and used ones can be bought for quite cheap on ebay. Frank.
[sane-devel] Canoscan 5200F
Your scanner doesn't seem to be supported. http://sane-project.org/unsupported/canon-5200f.html
[sane-devel] unpaper default parameter - empty output bug
Hi Jens, Jens Gulden wrote: > Peter Fales schrieb: > >> Now that's wierd. I was using a privately built copy of unpaper, but I >> just unpacked the tarball and get the same results with the prebuilt >> binary! > > > I just reproduced the problem on one remote Intel machine I have access to. > > Try to compile without any optimization (no -Ox), this was the only way > for me to get a usable executable for that machine. Does it help for > you? (I am using gcc 3.3.5 on Debian.) > > Jens Compile unpaper with the -Wall options and fix all the warnings. It will show there's a few bug (uninitialized variables for instance). gcc -Wall -O1 -g3 unpaper.c -o unpaper -lm Once it's done, run valgrind on it and fix the bugs it finds. valgrind --tool=memcheck unpaper tst.pgm tst2.pgm Frank.
[sane-devel] [patch] fix SANE_Device
Oliver Rauch wrote:
> Am Mit, 2004-11-17 um 20.58 schrieb fz...@austin.rr.com:
>
>>>Hello Frank.
>>>
>>>I am not a fan of this patch.
>>>I think it will work but I think it is a hack.
>>>
>>>It seems that only a few backends have problems with this.
>>
>>A few backend are creating the name of the manufacturer from the scsi inquiry.
>>A lot of backends are creating their mode list from the device.
>>This patch will allow us to get rid of about 150 (IMO legitimate) warnings.
>>The current code is not clean.
>>
>>
>>
>>>Why not fix it in a proper way:
>>
>>The non hack solution is to have two headers: one for the symbols exported
>>and one for internal use. Same as what is done with the linux kernel
>>structure s.
>>
>>
>>>create the strings as non const and then set the
>>>sane_device structur to point to these strings?!
>>
>>This will not work. That why there is so much warnings.
>
>
> IMO thats not ture.
> It is allowed to do this:
>
> char *hello;
> const char *hello_const;
>
> hello="ABC";
>
> hello_const = hello;
>
>
>
> and this produces a warning:
>
> *hello_const = 'A';
>
> what is correct becaus we use a pointer to a const char to change the
> char so it is not const any more.
>
> It is not a const pointer to a char, it is a pointer to a const char.
> And it is allowed to make a pointer of type pointer to const char point
> to a (non const) char.
>
> I attach a little test c-code for this. Compile with
>
> gcc consttest.c -o consttest -Wall
>
> (gcc version 3.2.2 20030222)
>
> Oliver
>
>
>>>But when I am the only one who is against this patch
>>>then I will be quiet and it will be ok for me. It is nothing
>>>that will steal my sleep :)
>>>
>>
>>Your input is appreciated. Thanks.
>>
>>Frank.
>>
>>
>>
>>
>>
>>
>>
>>
>>#include "stdio.h"
>>#include "stdlib.h"
>>
>>int main()
>>{
>> const char *hello_const;
>> char *hello;
>>
>> printf("defining hello=\"Hello\"\n");
>> printf("defining hello_const = hello\n");
>> hello = "Hello";
>> hello_const = hello;
>> printf("hello = %s\n", hello);
>> printf("hello_const = %s\n", hello_const);
>> printf("\n");
>>
>> printf("defining hello = (char *) malloc(10)\n");
>> printf("defining *hello = \'A\'\n");
>> printf("defining *(hello+1) = \'B\'\n");
>> printf("defining hello_const = hello\n");
>> hello= (char *) malloc(10);
>> hello_const = hello;
>> *hello='A';
>> *(hello+1)='B';
>> hello[2]=0;
>> printf("hello = %s\n", hello);
>> printf("hello_const = %s\n", hello_const);
>> printf("\n");
>>
>> printf("unallowed defining *hello_const = \'X\'\n");
>> *hello_const='X';
>>
>> printf("hello = %s\n", hello);
>> printf("hello_const = %s\n", hello_const);
>>
>> return 0;
>>}
Your example is missing the one thing I'd like to see fixed. How do you free
your memory allocated?
free(hello_const) will generate a warning.
free((void *)hello_const) will also generate a warning.
So do we fix:
dev->sane.name = strdup (devname);
...
free(dev->sane.name);
with:
unconst_name = strdup (devname);
dev->sane.name = unconst_name;
..
dev->sane.name = NULL;
free(unconst_name);
Or we fix dev->sane.name's definition
Or we do nothing and live with 150 warnings (for both SANE_Device and
SANE_Descriptor)?
Frank.
[sane-devel] [patch] fix SANE_Device
Mattias Ellert wrote: > Frank Zago wrote: > >> SO? Is anyone for or against this patch? > > > This patch introduces SANE backend internal definitions in the public > sane.h header. Backend internal definitions should be in the sanei_*.h > headers. > > If you really want different definitions of the structs internally in > the backends these should be in a sanei_*.h header not in the public > header. > Alas, the backends are including the public header, so that's not possible.
[sane-devel] [patch] fix SANE_Device
Frank Zago wrote:
>=20
>>
>> The SANE standard defines the comunication between frontend and backen=
d.
>> It does not define any structs that shall be internally used by the
>> frontend or backend.
>>
>> I think the clean appoach is that the backend handles the texts intern=
al
>> as non const strings and only creats the SANE_Device struct to return
>> the data to the frontend. The SANE_Device struct is defined for the
>> purpose to transfer the data from the backend to the frontend as const
>> chars. When the backend has to use non const definitions then it is no=
t
>> allowed to use the SANE_Device struct so it has to use it=C2=B4s own d=
ata
>> types and not the one of the SANE standard.
>>
>> Oliver
>=20
>=20
> So, in that case what about the patch in attachment.
>=20
> I've also changed the internal definition of SANE_Option_Descriptor for=
=20
> the same reason. It breaks about 5 backends, but they can all be easil=
y=20
> fixed by hand by removing a few const. I'd say that the current=20
> definition of SANE_Device and SANE_Option_Descriptor and created an ugl=
y=20
> cascade of unnecessary casts and consts in all the backends.
>=20
> Frank.
>=20
>=20
>=20
> ---=
-
>=20
> Index: include/sane/sane.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/sane/sane-backends/include/sane/sane.h,v
> retrieving revision 1.6
> diff -u -3 -p -B -b -u -r1.6 sane.h
> --- include/sane/sane.h 13 Nov 2004 20:29:14 - 1.6
> +++ include/sane/sane.h 14 Nov 2004 18:59:03 -
> @@ -92,6 +92,16 @@ typedef enum
>}
> SANE_Unit;
> =20
> +#ifdef BACKEND_NAME
> +typedef struct
> + {
> +SANE_String name;/* unique device name */
> +SANE_String vendor; /* device vendor string */
> +SANE_String model; /* device model name */
> +SANE_String type;/* device type (e.g., "flatbed scanner") */
> + }
> +SANE_Device;
> +#else
> typedef struct
>{
> SANE_String_Const name; /* unique device name */
> @@ -100,6 +110,7 @@ typedef struct
> SANE_String_Const type; /* device type (e.g., "flatbed scanner") *=
/
>}
> SANE_Device;
> +#endif
> =20
> #define SANE_CAP_SOFT_SELECT (1 << 0)
> #define SANE_CAP_HARD_SELECT (1 << 1)
> @@ -134,6 +145,28 @@ typedef struct
>}
> SANE_Range;
> =20
> +#ifdef BACKEND_NAME
> +typedef struct
> + {
> +SANE_String name;/* name of this option (command-line name) */
> +SANE_String title; /* title of this option (single-line) */
> +SANE_String desc;/* description of this option (multi-line) */
> +SANE_Value_Type type;/* how are values interpreted? */
> +SANE_Unit unit; /* what is the (physical) unit? */
> +SANE_Int size;
> +SANE_Int cap;/* capabilities */
> +
> +SANE_Constraint_Type constraint_type;
> +union
> + {
> + SANE_String *string_list; /* NULL-terminated list */
> + SANE_Word *word_list; /* first element is list-length */
> + SANE_Range *range;
> + }
> +constraint;
> + }
> +SANE_Option_Descriptor;
> +#else
> typedef struct
>{
> SANE_String_Const name; /* name of this option (command-line name)=
*/
> @@ -154,6 +187,7 @@ typedef struct
> constraint;
>}
> SANE_Option_Descriptor;
> +#endif
> =20
> typedef enum
>{
SO? Is anyone for or against this patch?
[sane-devel] [patch] fix SANE_Device
This is a multi-part message in MIME format. --020906070304060802060600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-04.texas.rr.com id iAEJ34J5003498 >=20 > The SANE standard defines the comunication between frontend and backend. > It does not define any structs that shall be internally used by the > frontend or backend. >=20 > I think the clean appoach is that the backend handles the texts interna= l > as non const strings and only creats the SANE_Device struct to return > the data to the frontend. The SANE_Device struct is defined for the > purpose to transfer the data from the backend to the frontend as const > chars. When the backend has to use non const definitions then it is not > allowed to use the SANE_Device struct so it has to use it=C2=B4s own da= ta > types and not the one of the SANE standard. >=20 > Oliver So, in that case what about the patch in attachment. I've also changed the internal definition of SANE_Option_Descriptor for t= he same=20 reason. It breaks about 5 backends, but they can all be easily fixed by= hand=20 by removing a few const. I'd say that the current definition of SANE_Devi= ce and=20 SANE_Option_Descriptor and created an ugly cascade of unnecessary casts a= nd=20 consts in all the backends. Frank. --020906070304060802060600 Content-Type: text/plain; name="sane.diff.part32" Content-Disposition: inline; filename="sane.diff.part32" Content-Transfer-Encoding: base64 SW5kZXg6IGluY2x1ZGUvc2FuZS9zYW5lLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2 c3Jvb3Qvc2FuZS9zYW5lLWJhY2tlbmRzL2luY2x1ZGUvc2FuZS9zYW5lLmgsdgpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuNgpkaWZmIC11IC0zIC1wIC1CIC1iIC11IC1yMS42IHNhbmUuaAot LS0gaW5jbHVkZS9zYW5lL3NhbmUuaAkxMyBOb3YgMjAwNCAyMDoyOToxNCAtMDAwMAkxLjYK KysrIGluY2x1ZGUvc2FuZS9zYW5lLmgJMTQgTm92IDIwMDQgMTg6NTk6MDMgLTAwMDAKQEAg LTkyLDYgKzkyLDE2IEBAIHR5cGVkZWYgZW51bQogICB9CiBTQU5FX1VuaXQ7CiAKKyNpZmRl ZiBCQUNLRU5EX05BTUUKK3R5cGVkZWYgc3RydWN0CisgIHsKKyAgICBTQU5FX1N0cmluZyBu YW1lOwkvKiB1bmlxdWUgZGV2aWNlIG5hbWUgKi8KKyAgICBTQU5FX1N0cmluZyB2ZW5kb3I7 CS8qIGRldmljZSB2ZW5kb3Igc3RyaW5nICovCisgICAgU0FORV9TdHJpbmcgbW9kZWw7CS8q IGRldmljZSBtb2RlbCBuYW1lICovCisgICAgU0FORV9TdHJpbmcgdHlwZTsJLyogZGV2aWNl IHR5cGUgKGUuZy4sICJmbGF0YmVkIHNjYW5uZXIiKSAqLworICB9CitTQU5FX0RldmljZTsK KyNlbHNlCiB0eXBlZGVmIHN0cnVjdAogICB7CiAgICAgU0FORV9TdHJpbmdfQ29uc3QgbmFt ZTsJLyogdW5pcXVlIGRldmljZSBuYW1lICovCkBAIC0xMDAsNiArMTEwLDcgQEAgdHlwZWRl ZiBzdHJ1Y3QKICAgICBTQU5FX1N0cmluZ19Db25zdCB0eXBlOwkvKiBkZXZpY2UgdHlwZSAo ZS5nLiwgImZsYXRiZWQgc2Nhbm5lciIpICovCiAgIH0KIFNBTkVfRGV2aWNlOworI2VuZGlm CiAKICNkZWZpbmUgU0FORV9DQVBfU09GVF9TRUxFQ1QJCSgxIDw8IDApCiAjZGVmaW5lIFNB TkVfQ0FQX0hBUkRfU0VMRUNUCQkoMSA8PCAxKQpAQCAtMTM0LDYgKzE0NSwyOCBAQCB0eXBl ZGVmIHN0cnVjdAogICB9CiBTQU5FX1JhbmdlOwogCisjaWZkZWYgQkFDS0VORF9OQU1FCit0 eXBlZGVmIHN0cnVjdAorICB7CisgICAgU0FORV9TdHJpbmcgbmFtZTsJLyogbmFtZSBvZiB0 aGlzIG9wdGlvbiAoY29tbWFuZC1saW5lIG5hbWUpICovCisgICAgU0FORV9TdHJpbmcgdGl0 bGU7CS8qIHRpdGxlIG9mIHRoaXMgb3B0aW9uIChzaW5nbGUtbGluZSkgKi8KKyAgICBTQU5F X1N0cmluZyBkZXNjOwkvKiBkZXNjcmlwdGlvbiBvZiB0aGlzIG9wdGlvbiAobXVsdGktbGlu ZSkgKi8KKyAgICBTQU5FX1ZhbHVlX1R5cGUgdHlwZTsJLyogaG93IGFyZSB2YWx1ZXMgaW50 ZXJwcmV0ZWQ/ICovCisgICAgU0FORV9Vbml0IHVuaXQ7CQkvKiB3aGF0IGlzIHRoZSAocGh5 c2ljYWwpIHVuaXQ/ICovCisgICAgU0FORV9JbnQgc2l6ZTsKKyAgICBTQU5FX0ludCBjYXA7 CQkvKiBjYXBhYmlsaXRpZXMgKi8KKworICAgIFNBTkVfQ29uc3RyYWludF9UeXBlIGNvbnN0 cmFpbnRfdHlwZTsKKyAgICB1bmlvbgorICAgICAgeworCVNBTkVfU3RyaW5nICpzdHJpbmdf bGlzdDsJLyogTlVMTC10ZXJtaW5hdGVkIGxpc3QgKi8KKwlTQU5FX1dvcmQgKndvcmRfbGlz dDsJLyogZmlyc3QgZWxlbWVudCBpcyBsaXN0LWxlbmd0aCAqLworCVNBTkVfUmFuZ2UgKnJh bmdlOworICAgICAgfQorICAgIGNvbnN0cmFpbnQ7CisgIH0KK1NBTkVfT3B0aW9uX0Rlc2Ny aXB0b3I7CisjZWxzZQogdHlwZWRlZiBzdHJ1Y3QKICAgewogICAgIFNBTkVfU3RyaW5nX0Nv bnN0IG5hbWU7CS8qIG5hbWUgb2YgdGhpcyBvcHRpb24gKGNvbW1hbmQtbGluZSBuYW1lKSAq LwpAQCAtMTU0LDYgKzE4Nyw3IEBAIHR5cGVkZWYgc3RydWN0CiAgICAgY29uc3RyYWludDsK ICAgfQogU0FORV9PcHRpb25fRGVzY3JpcHRvcjsKKyNlbmRpZgogCiB0eXBlZGVmIGVudW0K ICAgewo= --020906070304060802060600--
[sane-devel] [patch] fix SANE_Device
Oliver Rauch wrote: > Am Sam, 2004-11-13 um 21.26 schrieb Frank Zago: > > >>>I guess the idea was that the strings shouldn't be changed after the >>>SANE-Device pointer is returned to the frontend. >> >>Thsi behaviour should be made clear in the doc. To me, const means something >>else. >>Since this patch makes the variable from const to non-const, I don't think it >>will break anything. >> >> >>>As far as I can see the trouble results from doing things like >>>sane.name = strdup (...) and freeing those in sane_exit(). >>> >> >>That is correct. I think it's clear from the use of that field that the const >>creates more trouble than it solves. > > > Hello Henning, hello Frank, > > I think the const should not be changed because of two reasons: > > 1) It makes sense to define it as const in the standard because >the frontend should not change anything in the struct that >is returned by the backend > 2) It is part of the sane standard and it makes a lot of problems >to change the standard definitions > > May be we need a second definition without the const in some cases, > but the struct that is returned by the backend should contain const > strings. > > So when it is necessary then the routine that needs any non const > strings has to create its own struct definition. > > May be this second (non const) definition can be put in a helper file > (sanei_???.h). > > Oliver > > So what about having an external definition for frontends, and one internal for backends?
[sane-devel] Question on SCSI Scanner in M$
Dieter Jurzitza wrote: > Dear Frank, > thank you for your fast reply. Here you go with a new file scan.log. What > makes me wonder is the fact that sane tries to open /dev/scanner and is alway > saying this interface does not exist - what is right, indeed. > I tried to start scanimage with > scanimage -d h0b0t5l0 > but scanimage says then that this device does not exist. Hence, I do not > know. > The logfile has been generated exactly as recommended in the microtec2 - > manpage. Maybe you can solve things ... > > My driver for the AHA2940 comes with M$ - and Adaptec does not offer an > alternative, therefore I think this is what I can get. > > Many many thanks for your efforts! > > take care > > [microtek2] [readimagestatus] > [microtek2] 28,00,83,00,00,00,00,00,00,00, > [microtek2] sane_get_parameters: handle=0x10033558, params=0x226e50 > [microtek2] sane_get_parameters: format=1, last_frame=1, lines=56 > [microtek2] sane_get_parameters: depth=8, ppl=283, bpl=849 > [microtek2] sane_read: handle=0x10033558, buf=0x226e70, maxlen=32768 > [microtek2] reader_process: ms=0x10033558 > [microtek2] reader_process: transferlength=32604, lines=38, linelength=858, > real_bpl=849, srcbuf=0x10042198 > [microtek2] scsi_read_image: ms=0x10033558, buffer=0x10042198 > [microtek2] scsi_read_image: transferlength=32604 > [microtek2] [readimagecmd] > [microtek2] 28,00,00,00,00,00,00,7f,5c,00, > [sanei_scsi] sanei_scsi_cmd2: DeviceIoControl() failed: 6 > [microtek2] scsi_read_image: 'Error during device I/O' > [microtek2] sane_read: read 0 bytes -> EOF > [microtek2] cleanup_scanner: ms=0x10033558, ms->sfd=460 DeviceIoControl says invalid handle. I think somehow that last read command hosed the adapter or the scanner. Do you have the possibility to recompile sane?
[sane-devel] [patch] fix SANE_Device
Henning Meier-Geinitz wrote: > Hi, > > On Sat, Nov 13, 2004 at 01:28:16PM -0600, Frank Zago wrote: > >>This patch removes the const from the name strings in SANE_Device. >>I didn't commit it because it might breaks stuff. > > > Be careful. SANE-Device is part of the SANE standard, so that would > need to be changed also. > > >>However, I believe the new definition is actually correct. > > > I guess the idea was that the strings shouldn't be changed after the > SANE-Device pointer is returned to the frontend. Thsi behaviour should be made clear in the doc. To me, const means something else. Since this patch makes the variable from const to non-const, I don't think it will break anything. > > As far as I can see the trouble results from doing things like > sane.name = strdup (...) and freeing those in sane_exit(). > That is correct. I think it's clear from the use of that field that the const creates more trouble than it solves.
[sane-devel] Re: [sane-commit] CVS update: sane-backends/include/sane
> > Wouldn't that better fit to sanei_backend.h? I think we shouldn't > export such "helper" macros to all the frontends. Yes, of course. I'll fix that right away.
[sane-devel] [patch] umax_pp: fixes for x86_64
This is a multi-part message in MIME format.
--080906040001030401050006
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
This patch makes umax_pp recognize the amd64 cpus.
--080906040001030401050006
Content-Type: text/plain;
name="sane.diff.part29"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="sane.diff.part29"
--- backend/umax_pp_low.c 8 Oct 2004 05:16:43 - 1.61
+++ backend/umax_pp_low.c 13 Nov 2004 19:34:18 -
@@ -208,7 +208,7 @@ sanei_outsl (unsigned int port, const un
/* linux GCC on i386 */
-#if ( ! defined SANE_INB ) && ( defined HAVE_SYS_IO_H ) && ( defined __GNUC__
) && ( defined __i386__ )
+#if ( ! defined SANE_INB ) && ( defined HAVE_SYS_IO_H ) && ( defined __GNUC__
) && ( defined __i386__ || defined __x86_64__)
#define SANE_INB 3
static int
@@ -305,6 +305,8 @@ sanei_insb (unsigned int port, unsigned
static void
sanei_insl (unsigned int port, unsigned char *addr, unsigned long count)
{
+ int i;
+
for (i = 0; i < count * 4; i++)
addr[i] = sanei_inb (port);
}
--080906040001030401050006--
[sane-devel] [patch] v4l fix for 64 bits platforms
This is a multi-part message in MIME format.
--010607050104040304090109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
--010607050104040304090109
Content-Type: text/plain;
name="sane.diff.part30"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="sane.diff.part30"
--- backend/v4l.c 30 May 2004 13:48:40 - 1.16
+++ backend/v4l.c 13 Nov 2004 19:34:18 -
@@ -986,7 +986,7 @@ sane_start (SANE_Handle handle)
s->mbuf.size, s->mbuf.frames, s->mbuf.offsets[0]);
buffer =
mmap (0, s->mbuf.size, PROT_READ | PROT_WRITE, MAP_SHARED, s->fd, 0);
- if ((int) buffer == -1)
+ if (buffer == (void *)-1)
{
DBG (1, "sane_start: mmap failed: %s\n", strerror (errno));
return SANE_STATUS_IO_ERROR;
--010607050104040304090109--
[sane-devel] [patch] fix SANE_Device
This is a multi-part message in MIME format.
--020303030609050904070206
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
This patch removes the const from the name strings in SANE_Device.
I didn't commit it because it might breaks stuff. However, I believe the new
definition is actually correct. On my tree, the number of warnings drop from
137
to 94. It also introduces a few more warnings, but these can be fixed too.
If no one objects, I will commit it in a few days.
Frank.
--020303030609050904070206
Content-Type: text/plain;
name="sane1.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="sane1.diff"
Index: include/sane/sane.h
===
RCS file: /cvsroot/sane/sane-backends/include/sane/sane.h,v
retrieving revision 1.5
diff -u -3 -p -B -b -u -r1.5 sane.h
--- include/sane/sane.h 13 Nov 2004 19:04:44 - 1.5
+++ include/sane/sane.h 13 Nov 2004 19:21:31 -
@@ -110,10 +110,10 @@ SANE_Unit;
typedef struct
{
-SANE_String_Const name;/* unique device name */
-SANE_String_Const vendor; /* device vendor string */
-SANE_String_Const model; /* device model name */
-SANE_String_Const type;/* device type (e.g., "flatbed scanner") */
+SANE_String name; /* unique device name */
+SANE_String vendor;/* device vendor string */
+SANE_String model; /* device model name */
+SANE_String type; /* device type (e.g., "flatbed scanner") */
}
SANE_Device;
--020303030609050904070206--
[sane-devel] Question on SCSI Scanner in M$
The scanner seems to respond well at first and then it fails when the driver request the image data. It's possible the pkt passed to windows is invalid. Is your windows scsi driver up-to-date? The current logs are not enough to understand what's happening. Could you make a new trace with SANE_DEBUG_SANEI_SCSI set to 255 (as well as with SANE_DEBUG_MICROTEK2)? Frank.
[sane-devel] Error at translation
Mogens Jaeger wrote: > Hello > > When I in emacs runs the 'Validate' command, on the sane-backends da.po > file, I get the folloving error: > > cd ~/Oversaettelse/Sane-backends-1.0.15/ > msgfmt --statistics -c -v -o /dev/null > /home/mogens/Oversaettelse/Sane-backends-1.0.15/sane-backends.da.po > /home/mogens/Oversaettelse/Sane-backends-1.0.15/sane-backends.da.po:1268: > 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the > directive number 1, the character 'b' is not a valid conversion specifier. > > The message looks this way: > > #: .tmp/microtek2.h:697 > #, c-format > msgid "Balance factor for red. A value of 100% means no correction." > msgstr "Balancefaktor for roed. Vaerdien 100% betyder ingen korrektion." > > I have asked in my Language-Team, and one said that there should not be > a '#, c-format' up front??? > > I had 3 messages with errors like this, lines in da.po file : 1268 > (above), 1277 and 1268, all with the same errormessage. > It's a bug in the original string "...100% means". The "%" should be "%%". The source code must be updated. Frank.
[sane-devel] reverse engineering / usbsnoop
Mbosowo I Sampson wrote: > After reading reams of documentation, I think I have a grasp on how the > USB protocol works. I started snooping the usb traffic of my hp scanjet > 3970 so I can start writing the backend for it. I have a couple of > questions... > > With Snoopy Pro it seems to stop logging information once the actual > scan begins. Someone else posted something on SF page about it stopping > once the bulk transfer began. I was wondering if anyone knew how to get > around this. I tried sniffit, but the documentation says it only works > for NT 2000. sniffit is not a usb sniffer. Try http://benoit.papillault.free.fr/usbsnoop/ > > I was looking at a usb dump, > http://reapoff.sourceforge.net/hpscanner/full_scan.dump.gz > > posted by this guy, > http://reapoff.sourceforge.net/hpscanner/hp4470c.txt > > On this page he says that the chipset he was looking at had 244 > registers. How exactly can you tell that by the logs? May be because 243 is the highest register he saw? > I'm looking at the logs, and I'm not sure where to start. I was to start > simple by writing a stand alone application that tuns on the lamp, then > build on it from there. I have a session log, but I have no idea how to > find out what register and values are needed to turn on the lamp. Any tips? Are you sure your scanner has the same chipset than the 4470c? You need to get an idea of what your scanner is based on: - open it and get the chipset names - running "strings" on the windows drivers may yield some data - check the windows driver .INF You will have to get a usb trace for your scanner. Frank.
[sane-devel] Need help with reverse engineering Microtek Scanmaker 5600
Personnaly, I prefer sniff-usb (http://benoit.papillault.free.fr/usbsnoop/). IMO USBSnoopy Pro is a pita to use.
[sane-devel] tstbackend
Hi Jim, > 1. There is a check on the descriptor returned by sane_get_select_fd() > which always fails even when my backend has returned a valid small > integer file descriptor. The check is implemented like > "check(ERR,(fd <0), ..".I think it should be > "check(ERR,(fd>=0)," That's a tstbackend bug. Your backend seems to be the first tested one to support sane_get_select_fd. > > 2. In the scanning tests tstbackend starts a scan and then toggles > the state of the io_mode eventually leaving the fd in non-blocking > mode. It then attempts to do a 1 byte read. Due to being very slow > scanner, my DS3000 backend has no data ready on the first call to > sane_read() and therefore returns SANE_STATUS_GOOD and sets the length > to 0 as suggested by the SANE API doc.tstbackend thinks this is an > error and aborts the rest of the scan. I would expect that either > tstbackend should use the descriptor in blocking mode or should accept > return value of SANE_STATUS_GOOD with a returned length of 0 bytes? > Ditto with sane_set_io_mode. I'll fix that. Frank.
[sane-devel] FW: Other new info
Henning Meier-Geinitz wrote: > Hi, > > On Fri, Jul 23, 2004 at 12:56:29AM -0500, Frank Zago wrote: > >>Your scanner uses isochronous pipes to communicate. libusb does not yet >>support isochronous transfers. > > > Are you sure? I may be wrong but I think the iso endpoints in his logs > are from a completely different device. > > Bye, > Henning > Yes, you're right. I looked at the first email, and it didn't contain the scanner, so I assumed the one with iso pipes was the scanner. Looking more closely at the second shows the scaner is there. Unfortunately that doesn't change the fact that the chipset is not recognized :( Frank.
[sane-devel] FW: Other new info
Hi, > Humm... > I made some proofs ... I found several differences between my > sane-find-scanner -v -v executed in root or by my usual user > As you can see in the 2 outputs I have pasted you forward, when i > execute the command from my user the output gives an ipotethic chip for > the device, with no name of manufacturer or peripheral, instead, if I do > the command from root, he gives me the names of the different > peripherals, canon canoscan included, but he doesn't tell me anything > 'bout the chip. > Another try I did was to look into my hardware browser, installed in X, > and I found something else. It puts between the "system peripherals" a > peripheral which it calls "canon Canoscan", with an "unknown" tag at the > "driver" voice. > "canon Canoscan" is reported by the device itself, as most usb devices do. a cat /proc/bus/usb/devices will show you the same info. Same for "driver". Your scanner uses isochronous pipes to communicate. libusb does not yet support isochronous transfers. The old kernel driver didn't either (AFAIK). Conclusion: there is no driver yet for your scanner. Now if you're really brave, there is a patch for libusb floating around to support isochronous pipes. You can start a project to support your scanner. A few people have done that, so it's possible. Henning has written a few web pages on that subject. Sorry. Frank.
[sane-devel] [Canoscan5000f] news.
> Then, after, i think, some updates of the system (including SANE ?) I > got something else...a GL660 Chip is maybe present. > (See attached file found_thibault.txt) > The other genesys chipsets don't use isochronous endpoints. So I doubt your scanner is based any gl chipset.. Frank.
[sane-devel] Chinon DS-3000
>I have a > working linux interface program and propose to make a sane backend for > this scanner. Do you have the source? Is is a scsi or parallel scanner? Frank.
[sane-devel] hp3670
Mickael Profeta wrote: > Hi > > I did not give news since a long time, sorry but I had others things to > do... (find a job...) > > I try the genesys backend for this scanner, I attach the modifications > to make it recognise and the output of scanimage with debug, if it can > help... > > And YES! the motor moves, ok just 1 cm, but it is the first step ;) > > I put some logs of sane-find-scanner and scanimage here: > > http://www.alezan.org/hp3670/ > > scanimage.3670.gz and sane-find-scanner.3670.gz > > Cheers > Mike Applied. Frank.
[sane-devel] Umax Astra 4000U
Henning Meier-Geinitz wrote: > Hi, > > Please reply to the list and not only to me. May be someone with admin right could fix the reply-to: field of this mailing list? Frank.
[sane-devel] sane-sp15c and Fujitsu 620c: Help needed for plumbing backend to frontend
Garrick Sitongia wrote:
> The brightness and contrast levels are presently not supported by the=20
> sp15c backend. These are presently hardcoded at 128. But I was able to=20
> get it working in the hardware by adding "scanf" statements in sp15c.c.=
=20
> Scanimage stops and I can enter numbers for brightness and contrast eac=
h=20
> time I run scanimage.
>=20
> scanf("%d", &c);/* my code */
>=3D c;
> dev->threshold =3D 128;
> scanf("%d", &c);/* my code */
> dev->contrast =3D c;
>=20
> How instead do I pass these numbers to the backend from scanimage? Wher=
e=20
> scanimage would get them the usual way from command line args?
>=20
> Garrick
>=20
> _
> FREE pop-up blocking with the new MSN Toolbar =96 get it now!=20
> http://toolbar.msn.com/go/onm00200415ave/direct/01/
>=20
>=20
It seems that the backend has these options, but they are de-activated al=
most=20
all the time.
In sane_control_option(), see all the lines like
scanner->opt[OPT_BRIGHTNESS].cap =3D SANE_CAP_INACTIVE;
This tells the frontend not to offer the option.
You can change some to
scanner->opt[OPT_BRIGHTNESS].cap &=3D ~SANE_CAP_INACTIVE;
to activate them.
Then, if the option is active, use the value with
dev->brightness =3D scanner->val[OPT_BRIGHTNESS].w;
Hope that helps,
Frank.
[sane-devel] sane-sp15c and Fujitsu 620c ADF double-page feed
Garrick Sitongia wrote: > When I put many docs in the ADF, sane will scan the 1st, eject it, then > it will feed the next straight through without scanning it, scan the > 3rd, feed the 4th through, scan the 5th, etc. How do we get it to stop > scanning only every other document? > > I have done this: > > "export SANE_DEBUG_SP15C=25" > > then > > "scanimage --mode 8-bit --format=tiff --resolution 240 --y-resolution > 240 --source ADF --batch -y 270" > > It seems to eject the odd pages when doing a "sp15c_object_discharge". May be this particular scanner is doing it by itself. A shot in the dark: in sp15c_free_scanner(), remove the following lines: ret = sp15c_object_discharge (s); if (ret) return ret; recompile sane and try again. (I know nothing about that scanner, and I'm not the maintainer of that backend). Frank.
[sane-devel] hp2300c
Sanjay Chigurupati wrote: > Does that mean the Genesys backend is incomplete? > Well ... yes. But at least it's started. Frank.
[sane-devel] Question on Genesys backend
Sanjay Chigurupati wrote: > Hi, > > Please correct me if I am wrong. This is my understanding: > > 1) genesys.conf defines the vendor id and , (usb address ?) Yes. > 2) genesys_low.c is the low level implementation for the scanner with > genesys_low.c being the header file for it Yes. > 3) genesys.c is the high level implementation for the scanner with > genesys.h being the header for it. Yes. But this backend doesn't do much (see Henning's page for details). It cannot even do a full scan at any resolution. Frank.
[sane-devel] hp2300c
Sanjay Chigurupati wrote: > Does that mean HP 2400c and HP 2300c are supported by the latest cvs > version of Sane? > NO. sane-find-scanner might be able to tell whether this scanner is based on a gl646. There is no backend for that scanner. Frank.
[sane-devel] Segmentation Fault Encountered when Using FrontEnds with my Backend
> > > I am trying to develop an all-in-one driver for a > Lexmark X5150 AIO machine. The folks from Lexmark > hasn't developed a SANE backend for any of their > scanner yet that is why I am working on it. Setting > debug level to 128 still has the output of > segmentation fault. > The technique I use to develop new backends is to use scanimage, linked staticly only with my backend, and everything compiled with -g3. It doesn't take long to compile/link; I don't have to install anything and I know it's using the correct code. And if it crashes, I get a nice core I can analyze with gdb. Frank.
[sane-devel] On the 2300C chipset
Jason Anderson wrote: >> From what I have seen over the past few days, we may have actually found >> out which chipset the 2300C actually is. However, if it is the GL, what >> now? Is there code to access the chipset and to actually make the scanner >> respond? Well, sort of. I've started a backend for it: http://www.zago.net/sane/gl646/gl646.c http://www.zago.net/sane/gl646/gl646.h It does a couple checks and initializes the scanner. I expect to fill the blanks by looking at the doc and the logs. Right now, it looks like the driver gives the scan parameters by writing to the scanner DRAM. The format still looks like a pile of junk data, but eventually we'll get there. If you're interrested, hp2300_scanner_init() correspond to the urbs 5 to 24 when one plugs the scanner. Frank.
[sane-devel] hp2300c
> > So can sane-find-scanner really talkt to the scanner after that > change? Can I see the output of sane-find-scanner -v -v after the > change, please? > > Bye, > Henning > Yes, it can. Looking at the usb traces, it looks like it is very close, if not identical, to a gl646. The registers used are the same, and the method to access them is very similar to that of the gl640. It seems there is at least 3 hp usb scanners (3670, 3690, 2400) that have a close chip. I'm only sure about the 3670 since that's the only one I found usb traces. Is it possible you set up a cvs tree for backends development (not specific to a particular backend) and a mailing list for people interrested in the GL scanner-on-chip dev? I don't want to use SF, and it would be better on alioth anyway. If you don't mind, I'd also like to see what code you have written for the gl646. Frank. searching for SCSI scanners: checking /dev/scanner... failed to open (Invalid argument) checking /dev/sg0... failed to open (Invalid argument) checking /dev/sg1... failed to open (Invalid argument) checking /dev/sg2... failed to open (Invalid argument) checking /dev/sg3... failed to open (Invalid argument) checking /dev/sg4... failed to open (Invalid argument) checking /dev/sg5... failed to open (Invalid argument) checking /dev/sg6... failed to open (Invalid argument) checking /dev/sg7... failed to open (Invalid argument) checking /dev/sg8... failed to open (Invalid argument) checking /dev/sg9... failed to open (Invalid argument) checking /dev/sga... failed to open (Invalid argument) checking /dev/sgb... failed to open (Invalid argument) checking /dev/sgc... failed to open (Invalid argument) checking /dev/sgd... failed to open (Invalid argument) checking /dev/sge... failed to open (Invalid argument) checking /dev/sgf... failed to open (Invalid argument) checking /dev/sgg... failed to open (Invalid argument) checking /dev/sgh... failed to open (Invalid argument) checking /dev/sgi... failed to open (Invalid argument) checking /dev/sgj... failed to open (Invalid argument) checking /dev/sgk... failed to open (Invalid argument) checking /dev/sgl... failed to open (Invalid argument) checking /dev/sgm... failed to open (Invalid argument) checking /dev/sgn... failed to open (Invalid argument) checking /dev/sgo... failed to open (Invalid argument) checking /dev/sgp... failed to open (Invalid argument) checking /dev/sgq... failed to open (Invalid argument) checking /dev/sgr... failed to open (Invalid argument) checking /dev/sgs... failed to open (Invalid argument) checking /dev/sgt... failed to open (Invalid argument) checking /dev/sgu... failed to open (Invalid argument) checking /dev/sgv... failed to open (Invalid argument) checking /dev/sgw... failed to open (Invalid argument) checking /dev/sgx... failed to open (Invalid argument) checking /dev/sgy... failed to open (Invalid argument) checking /dev/sgz... failed to open (Invalid argument) # No SCSI scanners found. If you expected something different, make sure that # you have loaded a SCSI driver for your SCSI adapter. # Also you need support for SCSI Generic (sg) in your operating system. # If using Linux, try "modprobe sg". searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid argument) checking /dev/usb/scanner0... failed to open (Invalid argument) checking /dev/usb/scanner1... failed to open (Invalid argument) checking /dev/usb/scanner2... failed to open (Invalid argument) checking /dev/usb/scanner3... failed to open (Invalid argument) checking /dev/usb/scanner4... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner5... failed to open (Invalid argument) checking /dev/usb/scanner7... failed to open (Invalid argument) checking /dev/usb/scanner8... failed to open (Invalid argument) checking /dev/usb/scanner9... failed to open (Invalid argument) checking /dev/usb/scanner10... failed to open (Invalid argument) checking /dev/usb/scanner11... failed to open (Invalid argument) checking /dev/usb/scanner12... failed to open (Invalid argument) checking /dev/usb/scanner13... failed to open (Invalid argument) checking /dev/usb/scanner14... failed to open (Invalid argument) checking /dev/usb/scanner15... failed to open (Invalid argument) checking /dev/usbscanner... failed to open (Invalid argument) checking /dev/usbscanner0... failed to open (Invalid argument) checking /dev/usbscanner1... failed to open (Invalid argument) checking /dev/usbscanner2... failed to open (Invalid argument) checking /dev/usbscanner3... failed to open (Invalid argument) checking /dev/usbscanner4... failed to open (Invalid argument) checking /dev/usbscanner5... failed to open (Invalid argument) checking /dev/usbscanner6... failed to open (Invalid argument) checking /dev/usbscanner7... failed to open (Invalid argument) checking /dev/usbscanner8... failed to open (Invalid argument) checking /dev/usbscanner9... fa
[sane-devel] hp2300c
Hi,
I just bought a el cheapo hp2300c scanner since there is no SANE drivers.
I looked at the windows driver, and found the "GL646U" strings. Same as the hp
3690 it seems.
So I ran "sane-find-scanner -v -v -v" and it didn't detect that chipset.
However, after making a few subtle changes to check-usb-chip.c,
sane-find-scanner actually detects a GL646. See diff:
--- check-usb-chip.c29 Dec 2003 16:32:30 - 1.7
+++ check-usb-chip.c26 Feb 2004 02:28:25 -
@@ -1043,8 +1043,8 @@ check_gl646 (struct usb_device *dev)
printf ("checking for GL646 ...\n");
/* Check device descriptor */
- if ((dev->descriptor.bDeviceClass != USB_CLASS_PER_INTERFACE)
- || (dev->config[0].interface[0].altsetting[0].bInterfaceClass != 0x10))
+ if ((dev->descriptor.bDeviceClass != 0xff)
+ || (dev->config[0].interface[0].altsetting[0].bInterfaceClass != 0xff))
{
if (verbose > 2)
printf
@@ -1060,14 +1060,14 @@ check_gl646 (struct usb_device *dev)
dev->descriptor.bcdUSB);
return 0;
}
- if (dev->descriptor.bDeviceSubClass != 0x00)
+ if (dev->descriptor.bDeviceSubClass != 0xff)
{
if (verbose > 2)
printf ("this is not a GL646 (bDeviceSubClass = 0x%x)\n",
dev->descriptor.bDeviceSubClass);
return 0;
}
- if (dev->descriptor.bDeviceProtocol != 0)
+ if (dev->descriptor.bDeviceProtocol != 0xff)
{
if (verbose > 2)
printf ("this is not a GL646 (bDeviceProtocol = 0x%x)\n",
This change looks legitimate to me and the scanner really has a GL646 inside.
Frank.
[sane-devel] Question about VISIONEER 8100 USB scanner
Sharpe, Richard wrote: > Hi > > I was wondering if anyone has gotten the Visioneer 8100 USB scanner > to work using SANE ? I have attempted but failed on all attempts. If > some can point me in the right direction or knows of a solution I would > appreciate it very much. > > Thanks AFAIK it is not supported under sane. It might be supported by the viceo backend, though. Alternatively, you could post the output of "cat /proc/bus/usb/devices" to the list. It might be a rebadged scanner. Frank.
[sane-devel] sane homepage
Alas, it didn't take long for sane-project.org to go off the air :)
[sane-devel] windows port of sane
Henning Meier-Geinitz wrote: > > +sane-backends will not compile out of the box. You need to follow the > following steps: > + > +- edit configure.in and put all the AC_CONFIG_FILES entry in one line. > > Would it help to use AC_CONFIG_FILES three times? I don't know. > > + edit acinclude.m4 and remove everything from libtool (about 170kb) > > That's because the libtool that comes with cygwin is newer (or just > different)? I don't know either. I had a lot of trouble with that file and everything started working once I removed it. They seem to be from the same version of libtool though. > > +- edit backend/Makefile.in, and add "-no-undefined" before the > "-version-info" parameter (twice). > > What about checking for windows in configure.in and setting the > variable @NO_UNDEFINED@ based on that check and calling libtool with > that variable in the Makefile? I was thinking about adding a @LIBTOOL_EXTRA_FLAGS@ field for that. > > --- sane-backends-1.0.12.org/backend/Makefile.in2003-05-13 > 04:39:50.0 -0500 > +++ sane-backends-1.0.12/backend/Makefile.in2003-09-21 21:19:38.0 > -0500 > @@ -155,7 +155,7 @@ > > libsane-%.la: %.lo %-s.lo $(EXTRA) $(LIBOBJS) > @$(LIBTOOL) $(MLINK) $(CC) -export-dynamic -o $@ $($*_LIBS) \ > - $(LDFLAGS) $(BACKENDLIBS) $^ -rpath $(libsanedir) \ > + $(LDFLAGS) $(BACKENDLIBS) $^ -rpath $(libsanedir) -no-undefined \ > -version-info $(V_MAJOR):$(V_REV):$(V_MINOR) $(DYNAMIC_FLAG) > > Can "-no-undefined" be harmful on other platforms? I've read the docs > but it looks like I don't really understand what it does :-/ Neither do I. It just doesn't work with it :) > > Otherwise I haven't found anything that may harm non-Windows system so > it's ok for me. I haven't applied the patch, however. > > Could you add some lines to to README.windows about "only SCSI > supported"? README and Makefile.in must be updated, too. Why Makefile.in? Frank.
[sane-devel] windows port of sane
I've updated my port of sane to windows. It works fine with 2 of my scsi scanners. I'd like to integrate it. Can someone review the code? http://www.zago.net/sane/windows/sane_on_windows.html Frank.
[sane-devel] Planar & Chunky
Guy Brooker wrote: > A front end question ! > > As far as I understand from the SANE spec, a backend may send colour image > data as either an R, G & B sample per pixel, what TWAIN refers to as chunky, > or as three separate images, one of R, one of G and one of B, what TWAIN > refers to as planar. > > Is there any way of forcing a backend to go one way or another ? No. It depends on how the backend has been coded; which itself depends on how the scanner returns the data. > And secondly, is there any way of determining if the data will be planar or > chunky before calling sane_start() ? I don't think so. It seems that all recent backends do only one pass, so you might get away with not coding for 3 passes backends. Frank.
[sane-devel] SANE2 (was Re: Scanning negatives with Epson Perferction 1260 Photo)
Major A wrote: >>It seems to me that if nothing happens on the SANE2 front (eg development), >>SANE2 will stay a mirage. A well documented illusion. >>A lot of people have given some input, but if the proposal isn't >>implemented, why care? > > > Good point, Frank. The bad thing is that SANE1 and SANE2 are mostly > incompatible, so it's currently quite difficult to write a SANE2 > frontend because there no suitable backends, and vice versa. scanimage can be used as the reference frontend. It's only 2000 lines, so it's easy to adapt. > It just occurred to me that we could make a shortcut: create a > metabackend that converts from SANE1 to SANE2, and one for the other > way round. All that would be needed is an appropriate directory > structure in CVS, and we could have SANE1 and SANE2 running > concurrently. A converter from sane1 to sane2 might be good for unmaintained backends. A converter from sane2 to sane1 would be a waste of effort IMHO, and not a good incentive to convert backends. > > I might have some time in a couple of weeks, so maybe I'll have a > closer look at SANE2 to find out how the conversion can be done. > > This is an RFC. > > Andras > Frank.
[sane-devel] SANE2 (was Re: Scanning negatives with Epson Perferction 1260 Photo)
Jonathan Buzzard wrote: > henn...@meier-geinitz.de said: > > [SNIP] > > >>I've asked multiple times for concrete proposals how the standard can >>be changed or appended. Each time there hasn't been any response. With >>"concrete proposals" I mean patches to SANE2 or at least the text of >>the to-be-added well-known options. >> >>If I remember correctly, we came to the conclusion that most proposed >>features can be done by adding well-known options (like multi-pass, >>selection of a specific range of images, auto/manual focus) and >>providing the functionality in the backend. So please send proposals. > > > I did sit down and make a long list of things that I thought where missing > from the SANE API for negative scanning and posted it to this list. I am > not sufficiently familiar with the SANE API to be qualified to make > good proposals on how it should be extended, and it would take significant > amounts of my time that I don't have to do so. > > It seems to me a far superior solution for those that know what is missing > from the standard to point out what is missing and for those that have > intimate knowledge of the standard to add those features in the way that > best fits in with the standard. It seems to me that if nothing happens on the SANE2 front (eg development), SANE2 will stay a mirage. A well documented illusion. A lot of people have given some input, but if the proposal isn't implemented, why care? Bigger projects like the linux kernel are changing everyday. Code gets in, code gets throwned out, the APIs change and break, but at the end of the day, there is something. The SANE2 framework is enough to get started. Frank. (this was not a rant, just a observation).
[sane-devel] UMAX Astra 2200 USB weirdness (Repost)
Oliver Rauch wrote: > Disable qualtiy calibration > > Oliver > Olivier, could the backend avoid using this command for the umax 2200, since the scanner does not support it (even in scsi)? I don't have access to that scanner anymore, so I cannot test. Frank.
[sane-devel] sane-backends effectively GPL'd in disguise?
Hi Olaf, IANAL but I'll try to answer anyway. None of these contain code. Just prototype and APIs. I don't think that the omission of the SANE exception would propagate to the rest of the code. Besides the README states that the backends are under GPL+exception. It is also quite clear that the authors of these files didn't intend to put these files under GPL only since they were written specifically for SANE. The files should be fixed though. Frank. Olaf Meeuwissen wrote: > Dear all, > > I have been upgrading "Image Scan! for Linux" to use SANE internals from > sane-backends-1.0.12. Ever since the FSF slapped us on the wrist for an > unintentional violation of the GPL, we have a little allergic to license > issues so I combed through the include/, lib/ and sanei/ directories for > license problems. > > The following files in include/ and sanei/ are GPL'd *without* the SANE > exception: > > include/lalloca.h > include/lassert.h > include/sane/sanei.h > include/sane/sanei_codec_ascii.h > include/sane/sanei_codec_bin.h > include/sane/sanei_scsi.h > include/sane/sanei_thread.h > include/sane/sanei_usb.h > include/sane/sanei_wire.h > include/sane/saneopts.h > sanei/linux_sg3_err.h > > Even though I have read the GPL twenty+ times over, I am still not sure > whether this means that files including any of these would effectively > void their SANE exception (assuming they have one). After all the SANE > exception explicitly states: > > This exception does not, however, invalidate any other reasons why > the executable file might be covered by the GNU General Public > License. > > Ergo, files like sanei/sanei_scsi.c and sanei/sanei_usb.c, which include > their counterpart header files, might in effect be released under the > GPL and the GPL only without any SANE exception. The same logic applies > to backends including files from the above list. > > The TODO notes that the getopt*.c and md5.c files have been checked for > (and replaced by LGPL'd versions) precisely the reasons cited above. > > Could anyone shed any light on this?
[sane-devel] detect the correct scanner
Hi Foffy_69, Assuming your scanner works, why do you care? Another solution to your problem would be to print a Plustek sticker and put it on top of the Genius logo. :) Frank. Foffy wrote: > i have a genius color page vivid-III but when mandrake > detect it as a plustek, that has the same chip. Is > this important or not? and how i can get it detected > as genius color page vivid-III. > >
[sane-devel] Compiling SANE backends on Mac OS X 10.1.5
I'm not an OSX user, but it seems this (sick pice of) code needs to be compiled with a C++ compiler, or at least a C compiler with non-standard extensions. You can try CC=g++ ./configure and recompile. Frank. David Alan Hjelle wrote: > Hello. > > I've been trying to get my Microtek SlimScan C6 cheap-o scanner to work > under Mac OS X for a while now, and just recently ran across SANE. I > figure I should be able to use SANE with the GIMP, which I use somewhat > regularly. > > I was trying to compile the lastest CVS snapshot (from June 2, 2003) of > SANE backends, but I ran into some problems. > > ./configure ran no problem. > > make, however, eventually gave me the following errors (Or, at least, > these are the errors deaing with the sanei_scsi.c file that seemed to > be the cause for the compilation problem. I think everything else was > just warnings. Of course, what do I know? I'm only just teaching myself > C programming and have only had experience in VB and Java .): >
[sane-devel] translation question
Hi Andras, Major A wrote: > As if I didn't have enough work already... now I came up with the idea > of creating a new translation for the SANE backends. I read the README > in the po directory and found a .po file for each language. Now a few > questions: > > - Are the comments in the .po file that tell where a string is used > (file, line) automatically generated, and if yes, how? If no, are > they really necessary? (I would hate to have to update the file > every time a backend changes.) Yes, they are. The GNU tools (xgettext, msgfmt and msgmerge) take care of the details. You just have to translate from english and forget about the rest. > > - What happens if a string isn't found in a language? Does gettext > just use the original version hardcoded into the backend? Yes. So you can do the translation bit by bit, since it's a tedious process. Frank.
[sane-devel] sane backends port to windows
Hi, I've started a port of the sane backends to windows. It's rather limited right now, but I can use one of my scsi scanner under the cygwin environment. Infos and patch at my temporary site: http://home.austin.rr.com/fzago/sane/windows/sane_on_windows.html Frank.
[sane-devel] Q: Recommendation on ADF scanners?
A Panasonic kv-ss25 or ss25d can scan about 20 to 25 A4 page per minutes. They retail new for about $2K to $4K, but you can find some used on ebay for less than $400. I don't know how often they need maintenance, though. Both scanners are supported by SANE. Note that the scan speed is for a batch job. A page per page scan speed will be about 5 ppm. Frank. Mattias K wrote: > I need some recommendations about which scanner to buy. > > I need a fast A4 scanner with ADF. Scan speed around 30 ppm. Black/white > or grayscale. I need it to scan waybills (around 500 per day). No high > quality requirements; quality has to be only slightly better than faxed > documents... > > Price should be no more than USD 4000. > > Any ideas? Which scanner should i choose?? > > Thanks in advance. > > /Mattias > > _ > Fynda på nätet! Handla på MSN Shopping http://www.msn.se/shopping > > ___ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel >
[sane-devel] Last call for new backends
Henning Meier-Geinitz wrote: > Hi, > > if you intend to get a new backend into SANE 1.0.12 it's now time to > tell us. Currently there are two backends on the TODO list: > > - Hewlett-Packard 4200c > [...] > http://fz.eryx.net/sane/#hp4200 > > What's the status of those? Are there any others that are intended to > go in 1.0.12 (or later versions)? Last time I tested my version (http://fz.eryx.net/sane/#hp4200), it worked. However I don't have access to that scanner anymore, so I won't push for its inclusion. Frank.
[sane-devel] Spot Dynotak 6p
Spot's been long dead. AFAIK there is no sane driver, not even a started one, and very little chance to see one one day. Frank. Libbi wrote: > Hi, > > the list of the supported scanners doesn't contain "Spot Dynotak 6p". > There doesnt exist any win xp-dirver, so i hoped to get it working using > linux. But the scanner seems not to be supported, too. > Is it possible to use the scanner anyway? Or will the scanner be > supported in the near future? > Thanks for your help, > Libbi >
[sane-devel] lost with FUJITSU scanner M3096G
> > I've tried it with RedHat 8.0 linux. The sense bytes 16 and 17 really > point to the offending byte (I've tried to set a invalid resolution > an others). There is a 8 byte window header you can't > see in the hexdump above. The offending byte is at position 25 (0x02). > This means 'grayscale monochrome'. Dirks M3096G doesn't seem to support > grayscale (probably that firmware bug?). > > Or it support grayscale, but not with a 8 bits depth. What about 4? See set_WD_bitsperpixel in setWindowParam(). Frank
[sane-devel] lost with FUJITSU scanner M3096G
abel deuring wrote: > Frank Zago wrote: > >>>[fujitsu] set_window_param >>>[fujitsu] Window set >>>[fujitsu] 000: 00 00 01 2c 01 2c 00 00 00 00 00 00 00 00 00 00 >>>[fujitsu] 016: 03 b0 00 00 05 89 00 00 00 02 08 00 00 00 00 00 >>>[fujitsu] 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0 >>>[fujitsu] 048: 20 00 00 00 00 84 00 00 00 00 00 00 00 00 00 00 >>>[fujitsu] 5/38/0: Invalid field in parm list >>>[fujitsu] sanei_scsi_cmd: returning 0x0004 >>>[fujitsu] sane_start: ERROR: failed to set window >> >>The scanner rejected the window parameter. If the scsi implementation is >>decent, >>the sense might contain the offset of the offending byte somewhere around byte >>16 oy 17. To get that, at the beginning of scsi_sense_handler, add this line: >> >> hexdump (MSG_IO, "Sense", sensed_data, sensed_data[7]+8); > > > Frank, > > you're right, the sense bytes 16 and 17 should point to the offending > byte, but unfortunately the Linux SCSI system returns only the first 16 > bytes of a SCSI command. Are you sure of that? There are devices out there that return more than 100 bytes of data in the sense. I assume someone would have fixed such a problem. > But it might help to issue a REQUEST SENSE manually after the failing > SET WINDOW and print the result of this command. Unless the system caches the sense (and more than 16 bytes), the next request sense isn't going to return anything. Frank.
[sane-devel] lost with FUJITSU scanner M3096G
> [fujitsu] set_window_param > [fujitsu] Window set > [fujitsu] 000: 00 00 01 2c 01 2c 00 00 00 00 00 00 00 00 00 00 > [fujitsu] 016: 03 b0 00 00 05 89 00 00 00 02 08 00 00 00 00 00 > [fujitsu] 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0 > [fujitsu] 048: 20 00 00 00 00 84 00 00 00 00 00 00 00 00 00 00 > [fujitsu] 5/38/0: Invalid field in parm list > [fujitsu] sanei_scsi_cmd: returning 0x0004 > [fujitsu] sane_start: ERROR: failed to set window The scanner rejected the window parameter. If the scsi implementation is decent, the sense might contain the offset of the offending byte somewhere around byte 16 oy 17. To get that, at the beginning of scsi_sense_handler, add this line: hexdump (MSG_IO, "Sense", sensed_data, sensed_data[7]+8); Frank.
[sane-devel] USB for Umax Astra 2200 SU
> > > Frank, > thanks for the quick reply. With having "quality calibration" switched off, > it wokrs fine now. > > Is then there any loss in quality compared to SCSI with "quality calibration" > switched on? > I don't think so. The command to set the qualibration level fails on both usb and scsi (command not supported). The difference is that the backend knows how to handle bad news from the scanner when accessed with scsi but not with usb. A proper fix would be to disable that command for that scanner, but I don't have access to it anymore. Frank.
[sane-devel] USB for Umax Astra 2200 SU
Klaus Dahlke wrote: > Hi all, > > I have a problem with my Umax Astra 2200 SU (it has both connectors, SCSI and > USB). SCSI and USB works fine with Win98 (i.e., hardware is okay), SCSI works > also under Linux (for various reasons I am thinking of switching to USB). > When attached to USB, scanner is detected by xscanimage on either > /dev/usbscanner or /dev/usb/scanner0. I can nicely do a preview or multiple > previews. But when I want to do the actual scan, the scanner starts with some > action (about a second or so) and then do nothing. The output from strace is > continuously producing: > Hi Klaus, Have you disabled "quality calibration" option? If not, do it and try again. Frank.
[sane-devel] Sane and gsc-1.1 on AIX 4.3.3-ml10
Hi Stephen, Can you enable the tracing, as described in the readme file, and send me the output? Since you're using aix 4.3.3, you can try using the original gsc (version 1.0). Frank. Stephen Hegarty wrote: >Hi All, > Anyone using AIX?? > > I am trying to use sane on AIX 4.3.3 (RS/6000) but > to do this, sane requires generic scsi drivers: > http://fz.eryx.net/aix/gsc-1.1.tar.gz. I have built > this using gcc 3.2.1 and GNU make. > >However, `lsdev -Cc generic` returns - > gsc0 Available 10-60-00-1,0 Feral Software Generic > SCSI Release 1.1 > >But, `./tstinq /dev/gsc0` returns - > GSC_CMD: I/O error > >This results in `sane-find-scanner` returning - > # No SCSI scanners found. > >Has anyone sucessfully run Sane or GSC on an AIX > 4.3.3 system? AIX has no native scanner support and > IBM UK UNIX support team have not been helpful. Any > help would be appreciated. > > Regards, > Stephen. > > __ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > ___ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel >
[sane-devel] no scanners found (leo s3 scsi-scanner)
axel dammers wrote: > Hi, > > thanks for your tip. > > I compiled it without the spaces in leo.c and the scanner runs !!! > > Very much thanks for your good help. :-)) > > Bye, > Axel > > Thanks for the report. Frank.
[sane-devel] no scanners found (leo s3 scsi-scanner)
Hi,
I've added an entry in the backend for this variant. You might as well wait for
sane 1.10.
But if you're in a hurry, remove the spaces and recompile sane.
eg change
{6, "LEO ", "LEOScan-S3 ",
to
{6, "LEO", "LEOScan-S3",
Regards,
Frank.
Henning Meier-Geinitz wrote:
> Hi,
>
> On Thu, Jan 16, 2003 at 11:01:54PM +0100, axel dammers wrote:
>
>>But sane-find-scanner -v -v shows not a 0 behind the scanner name:
>
>
> Yes, it does:
>
>
>>searching for SCSI scanners:
>>checking /dev/scanner... open ok
>> Inquiry for device:
>> 000: 06 00 02 02 1f 00 00 00 4c 45 4f 00 00 00 00 00LEO.
>> 016: 4c 45 4f 53 63 61 6e 2d 53 33 00 00 00 00 00 00LEOScan-S3..
>
>
>
> There are the 00 00 ... after the text. The backend expects spaces (32
> = 0x20).
>
>
>>Have I to do anything in the sourcecode ?
>
>
> Try it. Remove the spaces as I mentioned.
>
> Bye,
> Henning
> ___
> Sane-devel mailing list
> sane-de...@www.mostang.com
> http://www.mostang.com/mailman/listinfo/sane-devel
>
[sane-devel] no scanners found (leo s3 scsi-scanner)
Henning Meier-Geinitz wrote:
> Hi,
>
> On Wed, Jan 15, 2003 at 09:59:03PM +0100, axel dammers wrote:
>
>>It's right, the name of the scanner is LEO LEOScan-S3.
>>
>>Here are the output of "SANE_DEBUG_LEO=255 scanimage -L":
>>
>>[sanei_debug] Setting debug level of leo to 255.
>>[leo] sane_init
>>[leo] This is sane-leo version 1.0-9
>>[leo] (C) 2002 by Frank Zago
>>[leo] attach_scanner: /dev/sg0
>>[leo] leo_init: enter
>>[leo] leo_init: exit
>>[leo] attach_scanner: opening /dev/sg0
>>[leo] leo_identify_scanner: enter
>>[leo] device is "LEO" "LEOScan-S3" "1.10"
>>[leo] leo_identify_scanner: exit, device not supported
>
>
> Looks like a detection problem. I don't know anything about the leo
> backend, but here is part of the source code (backend/leo.c):
>
> static const struct scanners_supported scanners[] = {
> {6, "ACROSS ", "",
>"Across", "FS-1130"},
> {6, "LEO ", "LEOScan-S3 ",
>"Leo", "S3"}
> };
>
> So the backend expects spaces after the names but the SCSI inqiry
> seems to put a 0 after the names (?).
>
> You can verify that by running sane-find-scanner -v -v and looking at
> the SCSI inqiry. If there is a 0 after the names, that's the problem.
>
> You can try to modify the source code by removing the spaces after LEO
> and LEOScan-S3 to find out,i ft this is the problem.
Yes. That seems to be the problem. I have some scsi traces for that scanner,
and
there is spaces after the names. However the firmware version is not the same
(3.01 instead of 1.10 here).
I that fixes your issue, I'll add an entry for it before the next release of
SANE.
Frank.
[sane-devel] "hp4200" driver patch for SANE 1.0.9
Julien BLACHE wrote: > Till Kamppeter wrote: > > >>I didn't test whether the driver is actually working with SANE 1.0.9, >>as I don't have the appropriate scanner. But the patch works and after >>compiling SANE the "hp4200" backend is there. > > > I included the backend in the libsane-extras Debian package, and I've > got a few (one or two) success reports with it. Since then, SANE 1.0.9 > made its way into the Debian archive and nobody complained, > so... either it "works"[*] or nobody uses it :) > > Frank Zago said on October 30th that he was working on the backend, > but nothing else has happened since then. Any news ? > > JB. > > [*] IIRC the backend only supports a few features > Hi Julien, I've posted my changes at http://fz.eryx.net/sane/#hp4200 I'll try to borrow that scanner again to finish testing the backend. When it's ready, I'll submit it for inclusion. Frank.
[sane-devel] Looking for docs. Net sane?
Hi David, There a link for that on the sane documentation page: http://mostang.com/sane/docs.html To acces your scanner from windows, check SaneTwain. http://mostang.com/sane/sane-frontends.html Frank. David Hostetler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I have heard that you can set up SANE on a Linux / BSD / Solaris box and > share > it to any of the machines on a network. I am looking for docs on how to do > this, and how to be able to access it from Windows, and Linux clients. I have > one scanner and three PCs that need to access it. One of the PCs is my wife's > Windows 2000 PC. Am I on the right track and can you suggest what docs to > read for doing this? Thanks... > > - -- > David B. Hostetler > First Line Computer Systems > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE98SsBUpT27+K2BFURAjgzAJwOwYC3UlOeXZXO9sSAQrHloIYUNQCg1VN2 > kw3swgR9rRPPhpvjrB9GI6c= > =AVII > -END PGP SIGNATURE- > > ___ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel >
[sane-devel] SANE i18n: only one translation file per language?
> > Opinions? Other advantages/disadvantages? > It looks good. Another advantage is that might help harmonize the terminology used in various backends (eg "Color" vs "Colour".) Frank.
[sane-devel] sane+ocr+barcodes
David, I was merely telling you that you might have a better answer on a clara mailing list, since clara supports barcodes. The only other free ocr I know is gocr (jocr.sf.net). However I don't know if it supports barcodes. Frank. David Anders wrote: > Frank, > > sane web site states: > > Since this is currently the only mailing list devoted to SANE, it's > perfectly OK to ask questions that are not strictly related to SANE > development. For example, nobody will jump at your throat if you were to > ask for recommendations as to what scanners work best with SANE. > > just figured some could recomend the best barcode-ocr to work with SANE. > > thanks > dave >
[sane-devel] sane+ocr+barcodes
Hi David You'd rather try asking that question on the clara mailing list, since you don't seem to have a problem with scanning. Regards, Frank. > > anyone out there doing barcode ocr? i'm currently using Clara to do some > ocr testing however i've been unable to find any documentation on do > ocr for barcodes. any help would be appreciated! >
[sane-devel] Individual Resolution for X and Y
... > So please implement individula resolution in all the backends if it allows. ... Just trollin'
[sane-devel] USB scanner paper
Hi Karl, In at least 3 places, replace "your" by "your're" or "you are". And most of the new distribution support hotplug, so it shouldnt be necessary to insmod or modprobe the scanner driver. The parameters to the scanner (if necessary) can be written into /etc/modules.conf. Except that, your document looks fine to me. Regards, Frank.
[sane-devel] HP4400c Scanjet
Chris wrote: > I'm determined, if possible, to get this scanner to work with linux. Has > anyone had any luck. I have it connected to my usb port and running kde's > usb viewer finds it. I have the current version of SANE installed, 1.0.9, > however running sane-find-scanner results in nothing. Being a newbie still > of sorts I'm kind of unsure what to try next. > Hi Chris, AFAIK, there is no SANE backend for that scanner, not even in alpha version. According to http://www.mostang.com/pipermail/sane-devel/2002-February/001850.html it is possible you have a scanner compatible with a umax 1200 or 2000. If you are that determined, you could get some usb traces of a very small scan under windows with SnoopyPro and post them to a web site. Maybe someone will recognize some patterns. SnoopyPro is at http://sourceforge.net/projects/usbsnoop/ Frank.
[sane-devel] Umax Astra 2200(U? SU?)
kw...@earthlink.net wrote: > this is what i suspected, and i do have the model with both usb and scsi, > but so far no luck in getting it to work. i think i am having a problem > with the kernel modules. it is the smp kernel from redhat 7.2 (2.4.7). 2.4.7 is way too old. See http://fz.eryx.net/sane Frank.
[sane-devel] Umax Astra 2200(U? SU?)
kw...@earthlink.net wrote: > http://panda.mostang.com/sane/sane-mfgs.html shows 3 entries for the astra > 2200, SU, both scsi and usb are listed as supported while the U is listed > as unsupported. does anyone know what the SU and U mean? my astra is > labeled just 2200 and im not sure if its supported or not. > thanks > wade richardson > AFAIK, it's incorrectly named. The name is just Umax 2200. It has both a scsi and a usb connection. And either one is supported by sane. Frank.
[sane-devel] hp4200c backend
Hi Oliver, > when the backend defines the resolution as list and not as range > and the user can NOT select grayscale/lineart then I think it is > ok to commit it after one other person did take a look at it. Yes, that's what it's doing. I will submit a patch soon. > - preview - does meand preview + real scan does work, correct? Yes. The original backend didn't have a preview mode, so I added it. Frank.
[sane-devel] Best Java programming API library available
Hi Sony, > Today as the Architect of the project I just succeeded in getting the > management to accept using SANE for our project. > I have been reading some literature and compiling the RPMs available. I > have some questions. Pl accept my apologies if this is not the right > place to ask these questions ( I will be very grateful if you could > point me to teh right place in that case ) > > 1. What is the licensing terms for SANE. Is it OK to use it for our > project ( Its not a product sold outside. But a software used in our > company ) SANE is released under GPL plus an exception. But basically if your product doesn't go outside your company, you can do whatever you want and you don't have to give your changes back. However giving some changes or new backend/frontend would be appreciated. > 2. I was reading that SANE is actually a standard that neatly helps to > abstract teh driver-specifics, away from teh user programs like GUI etc. > Is it this standard that is GPLd ( I didn t know specifications can be > GPLd. I thought only software can be GPLd ) Anyone can implement and use the SANE API. It is not protected (it's an API). > 3.Though I read SANE is a standard, I was also reading about ( like teh > RPM I downloaded from rpmfind.net ) SANE as a product. Are there more > than one implementation of that standard. Was I reading about one > particular ( maybe most popular - or even the only one ) implementation. SANE is not really a product. It's more like a set of functionnalities (core libraries, backends, frontends) that understand the SANE API. AFAIK there's only one public implementation and you've got it. > 4. Our project is in Java with remote scanning requirement ( This was my > main argument against TWAIN ). Though I was reading about some > discussions on Java APIs in this group ( also on Issue 47 of old > linuxjournal ), I couldn t come across a downloadable java library for > sane. Is there one that is the most popular Java implementation. There is an old java interface in the sane-backend package (directory japi). However it's not been maintained sine august 1999. > 7. In a remote scanning setup using Java on the client side, can the > server ( saned ) be in C. Or is there an equivalent jsaned. saned is written in C. But anything can connect to it, including some frontend written in java. > 8. Finally has teh on-the-wire protocol for sane been implemented/mapped > to Java. IOW if I have a Java client, can my client process completely > in Java ( bottommost layer in java talks this protocol, that is then > sent over the wire with Java sockets APIs - So its Java all the way ) Yes, but you may have to write the layer that talks to saned. Hope that helps, Frank.
[sane-devel] [ANN] Viceo 0.6 driver release for SANE 1.0.9
> Also need to look at the memory leaks and fix up some
> gamma problems. Ho Hum
>
Hi Steve,
To find the memleaks, you can do that:
- compile only your backend into the static library ("./configure
--enable-static" and edit backend/Makefile)
- use valgrind against scanimage and/or tstbackend
(http://devel-home.kde.org/~sewardj/)
That works great.
Frank.
[sane-devel] hp4200c backend
Hi, I've been loaned a hp4200c for some time. So I cleaned up the apparently orphaned backend. Right now the backend does: - preview - 75, 150, 300, 600dpi in color mode - gamma and that's it! No black&white, no grayscale, no more resolutions. I'm not going to add more time into it. It does not much, but it works well. I was wondering if that's enough to submit it. Comments? Frank.
[sane-devel] losing hair and sleep over this
noah wrote: > scanners don't work on my system!!! > i've tried three scanners. two of which were admittedly unsupported, but the > third of which is supposedly fully supported by sane. > they were all usb. > this last one is an epson perfection 640u. here's what happens: > i plug in the scanner. > quoth /var/log/messages: > Oct 28 22:36:49 cobaltdhcpb60 /sbin/hotplug: arguments (usb) env > (DEVFS=/proc/bus/usb OLDPWD=/ PATH=/bin:/sbin:/usr/sbin:/usr/bin > ACTION=remove PWD=/etc/hotplug SHLVL=1 HOME=/ DEVICE=/proc/bus/usb/002/006 > PRODUCT=4b8/10c/1 TYPE=255/0/255 DEBUG=kernel _=/bin/env) > Oct 28 22:36:49 cobaltdhcpb60 /sbin/hotplug: invoke /etc/hotplug/usb.agent () > Oct 28 22:36:53 cobaltdhcpb60 kernel: hub.c: new USB device 00:14.3-1.2, > assigned address 7 > Oct 28 22:36:57 cobaltdhcpb60 kernel: message.c: usb_control/bulk_msg: timeout > Oct 28 22:36:58 cobaltdhcpb60 kernel: message.c: error getting string > descriptor 0 (error=-110) > Oct 28 22:36:58 cobaltdhcpb60 kernel: Manufacturer: EPSON > Oct 28 22:36:58 cobaltdhcpb60 kernel: scanner.c: probe_scanner: User > specified USB scanner -- Vendor:Product - 4b8:10c > Oct 28 22:36:58 cobaltdhcpb60 /sbin/hotplug: arguments (usb) env > (DEVFS=/proc/bus/usb OLDPWD=/ PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add > PWD=/etc/hotplug SHLVL=1 HOME=/ DEVICE=/proc/bus/usb/002/007 > PRODUCT=4b8/10c/1 TYPE=255/0/255 DEBUG=kernel _=/bin/env) > Oct 28 22:36:58 cobaltdhcpb60 /sbin/hotplug: invoke /etc/hotplug/usb.agent () > Oct 28 22:37:01 cobaltdhcpb60 /etc/hotplug/usb.agent: Setup scanner for USB > product 4b8/10c/1 > Have you tried with another usb HCI? If you're using uhci, you can try usb-uhci instead (kernel configuration). Except that, I don't really know. You can try posting your message on linux-dev too (see linux-usb.org). Frank.
[sane-devel] losing hair and sleep over this
noah wrote: > scanners don't work on my system!!! > i've tried three scanners. two of which were admittedly unsupported, but the > third of which is supposedly fully supported by sane. > they were all usb. > this last one is an epson perfection 640u. here's what happens: > i plug in the scanner. > quoth /var/log/messages: > Oct 28 22:36:49 cobaltdhcpb60 /sbin/hotplug: arguments (usb) env > (DEVFS=/proc/bus/usb OLDPWD=/ PATH=/bin:/sbin:/usr/sbin:/usr/bin > ACTION=remove PWD=/etc/hotplug SHLVL=1 HOME=/ DEVICE=/proc/bus/usb/002/006 > PRODUCT=4b8/10c/1 TYPE=255/0/255 DEBUG=kernel _=/bin/env) > Oct 28 22:36:49 cobaltdhcpb60 /sbin/hotplug: invoke /etc/hotplug/usb.agent () > Oct 28 22:36:53 cobaltdhcpb60 kernel: hub.c: new USB device 00:14.3-1.2, > assigned address 7 > Oct 28 22:36:57 cobaltdhcpb60 kernel: message.c: usb_control/bulk_msg: timeout > Oct 28 22:36:58 cobaltdhcpb60 kernel: message.c: error getting string > descriptor 0 (error=-110) Hum. Not good. What is the version of your kernel (and distribution)? Do you have a powerpc or pentium? Frank.
[sane-devel] Lexmark X83
Dave Close wrote: > I noticed recently that Henning reports the gt68xx backend is reported > to work with some Lexmark scanners, including the X70 and X73. So I've > been encouraged to try with the X83 but I don't have it working yet. > If anyone has already made it work, please let us know. > > According to gt68xx.conf, the X7? scanners identify as 0x043d 0x002d. > My X83 identifies itself as 0x043d 0x003d, so I've added that line to > gt68xx.conf. Without any other changes (using SANE from CVS), sane- > find-scanner does not see the X83 (should it?). scanimage -h gt68xx: > (without a device file) reports a segmentation fault. Adding > /dev/usb/scanner[0-15] fails with the message, "open of device > gt68xx:/dev/usb/scanner? failed: Invalid argument" (replacing ? with > the actual number). All those device files exist, are owned by me, > and have permission 600. I must be missing something obvious. Loading the scanner driver with modprobe scanner vendor=0x043d product=0x003d should help sane-find-scanner to actually see it. Frank.
Sane installed twice (was Re: [sane-devel] epson scanner driving me crazy)
[...] > If you think > you already did this, then you have two versions of Sane (or at > least of the config files) installed. The fact that you think you > commented out the v4l entry also suggests this: If this were the > case, you would not see the v4l entries in your log. > > Please check that you have only one version of Sane installed. > Since this is a recurrent issue, sane-find-scanner and maybe (x)scanimage, could test for the presence of 2 sane installation and issue a warning. Testing for the presence of libsane.so in 2 or more directories should suffice. Frank.
[sane-devel] PRIMAX Jewle 4800
Michael Höller wrote: > Hi, > > I try to get a PRIMAX Jewle 4800 up t work but there seems to be a problem. > Can anyone tell me what I can do to get it to work? > > Thanks a lot > Michael > > Hi Michael, This scanner is not (yet) supported. There is some work in progress at: http://gkall.hobby.nl/notes2.html Frank.
[sane-devel] wrong assumption on char signedness
Aurelien Jarno wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> In backends/plustek-usbshading.c, in function usb_GetNewOffset, there
> is
>
> if( pcOffset[dw] >= 0 )
>
> pcOffset[dw] is defined as char. On some architectures (at least arm,
> powerpc and s390), char is per default unsigned on. This causes a
> warning on compilation ("warning: comparison is always true due to
> limited range of data type"), and may cause some errors at run time.
>
> I have made a small patch, but I am not sure it corrects everything.
What about adding -fsigned-char to CFLAGS instead?
Frank.
[sane-devel] (patch) Small fixes for canon630u, coolscan and microtek2
Hi Andras, Petter, >>If sizeof(size_t) is bigger then sizeof(u_int32_t), than the call to >>sanei_scsi_cmd() will write outside the space allocated for >>ms->n_control_bytes. If it is smaller, the value in >>ms->n_control_bytes will be wrong. It only work as it should if >>size_t and u_int32_t is the same type. This is not the case on >>64-bit machines. > > > This is definitely a bug in that backend, but your solution doesn't > solve anything. The only thing it might do is create a compiler > warning which is not much use to the end user anyway. (In fact, it > will certainly cause the compiler to warn about an unused variable.) > > This needs fixing, I agree, and it should be done before 1.0.9. The > solution should be rather easy, I guess the types involved should > either be all size_t or all u_int32_t, but I can't tell (I haven't got > the time to look at the code right now). Using size_t for ms->n_control_bytes is the way to go. It's ok for ia32 since sizeof(size_t) == sizeof(int). It needs some testing of wider platforms, though, but that's a good start. > BTW, is there any specified lower limit for sizeof(size_t), i.e. can > we safely assume that size_t can always take 32-bit values? Probably That's a safe assumption, at least for the platforms SANE runs on. > not a problem in this case, but it could have interesting implications > now that open-source software on embedded devices, PDAs etc. is taking > off. Frank.
[sane-devel] (patch) Small fixes for canon630u, coolscan and microtek2
Petter Reinholdtsen wrote: > [Frank Zago] > >>What's the point of this one? > > > If sizeof(size_t) is bigger then sizeof(u_int32_t), than the call to > sanei_scsi_cmd() will write outside the space allocated for > ms->n_control_bytes. If it is smaller, the value in > ms->n_control_bytes will be wrong. It only work as it should if > size_t and u_int32_t is the same type. This is not the case on 64-bit > machines. Hi Petter, That's definitively a bug to fix. However you're creating and setting a variable. But you're not using it! Frank
[sane-devel] (patch) Small fixes for canon630u, coolscan and microtek2
> === > RCS file: /cvsroot/external/sane/sane-backends/backend/microtek2.c,v > retrieving revision 1.10 > diff -u -3 -p -u -w -r1.10 microtek2.c > --- microtek2.c 2002/05/24 22:41:34 1.10 > +++ microtek2.c 2002/10/04 13:43:40 > @@ -4389,6 +4389,8 @@ scsi_read_control_bits(Microtek2_Scanner > int bit; > int count_1s; > > +size_t n_control_bytes; > + > md = ms->dev; > > DBG(30, "scsi_read_control_bits: ms=%p, fd=%d\n", ms, ms->sfd); > @@ -4400,6 +4402,8 @@ scsi_read_control_bits(Microtek2_Scanner > if ( md_dump >= 2) > dump_area2(cmd, RCB_CMD_L, "readcontrolbits"); > > +/* Avoid problems if sizeof(u_int32_t) != sizeof(size_t) */ > +n_control_bytes = ms->n_control_bytes; > status = sanei_scsi_cmd(ms->sfd, > cmd, > sizeof(cmd), What's the point of this one?
