[sane-devel] Error during device I/O running saned on WL-500GP under OpenWRT using libusb

[fireandy]

Hello @ all.

I am running latest sane-backends for OpenWRT Kamikaze
Kernel 2.4 using libusb (also from the OpenWRT package).
The scanner gets detected successfully by
sane-scanner-find.
But when I try to run scanimage -d pixma it gives me the
following:
[full log @ http://stingbyte.com/sane_debug.txt]

[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[...]
scanimage: sane_read: Error during device I/O

I have seen, that there was a similiar problem reported:
http://lists.alioth.debian.org/pipermail/sane-devel/2007-March/018818.html

There was the tip, to add a line in backend/pixma_mp150.c
like this:
pixma_sleep(100); /* <== INSERT THIS LINE */

I did this, now the scanner runs the "full initialization"
process, means it scans the whole
bed one time and then adjusts and remains in waiting
position.

Here the log output after editing pixma_mp150.c:

[...]
[pixma] IN   T=4.455 len=8
[pixma]  :06 06 00 00 00 00 00 00
[pixma]
[sanei_usb] sanei_usb_write_bulk: trying to write 16 bytes
[sanei_usb] : F3 20 00 00 00 00 00 00 00 00 00 00 00
00 00 0C . ..
[sanei_usb] sanei_usb_write_bulk: wanted 16 bytes, wrote
16 bytes
[pixma] OUT  T=4.457 len=16
[pixma]  :f3 20 00 00 00 00 00 00  00 00 00 00 00
00 00 0c
[pixma]
[sanei_usb] sanei_usb_read_bulk: trying to read 20 bytes
[sanei_usb] : 06 06 00 00 00 00 00 00 01 00 00 00 03
00 02 00 
[sanei_usb] 0010: 00 21 00 D9
.!..
[sanei_usb] sanei_usb_read_bulk: wanted 20 bytes, got 20
bytes
[pixma] IN   T=4.485 len=20
[pixma]  :06 06 00 00 00 00 00 00  01 00 00 00 03
00 02 00
[pixma]  0010:00 21 00 d9
[pixma]
[pixma] Current status: paper=0 cal=0 lamp=0 busy=33
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
[...]
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[pixma] WARNING:Timed out in wait_until_ready()
[sanei_usb] sanei_usb_write_bulk: trying to write 16 bytes
[sanei_usb] : EF 20 00 00 00 00 00 00 00 00 00 00 00
00 00 00 . ..
[sanei_usb] sanei_usb_write_bulk: wanted 16 bytes, wrote
16 bytes
[pixma] OUT  T=35.139 len=16
[pixma]  :ef 20 00 00 00 00 00 00  00 00 00 00 00
00 00 00
[pixma]
[sanei_usb] sanei_usb_read_bulk: trying to read 8 bytes
[sanei_usb] : 06 06 00 00 00 00 00 00

[sanei_usb] sanei_usb_read_bulk: wanted 8 bytes, got 8
bytes
[pixma] IN   T=35.141 len=8
[pixma]  :06 06 00 00 00 00 00 00
[pixma]
[sanei_usb] sanei_usb_read_int: trying to read 16 bytes
USB error: error submitting URB: Invalid argument
[sanei_usb] sanei_usb_read_int: read failed: Invalid
argument
[pixma] Reader task terminated: Connection timed out
[pixma] read_image():reader task closed the pipe:0 bytes
received, 1683840 bytes expected
scanimage: sane_read: Error during device I/O
[dll] sane_cancel(handle=0x16a0)
[dll] sane_close(handle=0x16a0)
[pixma] pixma_close(): Canon PIXMA MP150
[sanei_usb] sanei_usb_close: closing device 0
[dll] sane_exit: exiting
[dll] sane_exit: calling backend `pixma's exit function
[dll] sane_exit: finished

So, compiling and testing would be no problem, but I don't
know really what to do next...
If somebody could help me?

Thanks in advance
Stingbyte

[sane-devel] [announce] coolscan3 release

[René Rebe]

Hey Alessandro,

I just spotted the infrared option. I wonder how you output the infra- 
red
data?

In the Avision backend I recently added infrared support but so far I
just output two frames, one with the infra-red channel(s) and the other
one with the ordinary image data.

What is your backend doing?

Yours,

On 15.12.2007, at 13:54, Alessandro Zummo wrote:

>
>
> The experimental coolscan3 driver, which is a slightly retouched
> coolscan2 plus infrared, can be found here:
>
> http://sourceforge.net/project/showfiles.php?group_id=187512
>
> along with the necessary tiffscan frontend to use it.
>
> example usage:
>
> tiffscan --device ... --scan --autofocus=yes --ae-wb=yes --depth=12  
> --infrared=yes
>
> tiffscan --device ... --scan --batch --autofocus=yes --ae-wb=yes -- 
> depth=12 --infrared=yes --autoload=yes
>
> (the second one requires the SF-200 slide autoloader)
>
> -- 
>
> Best regards,
>
> Alessandro Zummo,
>  Tower Technologies - Torino, Italy
>
>  http://www.towertech.it
>
>
> -- 
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to sane-devel-request at lists.alioth.debian.org

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 10:29:03 +0100
Ren? Rebe  wrote:

> Hey Alessandro,
> 
> I just spotted the infrared option. I wonder how you output the infra- 
> red
> data?


> In the Avision backend I recently added infrared support but so far I
> just output two frames, one with the infra-red channel(s) and the other
> one with the ordinary image data.
> 
> What is your backend doing?


 alongside RGB data and this is why you need my program tiffscan
 to read it. that's why the bakend is experimental and not
 suited for mainstream sane. I defined a new frame type,
 SANE_FRAME_RGBX for it.

 I did because the double frame solution was not well suited
 for my workflow. now I can have tiffscan toss tiff images directly
 into vuescan for infrared cleaning.


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[René Rebe]

Hi,

now that was a fast reply :-)

On 17.12.2007, at 10:31, Alessandro Zummo wrote:

> On Mon, 17 Dec 2007 10:29:03 +0100
> Ren? Rebe  wrote:
>
>> Hey Alessandro,
>>
>> I just spotted the infrared option. I wonder how you output the  
>> infra-
>> red
>> data?
>
>
>> In the Avision backend I recently added infrared support but so far I
>> just output two frames, one with the infra-red channel(s) and the  
>> other
>> one with the ordinary image data.
>>
>> What is your backend doing?
>
>
> alongside RGB data and this is why you need my program tiffscan
> to read it. that's why the bakend is experimental and not
> suited for mainstream sane. I defined a new frame type,
> SANE_FRAME_RGBX for it.

Ah, ok. We recently added SANE_FRAME_JPEG, and in that
discussion I proposed GRAYI and RGBI.

What is the data format of your scanner? The Avision based ones
return a infra-red value for each R, G and B sensor, not just one
value per pixel, so I get: R,RI,G,GI,B,BI. I can imagine other devices
just return one I sample per pixel.

We should take that into account before adding some official
frame format to the SANE stanard.

>
> I did because the double frame solution was not well suited
> for my workflow. now I can have tiffscan toss tiff images directly
> into vuescan for infrared cleaning.

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 10:46:24 +0100
Ren? Rebe  wrote:

> > alongside RGB data and this is why you need my program tiffscan
> > to read it. that's why the bakend is experimental and not
> > suited for mainstream sane. I defined a new frame type,
> > SANE_FRAME_RGBX for it.
> 
> Ah, ok. We recently added SANE_FRAME_JPEG, and in that
> discussion I proposed GRAYI and RGBI.

 I tried to propose it a year ago but there was
 no consesus about changing current sane vs developing next
 generation sane. given I have no time to fork
 sane i decided to go on my own. 

> 
> What is the data format of your scanner? The Avision based ones
> return a infra-red value for each R, G and B sensor, not just one
> value per pixel, so I get: R,RI,G,GI,B,BI. I can imagine other devices
> just return one I sample per pixel.

 I just get RGBI. 

> We should take that into account before adding some official
> frame format to the SANE stanard.

 I guess you'll need SANE_FRAME_RIGIBI :-D I can happily implement
 it in tiffscan and store the three extra channels in the tiff file,
 but I doubt any infrared cleaning program currently handles it :)

 You can check if vuescan works on your avision and see how it
 saves the "raw data" file (it's just a tiff).

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Error during device I/O running saned on WL-500GP under OpenWRT using libusb

[m. allan noah]

are interrupt usb endpoints supported under 2.4 with the chip that is
in this box?

allan

On 12/17/07, fireandy  wrote:
> Hello @ all.
>
> I am running latest sane-backends for OpenWRT Kamikaze
> Kernel 2.4 using libusb (also from the OpenWRT package).
> The scanner gets detected successfully by
> sane-scanner-find.
> But when I try to run scanimage -d pixma it gives me the
> following:
> [full log @ http://stingbyte.com/sane_debug.txt]
>
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [...]
> scanimage: sane_read: Error during device I/O
>
> I have seen, that there was a similiar problem reported:
> http://lists.alioth.debian.org/pipermail/sane-devel/2007-March/018818.html
>
> There was the tip, to add a line in backend/pixma_mp150.c
> like this:
> pixma_sleep(100); /* <== INSERT THIS LINE */
>
> I did this, now the scanner runs the "full initialization"
> process, means it scans the whole
> bed one time and then adjusts and remains in waiting
> position.
>
> Here the log output after editing pixma_mp150.c:
>
> [...]
> [pixma] IN   T=4.455 len=8
> [pixma]  :06 06 00 00 00 00 00 00
> [pixma]
> [sanei_usb] sanei_usb_write_bulk: trying to write 16 bytes
> [sanei_usb] : F3 20 00 00 00 00 00 00 00 00 00 00 00
> 00 00 0C . ..
> [sanei_usb] sanei_usb_write_bulk: wanted 16 bytes, wrote
> 16 bytes
> [pixma] OUT  T=4.457 len=16
> [pixma]  :f3 20 00 00 00 00 00 00  00 00 00 00 00
> 00 00 0c
> [pixma]
> [sanei_usb] sanei_usb_read_bulk: trying to read 20 bytes
> [sanei_usb] : 06 06 00 00 00 00 00 00 01 00 00 00 03
> 00 02 00 
> [sanei_usb] 0010: 00 21 00 D9
> .!..
> [sanei_usb] sanei_usb_read_bulk: wanted 20 bytes, got 20
> bytes
> [pixma] IN   T=4.485 len=20
> [pixma]  :06 06 00 00 00 00 00 00  01 00 00 00 03
> 00 02 00
> [pixma]  0010:00 21 00 d9
> [pixma]
> [pixma] Current status: paper=0 cal=0 lamp=0 busy=33
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> [...]
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [pixma] WARNING:Timed out in wait_until_ready()
> [sanei_usb] sanei_usb_write_bulk: trying to write 16 bytes
> [sanei_usb] : EF 20 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 . ..
> [sanei_usb] sanei_usb_write_bulk: wanted 16 bytes, wrote
> 16 bytes
> [pixma] OUT  T=35.139 len=16
> [pixma]  :ef 20 00 00 00 00 00 00  00 00 00 00 00
> 00 00 00
> [pixma]
> [sanei_usb] sanei_usb_read_bulk: trying to read 8 bytes
> [sanei_usb] : 06 06 00 00 00 00 00 00
> 
> [sanei_usb] sanei_usb_read_bulk: wanted 8 bytes, got 8
> bytes
> [pixma] IN   T=35.141 len=8
> [pixma]  :06 06 00 00 00 00 00 00
> [pixma]
> [sanei_usb] sanei_usb_read_int: trying to read 16 bytes
> USB error: error submitting URB: Invalid argument
> [sanei_usb] sanei_usb_read_int: read failed: Invalid
> argument
> [pixma] Reader task terminated: Connection timed out
> [pixma] read_image():reader task closed the pipe:0 bytes
> received, 1683840 bytes expected
> scanimage: sane_read: Error during device I/O
> [dll] sane_cancel(handle=0x16a0)
> [dll] sane_close(handle=0x16a0)
> [pixma] pixma_close(): Canon PIXMA MP150
> [sanei_usb] sanei_usb_close: closing device 0
> [dll] sane_exit: exiting
> [dll] sane_exit: calling backend `pixma's exit function
> [dll] sane_exit: finished
>
> So, compiling and testing would be no problem, but I don't
> know really what to do next...
> If somebody could help me?
>
> Thanks in advance
> Stingbyte
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-request a

[sane-devel] [announce] coolscan3 release

[m. allan noah]

On 12/17/07, Alessandro Zummo  wrote:
> On Mon, 17 Dec 2007 10:46:24 +0100
> Ren? Rebe  wrote:
>
> > > alongside RGB data and this is why you need my program tiffscan
> > > to read it. that's why the bakend is experimental and not
> > > suited for mainstream sane. I defined a new frame type,
> > > SANE_FRAME_RGBX for it.

there was no consensus at that time, but since then, those of us that
need these options have plowed ahead and added them to SANE 1. I
really dont want to see a proliferation of types, but as long as the
user is required to set some option to get the non-rgb output, and the
help text for that option explains that the frontend may break, it is
a workable solution. well, its more workable if we all agree on what
the new types are :)

maybe you could come back to the table, and we can get this backend into sane.

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 08:26:12 -0500
"m. allan noah"  wrote:

> On 12/17/07, Alessandro Zummo  wrote:
> > On Mon, 17 Dec 2007 10:46:24 +0100
> > Ren? Rebe  wrote:
> >
> > > > alongside RGB data and this is why you need my program tiffscan
> > > > to read it. that's why the bakend is experimental and not
> > > > suited for mainstream sane. I defined a new frame type,
> > > > SANE_FRAME_RGBX for it.
> 
> there was no consensus at that time, but since then, those of us that
> need these options have plowed ahead and added them to SANE 1. I
> really dont want to see a proliferation of types, but as long as the
> user is required to set some option to get the non-rgb output, and the
> help text for that option explains that the frontend may break, it is
> a workable solution. well, its more workable if we all agree on what
> the new types are :)

 in theory the frontend should not break, since it should check the returned
 frame type. I believe my tiffscan works that way :-D

> maybe you could come back to the table, and we can get this backend into sane.

 I'd love it. 

 from what I've understood we'd need RGBI, GRAYI and RIGIBI. If there's space,
 i' love to have a way to ask the backend for scanner make/model. :)

 if we can make RGBI = 0x10 I will avoid to rewrite the frontend :)


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[m. allan noah]

On 12/17/07, Alessandro Zummo  wrote:
> On Mon, 17 Dec 2007 08:26:12 -0500
> "m. allan noah"  wrote:
>
> > On 12/17/07, Alessandro Zummo  wrote:
> > > On Mon, 17 Dec 2007 10:46:24 +0100
> > > Ren? Rebe  wrote:
> > >
> > > > > alongside RGB data and this is why you need my program tiffscan
> > > > > to read it. that's why the bakend is experimental and not
> > > > > suited for mainstream sane. I defined a new frame type,
> > > > > SANE_FRAME_RGBX for it.
> >
> > there was no consensus at that time, but since then, those of us that
> > need these options have plowed ahead and added them to SANE 1. I
> > really dont want to see a proliferation of types, but as long as the
> > user is required to set some option to get the non-rgb output, and the
> > help text for that option explains that the frontend may break, it is
> > a workable solution. well, its more workable if we all agree on what
> > the new types are :)
>
>  in theory the frontend should not break, since it should check the returned
>  frame type. I believe my tiffscan works that way :-D

and i modified scanimage to also handle unknown frame types.

>
> > maybe you could come back to the table, and we can get this backend into 
> > sane.
>
>  I'd love it.
>
>  from what I've understood we'd need RGBI, GRAYI and RIGIBI.

there are also at least three fax compression variants, as well as a
text variant for hardware patch-code support. i've got a HUGE scanner
in my dining room ATM that needs these. Actually, the bell and howell
backend already supports all these, with a #ifndef.

 If there's space,
>  i' love to have a way to ask the backend for scanner make/model. :)

that is already in the SANE_Device struct?

>
>  if we can make RGBI = 0x10 I will avoid to rewrite the frontend :)
>

if you include sane.h you wont have to change it later.

allan

ps- are you on the mailing list? i'll stop cc'ing you if so...

>
> --
>
>  Best regards,
>
>  Alessandro Zummo,
>   Tower Technologies - Torino, Italy
>
>   http://www.towertech.it
>
>


-- 
"The truth is an offense, but not a sin"

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 08:58:01 -0500
"m. allan noah"  wrote:

> >  from what I've understood we'd need RGBI, GRAYI and RIGIBI.
> 
> there are also at least three fax compression variants, as well as a
> text variant for hardware patch-code support. i've got a HUGE scanner
> in my dining room ATM that needs these. Actually, the bell and howell
> backend already supports all these, with a #ifndef.

 My dining room is free for your use :-D 

 I would output something like XML for every kind of barcode/patchcode/text
 output. this way the frontend will work even for new data types.

 something like

 

 


>  If there's space,
> >  i' love to have a way to ask the backend for scanner make/model. :)
> 
> that is already in the SANE_Device struct?

 Yes, but it is not accessible after sane_open, if I have understood correctly?
 only when you ask the driver the list of devices.
 
> >  if we can make RGBI = 0x10 I will avoid to rewrite the frontend :)
> >
> 
> if you include sane.h you wont have to change it later.

 sure I will, but the binary is the wild, so I was trying to avoid
 some work ;)

 
 ps- are you on the mailing list? i'll stop cc'ing you if so...

 sure!

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[m. allan noah]

On 12/17/07, Alessandro Zummo  wrote:
> On Mon, 17 Dec 2007 08:58:01 -0500
> "m. allan noah"  wrote:
>
> > >  from what I've understood we'd need RGBI, GRAYI and RIGIBI.
> >
> > there are also at least three fax compression variants, as well as a
> > text variant for hardware patch-code support. i've got a HUGE scanner
> > in my dining room ATM that needs these. Actually, the bell and howell
> > backend already supports all these, with a #ifndef.
>
>  My dining room is free for your use :-D
>
>  I would output something like XML for every kind of barcode/patchcode/text
>  output. this way the frontend will work even for new data types.
>
>  something like
>
>  
> 
>  
>

i am not personally prepared to prescribe the use of xml to any
backend author. but i do think that makes more sense than plain text.
there has also been a suggestion in the past of sending scanner
EXIF-type data, which would also work well in xml, but i'm no expert
on either of those.

>
> >  If there's space,
> > >  i' love to have a way to ask the backend for scanner make/model. :)
> >
> > that is already in the SANE_Device struct?
>
>  Yes, but it is not accessible after sane_open, if I have understood 
> correctly?
>  only when you ask the driver the list of devices.
>

yes- you would have to cache the results from the device list. i
suppose that the exif-type data could handle that.

> > >  if we can make RGBI = 0x10 I will avoid to rewrite the frontend :)
> > >
> >
> > if you include sane.h you wont have to change it later.
>
>  sure I will, but the binary is the wild, so I was trying to avoid
>  some work ;)
>

well, if we really add: IR, RGBI, GRAYI, RIGIBI, TEXT, XML, G31D,
G32D, and G42D,
we are getting close to your 0x10 :)

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 09:24:03 -0500
"m. allan noah"  wrote:

> >  I would output something like XML for every kind of barcode/patchcode/text
> >  output. this way the frontend will work even for new data types.
> >
> >  something like
> >
> >  
> > 
> >  
> >
> 
> i am not personally prepared to prescribe the use of xml to any
> backend author. but i do think that makes more sense than plain text.
> there has also been a suggestion in the past of sending scanner
> EXIF-type data, which would also work well in xml, but i'm no expert
> on either of those.

 I worked a bit on both of them. It has the advantage of being
 non-breaking as long as the xml syntax is respected. a frontend
 could always dump it to a file without parsing it. 

 plus, with five or so lines of perl you can decode and extract whatever
 data you want.
 
> >  Yes, but it is not accessible after sane_open, if I have understood 
> > correctly?
> >  only when you ask the driver the list of devices.
> >
> 
> yes- you would have to cache the results from the device list. i
> suppose that the exif-type data could handle that.

 I suppose it too. Are we talking about real exif or something that
 holds the same data as exif? because real exif can be very painful.

> >  sure I will, but the binary is the wild, so I was trying to avoid
> >  some work ;)
> >
> 
> well, if we really add: IR, RGBI, GRAYI, RIGIBI, TEXT, XML, G31D,
> G32D, and G42D,
> we are getting close to your 0x10 :)

 :-D

 
-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[Oliver Rauch]

Am Montag, den 17.12.2007, 14:37 +0100 schrieb Alessandro Zummo:

> 
>  from what I've understood we'd need RGBI, GRAYI and RIGIBI. If there's space,

Can someone explain me for what RIGIBI is needed?
There is no "red infrared" "green infrared" or "blue infrared".
Are there any scanners that produce an own infrared data channel for
red, green and blue?

Best regards
Oliver

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 17:20:28 +0100
Oliver Rauch  wrote:

> Am Montag, den 17.12.2007, 14:37 +0100 schrieb Alessandro Zummo:
> 
> > 
> >  from what I've understood we'd need RGBI, GRAYI and RIGIBI. If there's 
> > space,
> 
> Can someone explain me for what RIGIBI is needed?
> There is no "red infrared" "green infrared" or "blue infrared".
> Are there any scanners that produce an own infrared data channel for
> red, green and blue?

 yes.


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[Oliver Rauch]

Am Montag, den 17.12.2007, 08:58 -0500 schrieb m. allan noah:

> 
> there are also at least three fax compression variants, as well as a
> text variant for hardware patch-code support. i've got a HUGE scanner
> in my dining room ATM that needs these. Actually, the bell and howell
> backend already supports all these, with a #ifndef.

Don`t you think it really gets time to start SANE2 for this?
Please don`t try to force all that into SANE1

Best regards
Oliver

[sane-devel] [announce] coolscan3 release

[Oliver Rauch]

Am Montag, den 17.12.2007, 17:18 +0100 schrieb Alessandro Zummo:
> On Mon, 17 Dec 2007 17:20:28 +0100
> Oliver Rauch  wrote:
> 
> > Am Montag, den 17.12.2007, 14:37 +0100 schrieb Alessandro Zummo:
> > 
> > > 
> > >  from what I've understood we'd need RGBI, GRAYI and RIGIBI. If there's 
> > > space,
> > 
> > Can someone explain me for what RIGIBI is needed?
> > There is no "red infrared" "green infrared" or "blue infrared".
> > Are there any scanners that produce an own infrared data channel for
> > red, green and blue?
> 
>  yes.
> 
> 


can you explain how this works?

Best regards
Oliver

[sane-devel] [announce] coolscan3 release

[m. allan noah]

On 12/17/07, Oliver Rauch  wrote:
> Am Montag, den 17.12.2007, 17:18 +0100 schrieb Alessandro Zummo:
> > On Mon, 17 Dec 2007 17:20:28 +0100
> > Oliver Rauch  wrote:
> >
> > > Am Montag, den 17.12.2007, 14:37 +0100 schrieb Alessandro Zummo:
> > >
> > > >
> > > >  from what I've understood we'd need RGBI, GRAYI and RIGIBI. If there's 
> > > > space,
> > >
> > > Can someone explain me for what RIGIBI is needed?
> > > There is no "red infrared" "green infrared" or "blue infrared".
> > > Are there any scanners that produce an own infrared data channel for
> > > red, green and blue?
> >
> >  yes.
> >
> >
>
>
> can you explain how this works?
>

yes- i also wonder about this- are these CIS machines with both visual
and IR sensors? or a 6 channel CCD?

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] [announce] coolscan3 release

[m. allan noah]

On 12/17/07, Oliver Rauch  wrote:
> Am Montag, den 17.12.2007, 08:58 -0500 schrieb m. allan noah:
>
> >
> > there are also at least three fax compression variants, as well as a
> > text variant for hardware patch-code support. i've got a HUGE scanner
> > in my dining room ATM that needs these. Actually, the bell and howell
> > backend already supports all these, with a #ifndef.
>
> Don`t you think it really gets time to start SANE2 for this?
> Please don`t try to force all that into SANE1

It already IS in SANE1 in at least one backend.

the current SANE2 draft spec is too big for anyone to get started on
it. there are so many backends and frontends out there and so few
developers, that i have begun to doubt it will ever happen. heck- its
been 18+ months since our last SANE1 release. Instead i think we need
to find a way to let SANE1 grow a little, while still maintaining
backwards compatability.

yes, it takes a specialized frontend to use these new frame types, but
the user has to set an option to enable them, and it's really no more
than a single line added to an enum in sane.h, so 'force' is really
not the right word at all.

allan

>
> Best regards
> Oliver
>
>


-- 
"The truth is an offense, but not a sin"

[sane-devel] [announce] coolscan3 release

[Oliver Rauch]

Am Montag, den 17.12.2007, 11:39 -0500 schrieb m. allan noah:
> > Please don`t try to force all that into SANE1
> 
> It already IS in SANE1 in at least one backend.
> 

I don?t talk about what a single backend does.
I talk about the standard.

> the current SANE2 draft spec is too big for anyone to get started on
> it. there are so many backends and frontends out there and so few
> developers, that i have begun to doubt it will ever happen. heck- its
> been 18+ months since our last SANE1 release. Instead i think we need
> to find a way to let SANE1 grow a little, while still maintaining
> backwards compatability.

Then you get several mixes between SANE1 and SANE2 what makes it much
worser than only haveing SANE1 and SANE2.

> 
> yes, it takes a specialized frontend to use these new frame types, but
> the user has to set an option to enable them, and it's really no more
> than a single line added to an enum in sane.h, so 'force' is really
> not the right word at all.


Adding something to an enum is a really bad idea because you can not
test if this item is listed in the enum, you will get a lot of probelms
with this.

We can talk about starting SANE2 and I will create a SANE2 compilant
version of xsane. But I will not produce any mixes between SANE1 and
SANE2 for xsane.

Best regards
Oliver

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 17:25:15 +0100
Oliver Rauch  wrote:

> > > >  from what I've understood we'd need RGBI, GRAYI and RIGIBI. If there's 
> > > > space,
> > > 
> > > Can someone explain me for what RIGIBI is needed?
> > > There is no "red infrared" "green infrared" or "blue infrared".
> > > Are there any scanners that produce an own infrared data channel for
> > > red, green and blue?
> > 
> >  yes.

> 
> can you explain how this works?

 i don't really know, I've been told so by the Avision backend's author,
 (Rene') a few messages earlier in this thread. 

 I guess the scanner has some particular combination of
 infrared light emitter/receiver. 


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 17:23:46 +0100
Oliver Rauch  wrote:

> Am Montag, den 17.12.2007, 08:58 -0500 schrieb m. allan noah:
> 
> > 
> > there are also at least three fax compression variants, as well as a
> > text variant for hardware patch-code support. i've got a HUGE scanner
> > in my dining room ATM that needs these. Actually, the bell and howell
> > backend already supports all these, with a #ifndef.
> 
> Don`t you think it really gets time to start SANE2 for this?
> Please don`t try to force all that into SANE1

 it's not "all that". in fact is just _one_. If you add
 XML output in the backend it will all be done for now
 and ever, as it will cover any format of text/patch code/barcode
 output.


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 17:47:49 +0100
Oliver Rauch  wrote:

> > yes, it takes a specialized frontend to use these new frame types, but
> > the user has to set an option to enable them, and it's really no more
> > than a single line added to an enum in sane.h, so 'force' is really
> > not the right word at all.
> 
> 
> Adding something to an enum is a really bad idea because you can not
> test if this item is listed in the enum, you will get a lot of probelms
> with this.

 why? if every frontend has a correct handling in the default:
 case of the switch() statement, it can just throw an error.
 
> We can talk about starting SANE2 and I will create a SANE2 compilant
> version of xsane. But I will not produce any mixes between SANE1 and
> SANE2 for xsane.

 the beauty of that is that xsane would continue to work with no
 problems at all.

 as a matter of fact, 95% of sane users will just need
 RGB or GRAY. The other 5% can just do some homework
 and get a frontend that suits their needs. 

 and they will surely find one. it's a win-win situation.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[Julien BLACHE]

Alessandro Zummo  wrote:

Hi,

>> Adding something to an enum is a really bad idea because you can not
>> test if this item is listed in the enum, you will get a lot of probelms
>> with this.
>
>  why? if every frontend has a correct handling in the default:
>  case of the switch() statement, it can just throw an error.

I have, like, a feeling of d?ja vu.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 18:22:26 +0100
Julien BLACHE  wrote:

> >> Adding something to an enum is a really bad idea because you can not
> >> test if this item is listed in the enum, you will get a lot of probelms
> >> with this.
> >
> >  why? if every frontend has a correct handling in the default:
> >  case of the switch() statement, it can just throw an error.
> 
> I have, like, a feeling of d?ja vu.

 it's an error in the matrix. should we take the red pill
 or the blue pill?

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[Julien BLACHE]

Alessandro Zummo  wrote:

>> I have, like, a feeling of d?ja vu.
>
>  it's an error in the matrix. should we take the red pill
>  or the blue pill?

At that point I think you need both :)

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 18:41:56 +0100
Julien BLACHE  wrote:

> >> I have, like, a feeling of d?ja vu.
> >
> >  it's an error in the matrix. should we take the red pill
> >  or the blue pill?
> 
> At that point I think you need both :)

 lol :)



 the blue pill means to keep the status quo, like you brush you teeth every
 day, or you commute to work. to use sane as you have always done.

 the red pill might tell you the truth, just the truth, nothing more.
 and might tell you about a slightly different way to use sane.
 
 but the point is, what led us to this choice? it's because a question
 popped up in our minds and this is the real start of our journey
 to consciousness. 

 so it's not about taking one pill or another, they're just different
 paths to the same destination. imho, we should seek a path that
 has a chance to be reached.

 I'd take the red pill.


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] [announce] coolscan3 release

[Julien BLACHE]

Alessandro Zummo  wrote:

Hi,

>  the blue pill means to keep the status quo, like you brush you teeth every
>  day, or you commute to work. to use sane as you have always done.
>
>  the red pill might tell you the truth, just the truth, nothing more.
>  and might tell you about a slightly different way to use sane.

I'll refrain from making any kind of parallel between SANE2 and a
spoon.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 19:03:26 +0100
Julien BLACHE  wrote:

> >  the blue pill means to keep the status quo, like you brush you teeth every
> >  day, or you commute to work. to use sane as you have always done.
> >
> >  the red pill might tell you the truth, just the truth, nothing more.
> >  and might tell you about a slightly different way to use sane.
> 
> I'll refrain from making any kind of parallel between SANE2 and a
> spoon.

 eheh.. just kidding, obviously. in fact I'm pretty satisfied the way
 sane works now. 


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Going forwared with SANE (was: Re: [announce] coolscan3 release)

[Julien BLACHE]

Alessandro Zummo  wrote:

Hi,

>  eheh.. just kidding, obviously. in fact I'm pretty satisfied the way
>  sane works now. 

There's a real question of how SANE is going forward from there on.

It'd be nice if we could answer it at some point.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Going forwared with SANE (was: Re: [announce] coolscan3 release)

[Alessandro Zummo]

On Mon, 17 Dec 2007 19:31:04 +0100
Julien BLACHE  wrote:

> >  eheh.. just kidding, obviously. in fact I'm pretty satisfied the way
> >  sane works now. 
> 
> There's a real question of how SANE is going forward from there on.
> 
> It'd be nice if we could answer it at some point.

 we could, but every answer will be different or, at least, slightly
 different.

 if we answer, who will take the burden of actually choice 
 a single answer?


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Going forwared with SANE

[Julien BLACHE]

Alessandro Zummo  wrote:

>> There's a real question of how SANE is going forward from there on.
>> 
>> It'd be nice if we could answer it at some point.
>
>  we could, but every answer will be different or, at least, slightly
>  different.

Then, we can't answer it. As long as what you wrote will hold, then it
means we can't answer that (rather crucial) question.

>  if we answer, who will take the burden of actually choice 
>  a single answer?

Everybody interested in SANE will take the burden of developing it
further. But that requires a rough form of consensus first.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Going forwared with SANE

[Alessandro Zummo]

On Mon, 17 Dec 2007 19:44:31 +0100
Julien BLACHE  wrote:

> >  we could, but every answer will be different or, at least, slightly
> >  different.
> 
> Then, we can't answer it. As long as what you wrote will hold, then it
> means we can't answer that (rather crucial) question.
> 
> >  if we answer, who will take the burden of actually choice 
> >  a single answer?
> 
> Everybody interested in SANE will take the burden of developing it
> further. But that requires a rough form of consensus first.

 Yes, and given we have not reached it in years, I'm not so
 confident that we would be able to do it now.

 I think we have a split situation in which each "side" has
 probably some 50% . And I don't really have an answer on
 how to solve that.


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Going forwared with SANE

[Julien BLACHE]

Alessandro Zummo  wrote:

Hi,

>  Yes, and given we have not reached it in years, I'm not so
>  confident that we would be able to do it now.
>
>  I think we have a split situation in which each "side" has
>  probably some 50% . And I don't really have an answer on
>  how to solve that.

Then motivation, or, more probably, lack thereof, will solve
that. Sort of.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Going forwared with SANE

[Alessandro Zummo]

On Mon, 17 Dec 2007 19:56:28 +0100
Julien BLACHE  wrote:

> >  I think we have a split situation in which each "side" has
> >  probably some 50% . And I don't really have an answer on
> >  how to solve that.
> 
> Then motivation, or, more probably, lack thereof, will solve
> that. Sort of.

 .. can't follow, can you elaborate?

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Going forwared with SANE

[Julien BLACHE]

Alessandro Zummo  wrote:

>> Then motivation, or, more probably, lack thereof, will solve
>> that. Sort of.
>
>  .. can't follow, can you elaborate?

People on one side or the other will get demotivated, which will help
(or not) one side or the other to prevail, eventually fixing that
problem in the worst possible manner.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Going forwared with SANE

[Jon Chambers]

Hi,

Having lurked on this list for a couple of years it seems that while there are 
probably a reasonably large number of people (like me) who developed one 
driver and keep an eye on the list in case of bug reports etc, the majority 
of the core effort seems dominated by quite a small number of people.  

I suspect that you'd only need three or four of those to reach some consensus 
and start work on the SANE 2+ branch and the rest would follow (although no 
doubt there would be some grumbling on the list first).

cheers,
Jon

On Monday 17 December 2007, Julien BLACHE wrote:
> Alessandro Zummo  wrote:
> >> Then motivation, or, more probably, lack thereof, will solve
> >> that. Sort of.
> People on one side or the other will get demotivated, which will help
> (or not) one side or the other to prevail, eventually fixing that
> problem in the worst possible manner.



-- 
== Jon Chambers =
 http://www.jon.demon.co.uk, 020 8575 7097, 07931 961669
=

[sane-devel] Going forwared with SANE (was: Re: [announce] coolscan3 release)

[m. allan noah]

On Dec 17, 2007 1:32 PM, Alessandro Zummo  wrote:
> On Mon, 17 Dec 2007 19:31:04 +0100
> Julien BLACHE  wrote:
>
> > >  eheh.. just kidding, obviously. in fact I'm pretty satisfied the way
> > >  sane works now.
> >
> > There's a real question of how SANE is going forward from there on.
> >
> > It'd be nice if we could answer it at some point.
>
>  we could, but every answer will be different or, at least, slightly
>  different.
>
>  if we answer, who will take the burden of actually choice
>  a single answer?
>

ahh- yet more deja vu :)

I do not wish to hijack this project in any way. Most of you guys have
far more experience than I in programming heavily-used applications.
Oliver's opinion in particular carries some weight, being that Xsane
is probably the most developed and one of the more used front-ends,
and he has put quite a bit of effort into the current SANE2 draft.

My observations:

1. There is a need for more well-known options controlling certain
hardware (ie- adf)
2. There is a need to expose additional image types to specialized front ends.
3. The SANE2 draft is fairly large
4. The number of developers is limited

Frankly, these changes are quite small, not even a new function call,
but if the hang-up is purely a philosophical one around the word
'standard', then what about SANE1.1? Then every packager/frontend
author would have to compile against the new version, and we might
have some systems that continue to ship both versions (even though
they would be identical for most backends).

allan
-- 
"The truth is an offense, but not a sin"

[sane-devel] Going forwared with SANE (was: Re: [announce] coolscan3 release)

[Étienne Bersac]

Hi,

> 1. There is a need for more well-known options controlling certain
> hardware (ie- adf)
> 2. There is a need to expose additional image types to specialized front ends.
> 3. The SANE2 draft is fairly large
> 4. The number of developers is limited

Let me add : 

  5. event (button, sensors) support
  6. hotplug support (through HAL or whatever the host uses).

?tienne.
-- 
E Ultre?a !
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071217/3ea40369/attachment.pgp
 

[sane-devel] Going forwared with SANE (was: Re: [announce] coolscan3 release)

[Alessandro Zummo]

On Mon, 17 Dec 2007 14:57:51 -0500
"m. allan noah"  wrote:

> 
> Frankly, these changes are quite small, not even a new function call,
> but if the hang-up is purely a philosophical one around the word
> 'standard', then what about SANE1.1? Then every packager/frontend
> author would have to compile against the new version, and we might
> have some systems that continue to ship both versions (even though
> they would be identical for most backends).

 I mostly agree with you, but I want to make a strong point about
 the importance that current frontends should be able to work unaffected
 by those small changes we'd like introduce. 

 I really think we can achieve that. Either by checking that the frontends
 are correctly written or by a mechanism that prevents those new features
 to be exposed by unaware frontends (if it is dangerous to do so)
 or by something else. 

 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Going forwared with SANE (was: Re: [announce] coolscan3 release)

[m. allan noah]

On Dec 17, 2007 3:09 PM, ?tienne Bersac  wrote:
> Hi,
>
> > 1. There is a need for more well-known options controlling certain
> > hardware (ie- adf)
> > 2. There is a need to expose additional image types to specialized front 
> > ends.
> > 3. The SANE2 draft is fairly large
> > 4. The number of developers is limited
>
> Let me add :
>
>   5. event (button, sensors) support
>   6. hotplug support (through HAL or whatever the host uses).
>

please see #3 and #4 :)

i worry about the goals for the release being too large to ever get
completed, so i am just suggesting to start small with things that i
am willing to personally add, while having minimal disruption.

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] Going forwared with SANE

[Alessandro Zummo]

On Mon, 17 Dec 2007 20:46:08 +0100
Julien BLACHE  wrote:

> Alessandro Zummo  wrote:
> 
> >> Then motivation, or, more probably, lack thereof, will solve
> >> that. Sort of.
> >
> >  .. can't follow, can you elaborate?
> 
> People on one side or the other will get demotivated, which will help
> (or not) one side or the other to prevail, eventually fixing that
> problem in the worst possible manner.

 well. if that's the solution then the sooner we go for it,
 the better.

 as I said, I'm absolutely willing to port epson2, coolscan3
 and tiffscan to SANE2. 

 But, please, if SANE2 is not going to happen in a somewhat near future,
 then let us go ahead in the other direction.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Lexmark X1180 - weird noises :/

[got...@s01.de]

Hi!

I got a problem with a Lexmark X1180. The scanner starts making weird
noises when I scan.

There's a similiar Bug report:
http://alioth.debian.org/tracker/?group_id=30186&atid=410366&func=detail&aid=303960

Is there some workaround or fix?

regards
Gottox

the output of sane-find-scanner -v -v:

This is sane-find-scanner from sane-backends 1.0.18-cvs

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

searching for SCSI scanners:
checking /dev/scanner... failed to open (Invalid argument)
checking /dev/sg0... failed to open (Access to resource has been denied)
checking /dev/sg1... failed to open (Invalid argument)
checking /dev/sg2... failed to open (Access to resource has been denied)
checking /dev/sg3... failed to open (Access to resource has been denied)
checking /dev/sg4... failed to open (Access to resource has been denied)
checking /dev/sg5... failed to open (Access to resource has been denied)
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 kernel SCSI driver for your SCSI adapter.

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... failed to open (Invalid argument)
checking /dev/usbscanner10... failed to open (Invalid argument)
checking /dev/usbscanner11... failed to open (Invalid argument)
checking /dev/usbscanner12... failed to open (Invalid argument)
checking /dev/usbscanner13... failed to open (Invalid argument)
checking /dev/usbscanner14... failed to open (Invalid argumen

[sane-devel] [announce] coolscan3 release

[Jonathan Buzzard]

Ren? Rebe wrote:
> Hi,
> 
> now that was a fast reply :-)
> 
> On 17.12.2007, at 10:31, Alessandro Zummo wrote:
> 
>> On Mon, 17 Dec 2007 10:29:03 +0100
>> Ren? Rebe  wrote:
>>
>>> Hey Alessandro,
>>>
>>> I just spotted the infrared option. I wonder how you output the  
>>> infra-
>>> red
>>> data?
>>
>>> In the Avision backend I recently added infrared support but so far I
>>> just output two frames, one with the infra-red channel(s) and the  
>>> other
>>> one with the ordinary image data.
>>>
>>> What is your backend doing?
>>
>> alongside RGB data and this is why you need my program tiffscan
>> to read it. that's why the bakend is experimental and not
>> suited for mainstream sane. I defined a new frame type,
>> SANE_FRAME_RGBX for it.
> 
> Ah, ok. We recently added SANE_FRAME_JPEG, and in that
> discussion I proposed GRAYI and RGBI.
> 
> What is the data format of your scanner? The Avision based ones
> return a infra-red value for each R, G and B sensor, not just one
> value per pixel, so I get: R,RI,G,GI,B,BI. I can imagine other devices
> just return one I sample per pixel.
> 
> We should take that into account before adding some official
> frame format to the SANE stanard.
> 

The inability of the SANE standard to accept an IR channel is something 
that came up at over seven years ago on this list!!!

Perhaps one day I will be able to dump Vuescan for something that is 
open source. However given that I have been waiting seven years for this 
and SANE still has not got around to including the ability to scan the 
IR channel in the standard I am not holding my breath.

In the meantime my copy of Vuescan is one of the best software purchases 
I have ever made.


JAB.

-- 
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.   Tel: +44 1661-832195

[sane-devel] [announce] coolscan3 release

[Alessandro Zummo]

On Mon, 17 Dec 2007 21:51:57 +
Jonathan Buzzard  wrote:

> > 
> > We should take that into account before adding some official
> > frame format to the SANE stanard.
> > 
> 
> The inability of the SANE standard to accept an IR channel is something 
> that came up at over seven years ago on this list!!!
> 
> Perhaps one day I will be able to dump Vuescan for something that is 
> open source. However given that I have been waiting seven years for this 
> and SANE still has not got around to including the ability to scan the 
> IR channel in the standard I am not holding my breath.
 
 I can only say that I deeply understand your feelings, I'm really trying to 
fix that. 

 Which scanner do you have? If it's a Nikon I don't own, I would
 love if you can test it with coolscan3.

> In the meantime my copy of Vuescan is one of the best software purchases 
> I have ever made.
 
 True for me too. 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Error during device I/O running saned on WL-500GP under OpenWRT using libusb

[fireandy]

Sorry, but what are interrupt usb endpoints? Is it the way, the device is
read / written by using libusb?
The USB-Chip in the Box is a VIA 6212. Kernel is 2.4.34 used libusb is
0.1.12-1 

By searching I found the following: 
http://www.nabble.com/usb_interrupt_read-with-libusb-0.1.12-and-kernel-2.4.2
7-to4452928.html

Also a discussion about libusb with interrupt endpoints, where the person,
that states it is not working, receives the same returncode -22 (invalid
argument) as I see, when I do a dmesg. So I would have to give it a try with
Kernel 2.6.x?

Cause I can't find no scanner Kernel module for 2.4.34 for OpenWRT that I
could use as an alternative way of getting data from / to the device.

I mean..there was not nothing - scanner gets detected and moves around...

Stingbyte

[sane-devel] Error during device I/O running saned on WL-500GP under OpenWRT using libusb

[m. allan noah]

if you have the option to use 2.6 kernel, i think you should.

allan

On 12/17/07, fireandy  wrote:
> Sorry, but what are interrupt usb endpoints? Is it the way, the device is
> read / written by using libusb?
> The USB-Chip in the Box is a VIA 6212. Kernel is 2.4.34 used libusb is
> 0.1.12-1
>
> By searching I found the following:
> http://www.nabble.com/usb_interrupt_read-with-libusb-0.1.12-and-kernel-2.4.2
> 7-to4452928.html
>
> Also a discussion about libusb with interrupt endpoints, where the person,
> that states it is not working, receives the same returncode -22 (invalid
> argument) as I see, when I do a dmesg. So I would have to give it a try with
> Kernel 2.6.x?
>
> Cause I can't find no scanner Kernel module for 2.4.34 for OpenWRT that I
> could use as an alternative way of getting data from / to the device.
>
> I mean..there was not nothing - scanner gets detected and moves around...
>
> Stingbyte
>
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-request at lists.alioth.debian.org
>


-- 
"The truth is an offense, but not a sin"

[sane-devel] hs2p backend

[m. allan noah]

Jazz-

> > I've placed latest hs2p_patch.gz on my hs2p_sane_backend website.
> > It compiles on both x86 and x86_64 with the aforementioned warnings
> > related to free(sane.name) and free(sane.model) in sane_exit():
> >
> > # zgrep warn x86_*.gz
> > x86_64_log.gz:hs2p.c:1394: warning: cast discards qualifiers from pointer 
> > target type
> > x86_64_log.gz:hs2p.c:1395: warning: cast discards qualifiers from pointer 
> > target type
> > x86_log.gz:hs2p.c:1394: warning: cast discards qualifiers from pointer 
> > target type
> > x86_log.gz:hs2p.c:1395: warning: cast discards qualifiers from pointer 
> > target type
> >
>
> ok, i've not tried it yet, but i think you've reached the limits of my
> ability. i think that since sane.name is const, either free or the
> cast is going to complain. maybe someone else has an idea.
>

I just wanted to check and see if you are ready to get this code into
sane? i think we can ignore the free/const errors (unless someone else
has an idea).

allan


-- 
"The truth is an offense, but not a sin"

[sane-devel] Epson Perfection 1670 USB on Mac 10.3.9

[andy whelan]

Hello,

First off let me say that I am an absolute novice when it comes to any kind
of a command line interface, so go easy on me.

Here's my problem. I have installed: sane backends 10.0.18 and libusb 0.1.12

on a G4 macintosh running MacOS 10.3.9 and I can't get my scanner to work
using scanimage.

This is what happens:

Andy-Whelans-Computer:~ andywhelan$ sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure
that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

found USB scanner (vendor=0x067b, product=0x2303) at
libusb:001:003-067b-2303-00-00
found USB scanner (vendor=0x04b8 [EPSON], product=0x011f [EPSON Scanner]) at
libusb:002:002-04b8-011f-ff-ff
  # Your USB scanner was (probably) detected. It may or may not be supported
by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

  # You may want to run this program as root to find all devices. Once you
  # found the scanner devices, be sure to adjust access permissions as
  # necessary.

Which sounds okay to me. Then:

Andy-Whelans-Computer:~ andywhelan$ scanimage -L
[sanei_debug] Setting debug level of snapscan to 2.
[snapscan] add_usb_device: error opening device
libusb:002:002-04b8-011f-ff-ff: Invalid argument

And that's all I know. It sounds to me like SANE doesn't like what it's
getting from libusb, but like I said, I'm pretty inexperienced with this
stuff.

Any help would be greatly appreciated.

Andy
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071217/3cfdde16/attachment.htm