>> On Mon, Jul 11, 2005 at 05:11:48PM +0200, Mattias Ellert wrote:
>>> Even better would be:
>>>
>>> *dst-- = ((*src << 4) & 0xf0) + ((*src)& 0x0f);
>>> *dst-- = ((*src) & 0xf0) + ((*src-- >> 4) & 0x0f);
>>>
>>> Then 0 would map to 0 and 15 to 255, i
Wow, am I late getting into this long thread... (better late than never).
>On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
...
>I guess the image format is the most controversal point so I'll start
>with that one. Please keep calm everyone, I don't like to create a
>From: Henning Meier-Geinitz
>Date: Thu, 5 Dec 2002 22:34:09 +0100
...
>On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
>> http://www.meier-geinitz.de/sane/sane2/
>
>Now versioning and naming. Not all of this is strictly SANE standard
>stuff, but let's start with it:
>On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
>> http://www.meier-geinitz.de/sane/sane2/
>
>| 4.3.13 sane_get_select_fd
>http://www.meier-geinitz.de/sane/sane2/0.07/doc012.html#s4.3.13
>
>This function has caused a lot of trouble and misunderstandings. Or to
>be mo
>From: Diego Zuccato
>Date: Mon, 09 Dec 2002 00:13:01 +
>
>Henning Meier-Geinitz wrote:
>
>> And this would be returned by any SANE API function that currently
>> returns SANE_Status? Nice, because it links the error number and the
>> message. No need for an extra call to a function.
>On Monday 09 December 2002 17:51, Matto Marjanovic wrote:
>
>> So, how about this: remove the "frames" concept altogether. The whole
>> notion of calling start_scan() repeatedly to scan the same document was
>> always rather gruesome anyway.
>
&g
>From: Oliver Rauch
>Date: Mon, 9 Dec 2002 23:36:22 +0100
>
>On Friday 06 December 2002 20:24, Henning Meier-Geinitz wrote:
>> Proposal:
...
>but this would make the sane_cancel unnecessaryly complex
>because you have to call
>
> sane_cancel
> while (sane_read != SANE_STATUS_E
Good morning,
>If I understand correctly what happens in the case of auth_callback,
>the remote sane_func isn't finished yet, the callback is still running.
>
>> o Network backend calls the client frontend's callback with string,
>> then finally returns from "sane_func()" request.
>Some details:
>
>| 4.3.8 sane_get_parameters
>http://www.meier-geinitz.de/sane/sane2/0.07/doc012.html#s4.3.8
>
>|typedef struct
>| {
>[...]
>|char reserved[32]; /* 32 bytes for future use */
>| }
>| SANE_Parameters;
>
>--> SANE_Char, not char
SANE_Byte, not SANE_Char! :)
SANE
>> The difference isn't so much the data format as the code flow: all the
>> planar data is returned after a single sane_start(), and the multi-frame
>> flags for determining which 'frame' is currently being scanned can be
>> removed from the standard.
>
>But you can not expect that the o
>> > So, why bother? Remove sane_set_io_mode() and eliminate more confusion.
>>
>> No objection from me.
>
>We should not remove this. It does not cost anything to leave it but
>it gives the frontend the chance to implement a quick user
>interface.
I don't see any real benefit to leaving i
>If you want to save memory (4 bytes :) ) then use
>typedef SANE_Status
>{
> short code;
> short backend-code;
>} SANE_Status;
>which is still 32 bits long.
[Chiming in from the void...]
That's 32 bits long *only* if the structure is packed, which generally
requires a special #pragma
Hi,
Sorry to get into this thread so late...
I have to pull out all my microtek notes again; I might even already have
a fix for this problem in the works --- a big graduation got in the way,
and now I have to refresh many memories.
But, in the meantime...
0) None of this generation of Micro
>> I verified Your latest (second) patch. It also works without any
>> problems, e.a. compiles, scans and picture looks fine.
...
>thanks for this report. To be honest, i must admit that I can't really
>remember your first mails :( But it's nice to read that the patch fixes
>more bugs than
>> What does the patch do? (And how did it fix up the Microtek scanning?)
...
>depending on the status returned by the OS. The sense handler is only
>called, if ccb->ccb_h.status & CAM_AUTOSNS_VALID is true, which should
>guarantee that useful sense data is available.
...
>Without the patch
Hi, Abel,
>are you sure that the Linux SCSI system (or FreeBSD) tries to issue a
>REQUEST SENSE, if it can't "connect" to device? (If I find enough time,
I'm not exactly sure what is going on in this particular situation.
Last winter, a user (Shawn Rutledge) was really helpful in tracking
dow
>OK, so we have indeed a flaw in the Linux SCSI system... I assume that
>the scanners identify themselves as SCSI 1 devices, where these short
>sense data blocks are normal.
They do identify themselves, as a protocol between SCSI-1 and SCSI-2.
("SCSI_1_CCS" in drivers/scsi/scsi.h. This macr
>Am Montag, 17. April 2006 12:18 schrieb Frank Zago:
>
>> 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 th
>From: Daniel Bauer
>Date: Mon, 17 Apr 2006 18:08:06 +0200
...
>I've added the above in "microtek.c" and compiled again. Now there's much
>more
>output (all done as root):
>
>venus:~ # export SANE_DEBUG_MICROTEK=128
>venus:~ # echo $SANE_DEBUG_MICROTEK
>128
>venus:~ # scanimage --dev
>Several months ago I asked on this list who maintains the microtek
>backend, and nobody appears to do so.
Hiya... that would be me, and I most probably have that email in the backlog
somewhere. I've been busy with other stuff for a while, but recently went
and touched the code again (and I w
Hiya,
Here are a couple of small patches for xscanimage, which I will happily
commit to CVS if there are no objections.
They make the dialog window and progress bar update more immediately,
i.e. before the completion of the first sane_read(). For backends
such as microtek, which may have pret
>with Mandrake 9.0. Anyway, the scanner is recognized under xsane just
>fine and works almost well, except that it only scans 11" {letter size}
>area. This is a 13" scanner that support {legal size}. It won't let me
>change the setting past ~11-1/2" in height. Is there a way to make the
>s
Hiya, all,
I've got a question which isn't directly addressed by the API docs:
Suppose a scan is set-up and initiated, and sane_parameters() returns
a definite value for 'lines' (i.e., not -1). What should a backend
do if, before that number of lines is delivered, sand_read() returns
with SAN
>> with SANE_STATUS_EOF? Will/should the frontend abort the scan, or
>> gracefully truncate the output? (Or fill the remaining output with
>> black/white?)
>
>Print a warning and ask the user what to do. Or let the user decide by
>preferences.
(What do the current frontends do?)
>> I
>* strictly speaking sane_set_io_mode() should return SANE_STATUS_GOOD
> for non_blocking == SANE_FALSE, at least that's what the standard
> says. I guess nobody will ever notice...
A suggestion for a very tiny edit in the API docs:
4.3.12 sane_set_io_mode
...
This function may fail
>> Hmm... and the more I look at this, the less I understand what the
>> SANE_STATUS_INVAL case is for. (The microtek backend is blocking-mode
>> exclusively, so I've never really dealt with this) What does
>> "image acquistion is pending" mean? Is that before or after sane_start()
>This way several frontends can open the same device and the options are
>set independant.
>
>On my work I think it is normal that 5 people have the frontend(xsane)
>opened at the same time, all use the same scanner.
I don't see how not locking the device continuously from sane_open() to
san
>I've lost a little bit track of what you've already discussed, but as a user,
>what I would think is a nice feature is when I can take a bunch of papers,
>sit beside the scanner and only need to press the scanner button each time,
>without grabbing mouse, clicking here and there... Last tim
>I don't know, whether you've read my first posting, but the only problem is,
>that there's no way for a frontend to detect whether a button has been
>pressed. What Norman Urs Baier requests is a job for the *frontend* and not
>for the backend :-)
...But, my little epiphany was that if the
> has an ADF, we're all set (assuming ADF's are handled properly, which they
> aren't quite).
...
>The user still has to initiate the whole process ("start ADF scan") from
> the frontend, but then she slides her chair over to the scanner for the
> duration of her document.
Furthermore (last
>You ask the wrong question. The people do not close their frontend and this
>would make it impossible for the others to scan when the device is locked.
Man, Oliver, you must have a lot of very cranky and forgetful people where
you work; this seems to be a serious problem for you!
It seems to
>From: "Harald Schultz"
...
>i've problems with my scanmaker e3 and the aha152x.
>all is installed fine, scanner is detected, but when i want to scan
>scsi frezzes after 5 sec. with following msg:
>aha1502x0: no disconnected command for target 6/0
>the scanner is making the normal noise, b
>> Currently I'm using /usr/local/lib/sane as the default directory for
>> these files as they are binary objects. But as they are
>> platform-independent, shouldn't be the default path for such files
>> SANE_DATA_DIR "/sane" (by default "/usr/local/share/sane")?
>
>I think both places are ok
>additional identification parameter that could be used perhaps via
>a hash function of some sort that would allow us to uniquely identify
>the firmware files with the scanners.
Hee-hee... it's kind of funny to come back from a weekend out of town to
find one lonely email from Henning pleadin
>While I'm working on this topic some more small issues that got lost
>somehow after older discussions. These are proposals for SANE 1. From
>TODO:
Hi --- I hadn't replied to this yet, but it was still in my inbox, so
I had intended to get back to it when I had more time. Here I go:
>1) Wha
Could someone (David?) please remove "s...@tollyboy.com" from the
mailing list? Mr. Davies can resubscribe himself after he gets
out of the hospital and/or fixes his vacation script.
Thanks!
-matt m.
Hi, Henrik, Abel,
I'm catching up on this thread, too. (When I first received the bug report,
I was at the tail-end of finishing a Ph.D. Don't expect too much more
attention just yet -- now I am on vacation. :)
>> Jun 25 13:08:25 cortex unix: esp: Cmd dump for Target 5 Lun 0:
>> Jun 25 13:0
>i have tried the scan now with option norealcal uncommented which avoids the
>hang, but then i get the Out of Memory Error.
>Its still the same after setting MAX_DATA to 256k.
>
>Looks very much like the Problem with the Microtek ScanMaker II and Mac OS
>10.3.2
Could this be one of those "p
...
>So the first thing that fails is the first scsi command being sent that
>has the isWrite set to 0:
>
>[microtek] .get_scan_status 0...
>[sanei_scsi] cmd2: cmd_size:6 src_size:0 dst_size:6 isWrite:0
>[sanei_scsi] isRead dst_size:6
>[sanei_scsi] Executing command
>[sanei_scsi] ExecuteTa
Wow, a lot of Mac+SANE+microtek users sprung up out of nowhere all of
a sudden.
Perhaps a bug in the "real calibrate" code, perhaps tickled by a bug on
the OS-X port...
Try uncommenting the "norealcal" line in the your installed "microtek.conf".
That should skip that operation. (If that doesn
40 matches
Mail list logo
