[sane-devel] microtek2 backend
Hi, On Sat, Jan 11, 2003 at 05:56:06PM +0100, Karsten Festag wrote: > As for the option names, > #define M_NAME_QUALITY_SCAN"quality_scan" > is corrected to > #define M_NAME_QUALITY_SCAN"quality-scan" > and > #define M_NAME_FAST_SCAN "fast_scan" > to > #define M_NAME_FAST_SCAN "fast-scan" > > I added another bugfix and have the new files on my homepage. I also would > like the new microtek2.conf there to be put to CVS. It has some more options > enabled by default that seem to work reliable. It's all in CVS now. Bye, Henning
[sane-devel] scanimage cannot open any backends: weird error message
Hi, On Sat, Jan 11, 2003 at 04:48:25PM +0100, f...@gmx.li wrote: > I have just installed sane-1.0.9 and am encountering the following > situation: > > > # sane-find-scanner > > sane-find-scanner: found USB scanner (vendor = 0x05d8, product = 0x4003) at > > device /dev/usb/scanner0 > > (this is probably good.) > > > # scanimage -v -d test -T > > scanimage: open of device test failed: Invalid argument > > (this is probably bad.) Yes. This means that SANE 1.0.9 wasn't properly installed (or the test backend wasn't installed for some reason). Try "scanimage --version". If either version isn't 1.0.9, something went wrong during install. You can also check with SANE_DEBUG_DLL=255 scanimage -L if the libraries (test in this case) are loaded correctly. > I should add that I added the tevion9693usb backend from > http://www.angelfire.com/linux/crapsite/, which is alpha, but I acted > precisely as told in the instructions and if I am correct this backend > is not even touched in what I am doing. (For 'scanimage -d > tevion9693usb' the symptoms are the same, however.) The above debug messages should also list the tevion backend being loaded. > I am using the scanner kernel module in version 2.4.18. I haven't > done anything about the device node permissions, but I am doing > everything as root. It's found by sane-find-scanner so your kernel is probably ok. Concerning your remark in irc: The gt68xx backend won't work. Bye, Henning
[sane-devel] [ANN] Plustek Backend update V0.45-1
On Saturday 11 January 2003 20:12, Gene Heskett wrote: >On Saturday 11 January 2003 19:30, Henning Meier-Geinitz wrote: >>Hi, >> >>On Sat, Jan 11, 2003 at 07:07:49PM -0500, Gene Heskett wrote: >>> On checking to make sure of my facts, >>> I found the loffOnEnd was 0, and lampOff also at 0. So I >>> assume my file was overwritten at some point by a fresher >>> version. >> >>At least the original sane-backends "make install" does not >> overwrite config files. But if you did "make uninstall", they >> would have been removed. > >No, I hadn't. > >>> The trim each color set of sliders that you get when clicking >>> on the lower left icon was normal at that point. A rescan then >>> set everything to maximum except the gamma sliders, and the >>> formerly 2 stops too bright preview display dropped about 5 >>> stops in britness, with the histograms now showing the raw only >>> covering the leftmost 1/3 of that window, and processed only >>> covering the leftmost 2/3rds of the display. >> >>I'm not sure if I understand this but are you talking about >> xsane's "autoadjsut gamma, brightness and cotrast" feature? That >> can be disabled in Preferences-Enhancement->Autocorrect colors. > >Thanks, I'll give that a try. And it does work a whole lot better, even densities are had from 150dpi to 2400 dpi now. Just one thing about using that preferences menu. The builtin no activity timeout shuts it (xsane and company) down in about 30 seconds, making it hard to study the menu's and adjust anything before xsane goes away. Can this be reset somehow to say 5 minutes? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
[sane-devel] Re: Sane on Ultra Sparc
T. Ribbrock wrote: >>The question that ought to be answered by Abel (?) is whether it >>makes sense to globally switch to the old interface for sparc for >>the sake of simplicity - I do not know how big is the performance >>impact of this. >=20 >=20 > Performance is only one issue - you mention the other one below: 64bit > will come back to bite... :-} Not only in the x86 arena, also on the > Sun market - the prices of second hand UltraSparcs are dropping and > among them are quite a few nice machines to play around with at > home...:-) For a long term solution, we'll need support from the kernel developers. = The fact that Sane uses the write/read interface to access SG devices=20 makes things indeed a bit difficult. Generally, the write and read=20 functions should not change the data in any way, but for the SG=20 interface, the situation is different. When the SG3 interface is used,=20 the SG driver needs to know, if the data was passed from a 32 bit or a=20 64 bit application in order to properly deal with the pointers passed as = the read / write data. Abel >>P.S. Sch=F6nes Wochenende! >=20 >=20 > Danke, gleichfalls! :-) Euch auch!
[sane-devel] Re: Sane on Ultra Sparc
Dr. Ing. Dieter Jurzitza wrote:
> Hello Thomas,
> hello all,
> I think you've got me wrong. This define __SPARC_ARCH__ was only an
> *assumption* of mine. In fact, I am sure this define does *not* exist. Maybe I
> wasn't clear enough.
well, that was my fault -- dumb copy & paste ;)
>
> But according to Thomas's discovery one could say __sparc__ instead.
> The question that ought to be answered by Abel (?) is whether it makes sense
> to
> globally switch to the old interface for sparc for the sake of simplicity - I
> do not know how big is the performance impact of this.
Well, the impact is not _that_ big. The old interface stuffs three
different arrays (SG header, SCSI command data block and the date to be
written to the device) into one array, and passes this array in a write
call to the kernel. This means an additional memcpy for each command,
and a few malloc calls. On an old Sun IPX box with only a few MB RAM
installed this additional memory usage might perhaps be an issue.
Another point is that the old interface underwent a number of changes.
While these changes made a lot of sense, this contributed to the
cluttered code in sanei_scsi.c. Some really old versions of the SG
interface even could not give some additional information about errors
in the Linux SCSI layer. If we get error reports, I really prefer the
reports, where the the new interface was used -- in this case I am sure
that I have useful details about the situation ;)
>
> Whoever maintains the code should decide about the best way to do this
> (Abel?),
> I would appreciate to send a patch to SuSE and so on to allow them to make
> things work in their distribution.
Hrrmmm. I am not very familiar with autoconf. Henning, could you do
that? Thomas already suggested to check, what uname prints ('sparc' vs.
'sparc64').
>
> Nevertheless, there is my offer: if there is someone willing (having the time
> :-) to do so) to find out what is really going on (going wrong...) I am
> willing
> to test and to offer time for testing. This is all I can do for now.
Well, if you are a bit adventurous, you could try this:
- define a replacement of sg_io_hdr, which _might_ work:
typedef struct xsg_io_hdr
{
int interface_id; /* [i] 'S' for SCSI generic (required) */
int dxfer_direction;/* [i] data transfer direction */
unsigned char cmd_len; /* [i] SCSI command length ( <= 16
bytes) */
unsigned char mx_sb_len;/* [i] max length to write to sbp */
unsigned short iovec_count; /* [i] 0 implies no scatter gather */
unsigned int dxfer_len; /* [i] byte count of data transfer */
int pad1;
void * dxferp; /* [i], [*io] points to data transfer
memory
or scatter gather list */
int pad2;
unsigned char * cmdp; /* [i], [*i] points to command to
perform */
int pad3;
unsigned char * sbp;/* [i], [*o] points to sense_buffer
memory */
unsigned int timeout; /* [i] MAX_UINT->no timeout (unit:
millisec) */
unsigned int flags; /* [i] 0 -> default, see SG_FLAG... */
int pack_id;/* [i->o] unused internally (normally) */
int pad4;
void * usr_ptr; /* [i->o] unused internally */
unsigned char status; /* [o] scsi status */
unsigned char masked_status;/* [o] shifted, masked scsi status */
unsigned char msg_status; /* [o] messaging level data (optional) */
unsigned char sb_len_wr;/* [o] byte count actually written to
sbp */
unsigned short host_status; /* [o] errors from host adapter */
unsigned short driver_status;/* [o] errors from software driver */
int resid; /* [o] dxfer_len - actual_transferred */
unsigned int duration; /* [o] time taken by cmd (unit:
millisec) */
unsigned int info; /* [o] auxiliary information */
} xsg_io_hdr_t;
(a simple "copy" of struct sg_io_hdr as defined in sg.h, but with
"padding ints" before each pointer declaration. I even don't know, if
the SParc processor use big or low endian pointer/integers, so it might
be necessary to move the "padding ints" after the pointer declarations.
I conclude from the fact that the old SG interface works, that
sizeof(int)==4, even for 64 bit programs; if this is wrong, the int
definition in the struct would need padding too)
- replace all occurrences of Sg_io_hdr and sg_io_hdr in sanei with
xsg_io_hdr.
If the kernel function __copy_from_user and __copy_to_user can deal with
these fake 64 bit pointers, the SG3 interface might work too. But before
I put this stuff into CVS repository, I'd like to hear a few comments,
especially from other people, especially from those folks, who know a
bot more about kernel internals ;)
>
> I am asking whether there is anywhere a declaration within the gcc-header
> files
> (or some kernel call, or whatsoever ...) that could be used as
[sane-devel] [ANN] Plustek Backend update V0.45-1
On Saturday 11 January 2003 19:30, Henning Meier-Geinitz wrote: >Hi, > >On Sat, Jan 11, 2003 at 07:07:49PM -0500, Gene Heskett wrote: >> On checking to make sure of my facts, >> I found the loffOnEnd was 0, and lampOff also at 0. So I assume >> my file was overwritten at some point by a fresher version. > >At least the original sane-backends "make install" does not > overwrite config files. But if you did "make uninstall", they > would have been removed. No, I hadn't. >> The trim each color set of sliders that you get when clicking on >> the lower left icon was normal at that point. A rescan then set >> everything to maximum except the gamma sliders, and the formerly >> 2 stops too bright preview display dropped about 5 stops in >> britness, with the histograms now showing the raw only covering >> the leftmost 1/3 of that window, and processed only covering the >> leftmost 2/3rds of the display. > >I'm not sure if I understand this but are you talking about > xsane's "autoadjsut gamma, brightness and cotrast" feature? That > can be disabled in Preferences-Enhancement->Autocorrect colors. Thanks, I'll give that a try. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
[sane-devel] Re: Sane on Ultra Sparc
--/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 10, 2003 at 06:15:58PM +0100, Henning Meier-Geinitz wrote: > Ok. This is for SANE 1.0.8? gcc version? Compilation worked without any > patches? bosth shared libs and dynamic loading works? USB and X > clients are unknown? It's sane 1.0.7. Compilation needs a patch that was probably added by Red Hat, so don't ask me how or why... :-} The patch is attached - without it, I get compile errors when rebuilding the RPM. > > And while we're at it - for sane 1.0.7: > > > > Linux 2.4 Sparc32, gcc 2.96, User-level SCSI support: yes, USB: ???, > > shared and dynamic library support: yes, X11 clients: ??? > > URL: http://www.ultralinux.org > > Tested with only one Mustek scanner, but on two different > > SparcStations... > > Thanks, will be added to web page. The patch mentioned above applies to this one as well - my apologies for not checking all. The 1.0.9 backends seem to compile without that patch, though. Regards, Thomas -- - Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919 "You have to live on the edge of reality - to make your dreams come true!" --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sane-sparc.patch" --- sane-1.0.2/sanei/sanei_ab306.c.orig Thu May 18 18:22:45 2000 +++ sane-1.0.2/sanei/sanei_ab306.c Thu May 18 18:24:27 2000 @@ -49,6 +49,10 @@ #include +#ifdef __sparc__ +#define IO_SUPPORT_MISSING +#else + #ifdef HAVE_SYS_IO_H # include/* use where available (glibc 2.x, for example) */ #elif HAVE_ASM_IO_H @@ -72,6 +76,8 @@ #else # define IO_SUPPORT_MISSING +#endif + #endif #include --- sane-1.0.2/sanei/sanei_pio.c.orig Thu May 18 18:24:42 2000 +++ sane-1.0.2/sanei/sanei_pio.cThu May 18 18:25:31 2000 @@ -58,6 +58,10 @@ # include #endif +#ifdef __sparc__ +#define IO_SUPPORT_MISSING +#else + #ifdef HAVE_SYS_IO_H # include/* use where available (glibc 2.x, for example) */ #elif HAVE_ASM_IO_H @@ -83,6 +87,7 @@ #else # define IO_SUPPORT_MISSING +#endif #endif #include --- ./sanei/sanei_pa4s2.c.old Mon Mar 4 14:57:24 2002 +++ ./sanei/sanei_pa4s2.c Mon Mar 4 14:58:13 2002 @@ -62,6 +62,9 @@ #include #endif +#ifdef __sparc__ +#define IO_SUPPORT_MISSING +#else #ifdef HAVE_SYS_IO_H #include #elif HAVE_ASM_IO_H @@ -88,6 +91,7 @@ #else #define IO_SUPPORT_MISSING #endif +#endif #include "sane/sane.h" #include "sane/sanei.h" --/04w6evG8XlLl3ft--
[sane-devel] Re: Sane on Ultra Sparc
On Sat, Jan 11, 2003 at 06:43:52PM +0100, Dr. Ing. Dieter Jurzitza wrote: > I think you've got me wrong. This define __SPARC_ARCH__ was only an > *assumption* of mine. In fact, I am sure this define does *not* > exist. Maybe I wasn't clear enough. >=20 > But according to Thomas's discovery one could say __sparc__ instead. Yes, __sparc__ does indeed work. I just made a patch for sane 1.0.7 as used in the Aurora Linux RPM and rebuilt the RPM for sane-backends. xsane (and hence sane) works fine now. As for performance: I can't judge, as I have no comparison, but I'll test the same RPM on the SS20 as well some time tomorrow. As for defines: I found this handy line of code on google (the output you see below is for the U5/Aurora Linux 0.42): [emgaron@lu-tze emgaron]$ gcc -dM -E - < /dev/null #define __USER_LABEL_PREFIX__ #define __SIZE_TYPE__ unsigned int #define __PTRDIFF_TYPE__ int #define __HAVE_BUILTIN_SETJMP__ 1 #define __GNUC_PATCHLEVEL__ 0 #define __ELF__ 1 #define __WCHAR_TYPE__ int #define __NO_INLINE__ 1 #define __GNUC_MINOR__ 96 #define __WINT_TYPE__ unsigned int #define __sparc__ 1 #define __unix 1 #define unix 1 #define _LONGLONG 1 #define __REGISTER_PREFIX__ #define __linux 1 #define __GNUC__ 2 #define __linux__ 1 #define __VERSION__ "2.96 2731 (Red Hat Linux 7.3 2.96-113)" #define __GCC_NEW_VARARGS__ 1 #define linux 1 #define __unix__ 1 (In case someone is wondering about the compiler: Aurora is based on RHL 7.3, basically an effort to get RHL on Sparc again). As you can see, there's no indication that this is a 64bit machine - which is not really surprising, as this is compiled/run from within the 32bit userland. For all that gcc cares, it's 32bit, AFAIK. > The question that ought to be answered by Abel (?) is whether it > makes sense to globally switch to the old interface for sparc for > the sake of simplicity - I do not know how big is the performance > impact of this. Performance is only one issue - you mention the other one below: 64bit will come back to bite... :-} Not only in the x86 arena, also on the Sun market - the prices of second hand UltraSparcs are dropping and among them are quite a few nice machines to play around with at home...:-) [...] > I am asking whether there is anywhere a declaration within the > gcc-header files (or some kernel call, or whatsoever ...) that could > be used as above for Ultra only. I personally do not know - but > maybe someone on the list does. I'm by no means an expert, but if I understand the results of my google research correctly, there is no simple define to solve this. In fact, one of the things I found when googling for "__sparc64__" was a discussion between FreeBSD and NetBSD developers about whether gcc should be patched to always set this define on Sparc64, regardless of whether the compile is 32bit or 64bit. Aparently, it was regarded as a bad idea by most. So, from my limited amount of knowledge I'd probably go for a solution via configure, but I'm certain that Abel & Co know a lot better than me what to do. > Maybe one could check that in the configure script - do not ask me to do > this, configure is something quite strange for me. :-) I've only worked with it once but I think it's not *that* difficult and it's definitely capable of doing this check. Anyway, at least I can tackle that pile of magazines now with a faster machine - thank a bunch, folks! Cheerio, Thomas > P.S. Sch=F6nes Wochenende! Danke, gleichfalls! :-) --=20 ---= -- Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919 "You have to live on the edge of reality - to make your dreams come true= !"
[sane-devel] [ANN] Plustek Backend update V0.45-1
Thgank you for the update. I am preparing an official update for Mandrake Linux 9.0 now, to preven the Epson 1260 Photo scanners of Mandrake 9.0 users from being damaged. I have tested your update with my Epson Perfection 1260 Photo (it survived the driver version shipped with SANE 1.0.9 without needing to turn it off) and it works well. Only problem is the model auto-detection. It is way too slow. I have a tip to make it faster: When you run "sane-find-scanner", it needs about a second after failing with the SCSI search to find the scanner's USB ID's. And if I mention the USB ID's directly in plustek.conf, xsane needs about a second to start. So I recommend that you let the auto-detection part of the plustek driver call the library function which "sane-find-scanner" uses to determine the USB ID. Then the driver can probe this ID directly and so it gets access to the scanner in two seconds instead of two minutes. WDYT? Till Jaeger, Gerhard wrote: > Hi there, > > I've currently updated the Plustek Backend. > New version now is 0.45-1. > All changes are now in CVS and will go into SANE-1.0.10. > > This version is more or less a bug-fixing version and includes > support for the > EPSON 1260 Photo (inkl. TPA autodetection) - shouldn't damage motor anymore! > CanoScan N670U/N676U > CanoScan N1220U > CanoScan N1240U > CanoScan LIDE 20 > CanoScan LIDE 30 > > Although the picture quality on the CanoScan 1220 and 1240 > is not very good, I think we're on the correct way... > > The USB support covers now the libusb too, please have a look > at the plustek.conf for more info. > > Please test the stuff with your devices. > Cheers > Gerhard > ___ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel > >
[sane-devel] [ANN] Plustek Backend update V0.45-1
On Saturday 11 January 2003 10:05, Jaeger, Gerhard wrote: Announcing a new 45-1 release. In addition to my other excess verbiage report, I should add that the only way to shut the epson 1250u lamp off is to wait out the idle period before quitting, or quit and restart, then quit again once its recognized the scanner and blinked the light once then turned it off. A simple quit while the lamp is still on will leave it on. And I do have those options set in my plustek.conf. Or at least I *did* have them set. On checking to make sure of my facts, I found the loffOnEnd was 0, and lampOff also at 0. So I assume my file was overwritten at some point by a fresher version. Resetting those, the lampOff delay now works. But I'm back to the other oddments I had before, like the first preview run looked pretty good, but the histogram windows showed only a single line. The trim each color set of sliders that you get when clicking on the lower left icon was normal at that point. A rescan then set everything to maximum except the gamma sliders, and the formerly 2 stops too bright preview display dropped about 5 stops in britness, with the histograms now showing the raw only covering the leftmost 1/3 of that window, and processed only covering the leftmost 2/3rds of the display. Do we have a wild pointer someplace? Memory allocated but not initialized till after the first run? Something is certainly odd. I stopped it, restarted it, and got both histograms properly filled in this time, and with the preview display now about 1 stop dark, and the raw is using the left 1/3rd, but the enhanced is now full scale. Bringing the gamma up to 1.3 in all channels like I set in the plustek.conf makes the previewed image look very good. I'm gonna stop it and restart it after I've caused some memory shuffling so it doesn't get its own memory back. I'll be back later. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
[sane-devel] Re: Sane on Ultra Sparc
Hello Thomas, hello all, I think you've got me wrong. This define __SPARC_ARCH__ was only an *assumption* of mine. In fact, I am sure this define does *not* exist. Maybe I wasn't clear enough. But according to Thomas's discovery one could say __sparc__ instead. The question that ought to be answered by Abel (?) is whether it makes sense to globally switch to the old interface for sparc for the sake of simplicity - I do not know how big is the performance impact of this. Whoever maintains the code should decide about the best way to do this (Abel?), I would appreciate to send a patch to SuSE and so on to allow them to make things work in their distribution. Nevertheless, there is my offer: if there is someone willing (having the time :-) to do so) to find out what is really going on (going wrong...) I am willing to test and to offer time for testing. This is all I can do for now. I am asking whether there is anywhere a declaration within the gcc-header files (or some kernel call, or whatsoever ...) that could be used as above for Ultra only. I personally do not know - but maybe someone on the list does. Maybe one could check that in the configure script - do not ask me to do this, configure is something quite strange for me. So to conclude: 1.) the short term solution is at hand, looking forward to the new AMD processors right in front of the door and the 64bit linux on the horizon this issue should be expected to come up once again. If someone wants to try a little harder, come back to me - I'll test. 2.) let me know how to include into the code - I mean I can do right now, but I would prefer to be compliant with the solution you are heading for - just for readability and maintainability. Thanks alot, take care Dieter Jurzitza P.S. Schönes Wochenende! On 11-Jan-2003 T. Ribbrock wrote: > On Sat, Jan 11, 2003 at 12:26:06PM +0100, abel deuring wrote: -- --- E-Mail: Dr. Ing. Dieter Jurzitza Date: 11-Jan-2003 Time: 18:24:55 | \ /\_/\ | | ~x~ |/-\ / \ /- \_/ ^^__ _/ _ / <°°__ \- \_/ | |/| | || || _| _|_| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) ---
[sane-devel] Re: Sane on Ultra Sparc
On Sat, Jan 11, 2003 at 05:56:05PM +0100, T. Ribbrock wrote: [...] > #ifdef __sparc__ > #undef SG_IO > #endif /* __sparc__ */ [...] This time, I forgot a question: Do I understand this correctly - this basically forces the use of the old SG interface, right? This may be a stupid question, but does this mean it will break at some point in the future if/when the old SG interface is ever removed from the Linux kernel? Cheerio, Thomas -- - Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919 "You have to live on the edge of reality - to make your dreams come true!"
[sane-devel] Re: Sane on Ultra Sparc
On Sat, Jan 11, 2003 at 12:38:32PM +0100, abel deuring wrote:
> Forgot one question: This #ifdef disables the usage of the new SG
> interface for all Sparc processors, but we need this only for newer
> ones, with a 64 bit kernel and 32 bit applications. Does anybody know,
> how we could restirct the #ifdef to the this case?
Hm. I know there's __arch64__, but it's only defined if you're
actually *compiling* 64bit, which is not the case here.
How about some detection algorithm in 'configure', maybe based on
"uname -m" ('sparc' on my SS20, 'sparc64' on my U5 and U1)?
Cheerio,
Thomas
--
-
Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919
"You have to live on the edge of reality - to make your dreams come true!"
[sane-devel] How many scanners on an ieee1394 bus
Does anyone know how many scanners you can hang on an ieee1394 or USB 2.0 bus and still get sane to work on all of them? Tim Egbert
[sane-devel] microtek2 backend
Hi, I tested the translations of the microtek2 backend with the snapshot from= =20 09.01.03 and xsane 0.90. It works correctly. Thanks Henning for correctin= g my=20 mistakes (I somehow didn't realize that the translations are now in one=20 file.) As for the option names,=20 #define M_NAME_QUALITY_SCAN"quality_scan" is corrected to #define M_NAME_QUALITY_SCAN"quality-scan" and #define M_NAME_FAST_SCAN "fast_scan" to #define M_NAME_FAST_SCAN "fast-scan" I added another bugfix and have the new files on my homepage. I also woul= d=20 like the new microtek2.conf there to be put to CVS. It has some more opti= ons=20 enabled by default that seem to work reliable. Bye Karsten On Thursday 09 January 2003 02:00, Henning Meier-Geinitz wrote: > Hi, > > On Thu, Jan 09, 2003 at 01:01:54AM +0100, Karsten Festag wrote: > > I have made some modifications to the microtek2 backend: > > > > [Todo List] > > - microtek2.c (scsi_read_control_bits): Make sure to pass a size_= t* > > to sanei_scsi_cmd(). > > > > -done. > > Ok. > > > -added german language support (microtek2.de.po) > > The translations are now done in one file per language > (sane-backends.de.po in this case). Also the charset is UTF-8 now. I > have merged the files in CVS. > > Please check if that works correctly. You'll need XSane 0.90 and > remove the old microtek2.mo files from your system. I guess you can't > access the CVS server, so have a look at > http://www.meier-geinitz.de/sane/snapshots/ . > > > -impoved support for Scanmaker X12USL > > -alpha support for Scanmaker 9800XL > > -some bugfixes > > Ok, microtek2.h and microtek2.c (microtek2_20030109) are applied to > CVS. > > By the way, check microtek2.h, SANE option names are not allowed to > conatin a "_". "The option name must consist of lower-case ASCII > letters (a--z), digits (0-- 9), or the dash character (-) only. The > first character must be a lower-case ASCII character (i.e., not a > digit or a dash)." > > > The files are downloadable via > > > > http://karstenfestag.gmxhome.de/software/list.html > > microtek2.desc: error 403: Forbidden! > > Bye, > Henning > ___ > Sane-devel mailing list > sane-de...@www.mostang.com > http://www.mostang.com/mailman/listinfo/sane-devel
[sane-devel] Re: Sane on Ultra Sparc
On Sat, Jan 11, 2003 at 12:26:06PM +0100, abel deuring wrote: > Seems that I made a too big show out of the problem. Dieter Jurzitza > discovered that it is enough to simply add > > #ifdef __SPARC_ARCH__ > #undef SG_IO > #endif /* __SPARC_ARCH__ */ That didn't work for me. What *did* work was: #ifdef __sparc__ #undef SG_IO #endif /* __sparc__ */ With this define, sane-find-scanner detects the scanner on the U5 just like it did on the SS20 before. Great stuff - thanks a mil! Cheerio, Thomas -- - Thomas Ribbrockhttp://www.ribbrock.orgICQ#: 15839919 "You have to live on the edge of reality - to make your dreams come true!"
[sane-devel] scanimage cannot open any backends: weird error message
[First, let me say that I am impressed. Sane is insanely cool. Thanks!! :-) Hi all, I have just installed sane-1.0.9 and am encountering the following situation: > # sane-find-scanner > sane-find-scanner: found USB scanner (vendor = 0x05d8, product = 0x4003) at > device /dev/usb/scanner0 (this is probably good.) > # scanimage -v -d test -T > scanimage: open of device test failed: Invalid argument (this is probably bad.) I should add that I added the tevion9693usb backend from http://www.angelfire.com/linux/crapsite/, which is alpha, but I acted precisely as told in the instructions and if I am correct this backend is not even touched in what I am doing. (For 'scanimage -d tevion9693usb' the symptoms are the same, however.) I am using the scanner kernel module in version 2.4.18. I haven't done anything about the device node permissions, but I am doing everything as root. Anything else you need to know? If you are curious enough I am happy to meet in IRC in the next few hours. (Btw, irc.openprojects.net complains on connect that it's not called like that any more, maybe somebody wants to update that on http://www.mostang.com/sane/mail.html.) And now I will keep on searching. greetings, Matthias
[sane-devel] Re: [ANN] Plustek Backend update V0.45-1
On Saturday 11 January 2003 10:05, Jaeger, Gerhard wrote: Announcing a 45-1 release. I unpacked it over the old 45 in sane-backends-1.0.9, did a make clean && make && make install, which apparently went well. Fireing up xsane from the icon, I had it do a preview, which ran as far as the end of the forward travel of the carriage, at which time it cleared Olivers logo from the preview window, and the whole thing went away about 1 second later. The carriage went back home as it should have, but the lamp was left on. Running it from a shell, it did the same thing, and reported a "segfault" to the shell window as it exited. The epson iscan-1.40 derived backend still works ok though. I'm going to do another make clean and get rid of the config.cache etc stuffs and try it again, as I've re-arranged the order in ld.so.conf a bit since that configure was done. Humm, that might have done something, in 2 restarts it hasn't crashed yet. However, the returned image seems to be quite dark in the 600 dpi mode, with the raw histogram only occupying about the left hand 25% of that window. Also, all the britness and contrast sliders for both overall and rgb are pegged at the right border of the slider, and labeled 100 at that point. The initial image doesn't look that bad in the preview window, but 1/2 second later when the autoadjust kicks in, the image drops to be dark enough to be obvious. It can only be rescued by the options window britness slider being set for about +4 and a new scan done. Also, the white line artifact is (hooray!) gone when at 600 dpi. However, at 300dpi, its back and the output is too dark as before. Then at 1200 dpi, the inverse appears to be true, I'm on the third scan right now with the britness slider in the option window now at -15 and its still quite a bit too bright. Not making too much progress, I'm trying -30 now. Still too bright in the whites, but the darker colors are now all black, but the histograms haven't changed. Now the contrast is set for -30 also, but its still too bright and contrasty. Final settings for a decent scan are brightness=0 and contrast = -65. So thats a bit off. I also tried a 2400dpi scan (can we say slow?) at those settings and it looked pretty close to the 1200 dpi result except its beginnng to look like it was jpegged a wee bit too much. Is this mode by interpolation? Even the white line artifact is fuzzy. Then at 150dpi, the inverse is true, the usable setting is +7 and +50. Ditto for the 75dpi setting. I don't recall this change dpi, change everything else as being this obvious before, and ISTR the main control windows sliders all were centered at 100.0 prior to this. The motor you'll be glad to hear is running very quietly, only noticable at 150 and 300 dpi. This is odd indeed, I went back to do one more check at 600dpi, and had to virtually zero those sliders to get a decent scan again. I think I've got ghosts or something... Should this not be repeatable? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly
[sane-devel] [ANN] Plustek Backend update V0.45-1
Hi there, I've currently updated the Plustek Backend. New version now is 0.45-1. All changes are now in CVS and will go into SANE-1.0.10. This version is more or less a bug-fixing version and includes support for the EPSON 1260 Photo (inkl. TPA autodetection) - shouldn't damage motor anymore! CanoScan N670U/N676U CanoScan N1220U CanoScan N1240U CanoScan LIDE 20 CanoScan LIDE 30 Although the picture quality on the CanoScan 1220 and 1240 is not very good, I think we're on the correct way... The USB support covers now the libusb too, please have a look at the plustek.conf for more info. Please test the stuff with your devices. Cheers Gerhard
[sane-devel] Re: Sane on Ultra Sparc
abel deuring wrote: > abel deuring wrote: > >> So, what you can do: >> >> 1. compile Sane as a 64-bit application. In this case, sizeof(sg_io_hdr) >> should be the same both in the application and in the kernel. (OK, I >> understand that this might waste some disk space for duplicates of libc >> and friends.) > > [...] > > Seems that I made a too big show out of the problem. Dieter Jurzitza > discovered that it is enough to simply add > > #ifdef __SPARC_ARCH__ > #undef SG_IO > #endif /* __SPARC_ARCH__ */ Forgot one question: This #ifdef disables the usage of the new SG interface for all Sparc processors, but we need this only for newer ones, with a 64 bit kernel and 32 bit applications. Does anybody know, how we could restirct the #ifdef to the this case? Abel
[sane-devel] Re: Sane on Ultra Sparc
abel deuring wrote: > So, what you can do: > > 1. compile Sane as a 64-bit application. In this case, sizeof(sg_io_hdr) > should be the same both in the application and in the kernel. (OK, I > understand that this might waste some disk space for duplicates of libc > and friends.) [...] Seems that I made a too big show out of the problem. Dieter Jurzitza discovered that it is enough to simply add #ifdef __SPARC_ARCH__ #undef SG_IO #endif /* __SPARC_ARCH__ */ somewhere after '# include ' and '# include "/usr/src/linux/include/scsi/sg.h"' in sanei_scsi.c . This disables usage of the new SG interface. So, no other problems; especially was my concern wrong that sizeof(int) might be different in 32 bit and 64 bit modes, or that there could be other incompatibilities. Abel
[sane-devel] mac osx with epson usb backend
Howdy, Thanks for your help!! So I had: Mac OSX 10.2.3 libusb-0.1.7 sane-backends-1.0.9 -- gtk+1.2.10-10 (via fink) the apple beta release of x11 sane-frontends-1.0.9 xsane-0.90 gimp 1.2.3-9 (via fink) BUT! from your advice in the previous post, I replaced my sane-backends with the sane-backends-2003-01-11 snapshot. (I did a make uninstall; make distclean in sane-backends-1.0.9 and compiled then compiled and installed the sane-backends snapshot. ) This has solved my problem I reported in my last post. Yeah! scanimage now succeeds in recognizing the existance of my scanner. But I still can't scan. :-( I'll insert an output dump of scanimage with SANE_DEBUG_USB=255, SANE_DEBUG_SANEI_USB=255, SANE_DEBUG_EPSON=255. My read of this dump is that there is a libusb call (usb_bulk_read) failing. But what confuses me is that during this dump there are some previous points at which usb_bulk_read was called and apparently succeeded. Anyway here is the dump = <> below is the output of `scanimage` with the environment vars SANE_DEBUG_EPSON=255 SANE_DEBUG_USB=255 SANE_DEBUG_SANEI_USB=255 <> [sanei_debug] Setting debug level of epson to 255. [epson] sane_init: sane-backends 1.0.9-cvs [epson] sane_init, ># epson.conf< [epson] sane_init, >#< [epson] sane_init, ># here are some examples for how to configure the EPSON backend< [epson] sane_init, >#< [epson] sane_init, ># SCSI scanner:< [epson] sane_init, >#scsi EPSON< [epson] sane_init, >#< [epson] sane_init, ># Parallel port scanner:< [epson] sane_init, >#pio 0x278< [epson] sane_init, >#pio 0x378< [epson] sane_init, >#pio 0x3BC< [epson] sane_init, >#< [epson] sane_init, ># USB scanner - only enable this if you have an EPSON scanner. It could< [epson] sane_init, ># otherwise block your non-EPSON scanner from being< [epson] sane_init, ># recognized.< [epson] sane_init, ># Depending on your distribution, you may need either the< [epson] sane_init, ># first or the second entry.< [epson] sane_init, >#usb /dev/usbscanner0< [epson] sane_init, >usb libusb:-08:005< [epson] attach_one_usb(libusb:-08:005) [epson] SANE Epson Backend v0.2.32 - 2002-12-28 [epson] attach(libusb:-08:005, 3) [epson] attach: opening libusb:-08:005 [sanei_debug] Setting debug level of sanei_usb to 255. usb_set_debug: Setting debugging level to 255 (on) [sanei_usb] sanei_usb_open: trying to open device `libusb:-08:005' usb_os_open: 04b8:0101 [sanei_usb] sanei_usb_open: chosing first altsetting (0) without checking [sanei_usb] sanei_usb_open: found bulk-in endpoint (address 1) [sanei_usb] sanei_usb_open: found bulk-out endpoint (address 2) [sanei_usb] sanei_usb_open: opened usb device `libusb:-08:005' (*dn=0) [sanei_usb] sanei_usb_get_vendor_product: device 0: vendorID: 0x04b8, productID: 0x0101 [epson] Found valid EPSON scanner: 0x4b8/0x101 (vendorID/productID) [epson] send buf, size = 2 [epson] buf[0] 1b . [epson] buf[1] 40 @ Converting ep address to pipeRef. pipeRef for ep 0x02 found: 0x02 usb_bulk_write: endpoint=0x02 size=2 TO=6 write completed CFLoopRun returned [sanei_usb] sanei_usb_write_bulk: wanted 2 bytes, wrote 0 bytes Converting ep address to pipeRef. pipeRef for ep 0x81 found: 0x01 usb_bulk_read: endpoint=0x81 size=1 TO=6 USB error: error reading from bulk endpoint 81 [sanei_usb] sanei_usb_read_bulk: read failed: No such file or directory USB error: error clearing pipe stall [epson] receive buf, expected = 1, got = 0 [epson] get_identity_information() [epson] send buf, size = 2 [epson] buf[0] 1b . [epson] buf[1] 49 I Converting ep address to pipeRef. pipeRef for ep 0x02 found: 0x02 usb_bulk_write: endpoint=0x02 size=2 TO=6 write completed CFLoopRun returned [sanei_usb] sanei_usb_write_bulk: wanted 2 bytes, wrote 0 bytes Converting ep address to pipeRef. pipeRef for ep 0x81 found: 0x01 usb_bulk_read: endpoint=0x81 size=4 TO=6 [sanei_usb] sanei_usb_read_bulk: wanted 4 bytes, got 4 bytes [epson] receive buf, expected = 4, got = 4 [epson] buf[0] 02 . [epson] buf[1] 00 . [epson] buf[2] 61 a [epson] buf[3] 00 . [epson] code 02 [epson] status 00 [epson] count 97 Converting ep address to pipeRef. pipeRef for ep 0x81 found: 0x01 usb_bulk_read: endpoint=0x81 size=97 TO=6 [sanei_usb] sanei_usb_read_bulk: wanted 97 bytes, got 97 bytes [epson] receive buf, expected = 97, got = 97 <> [epson] resolution (dpi): 2400 [epson] maximum scan area: x 20400 y 28080 [epson] fbf tlx 0.00 tly 0.00 brx 215.84 bry 297.179993 [mm] [epson] send buf, size = 2 [epson] buf[0] 1b . [epson] buf[1] 44 D Converting ep address to pipeRef. pipeRef for ep 0x02 found: 0x02 usb_bulk_write: endpoint=0x02 size=2 TO=6 write completed CFLoopRun returned [sanei_usb] sanei_usb_write_bulk: wanted 2 bytes, wrote 0 bytes Converting ep address to pipeRef. pipeRef for ep 0x81 found: 0x01 usb_bulk_read: endpoint=0x81 size=1 TO=6 [sanei_usb] sanei_usb_read_bul
[sane-devel] mac osx with epson usb backend
Hi, On Fri, Jan 10, 2003 at 03:49:59PM -0800, rchar...@sonicwall.com wrote: > I'm seeking help with getting an epson USB u636 scanner working with > sane (xsane & scanimage). I've come down quite a long path to arrive > at "it's just so close but not yet working". I hope to find the > needed help to get the job done here. I'm not an Epson or Mac expert but maybe some general hints: > My current problem is that scanimage does not find my scanner. But > note that sane-find-scanner does find it. Better than nothing :-) > sane-find-scanner reports: > > found USB scanner (vendor=0x04b8 [EPSON], product=0x0101 [Perfection636]) at > libusb:-08:005 Which version of libusb is this? I remeber someone writing that these negative numbers went away wit hthe latest version but I'm not sure if this has any other consequences. > I have compiled sane with libusb. I had to trick up both the libusb > and the sane compile to get through. During the libusb compile, it > failed to link and I had to manually run ranlib on libusb.a before > the make would continue. During the sane compile, Which version of SANE? I recommend using a recent snapshot from http://www.meier-geinitz.de/sane/snapshots/ which has some fixes for Mac OS. > the compile failed during the cannon backend. "Internal compiler error"? That's a bug in the compiler. > I edited the make file to remove all the > backend objects excpet for the epson object which I think is the only > one I need (at least for the time being) (and I also had to do the > famous apple -no-cpp-precomp in the CFLAGS.) That's not in README.darwin. Question to all the other Mac users: was this flag necessary on your system, too? > But ok, they have compiled. And they installed just fine (seems like > to me anyway). scanimage --version should make that sure :-) > At this point sane-find-scanner is working and reporting my usb > scanner. But scanimage -L cannot find it. Check that the epson backend is loaded at all by setting environment variables: SANE_DEBUG_DLL=255 to see if the dynamic loading works and SANE_DEBUG_EPSON=255 to find out about what the epson backend does. > So I try to edit my /usr/local/etc/sane.d/epson.conf file to say > usb libusb:-08:005 May work. At least with the latest snapshot, usb 0x04b8 0x0101 should also work. > Still scanimage -L cannot find it. Try with SANE_DEBUG_EPSON=255. If you don't see in the debug messages what's going wrong, show us the output. > So I tried to do a `mknod /dev/usbscanner0 c 180 48` with an appropriate > `chmod`. I would be surprised if MacOS X would be Linux-compatible that way. Only libusb will work, ignore the Linux USB kernel driver and all the /dev stuff. Bye, Henning
