[sane-devel] HP Scanjet G4010

[Brian Shaver]

Stef,
Obtained the latest git source code. The G4010 is detected. scanimage --test
passes. However, trying both Color and Gray modes all I get back scanimage
is a solid black image.

I'll keep looking around for more information  / tests to run, or let me
know if there is specific output which would be helpful.

Thanks,
Brian ..

On Mon, Oct 4, 2010 at 12:08 AM, stef  wrote:

> Le Saturday 02 October 2010 11:25:07 Brian Shaver, vous avez ?crit :
> > Hello,
> > I've got an HP Scanjet G4010.
> >
> > I'd like to offer to assist with developing a backend for this model. If
> > I'm not mistaken, it looks like this is being actively worked on
> > currently. Does someone know the status of this effort?
> >
> > I'd be willing to help with testing, tweaks or whatever.
> >
> > Thanks,
> > Brian ..
> Hello,
>
>I have committed code for G4010 support in the genesys backend at
> the
> same time for limited support for G4050. It should be able to scan at 200
> and
> 300 dpi. It would be nice if you could test latest SANE's git source code.
>The next step is to add higher resolution (up to 4800 dpi), but it
> needs
> another way of setting up the sensor. Up to now the genesys backend assumed
> that hardware sensor's dpi wouldn't change. This has to be modified since a
> low dpi scan is slower when the sensor is set to 4800 than another lower
> resolution.
>
> Regards,
> Stef
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20101005/29b83a80/attachment.htm>

[sane-devel] HP Scanjet G4010

[Brian Shaver]

Stef,
You are correct, changing the following line now produces results:

  /* set up clock once for all */
  if (1) /*if (strcmp (dev->model->name, "hewlett-packard-scanjet-g4050") ==
0) */

Trying Gray, Color and Lineart modes. The result for Gray was pretty good.
With the Color mode I'm seeing some ghosted image effects. The Lineart mode
produced an image which was nearly all black.

Thanks,
Brian ..


On Thu, Oct 7, 2010 at 12:15 AM, stef  wrote:

> Le Tuesday 05 October 2010 15:28:28 Brian Shaver, vous avez ?crit :
> > Stef,
> > Obtained the latest git source code. The G4010 is detected. scanimage
> > --test passes. However, trying both Color and Gray modes all I get back
> > scanimage is a solid black image.
> >
> > I'll keep looking around for more information  / tests to run, or let me
> > know if there is specific output which would be helpful.
> >
> > Thanks,
> > Brian ..
> >
> Hello,
>
>there is a bug in setting up some registers values. To check it is
> the
> cause of blacks images, in gl843_cold_boot(), change the strcmp around line
> 3679 to if(1) in genesys_gl843.c
>
>Meanwhile I am progressing. I have added 100 and 150 dpi modes, and
> 600,
> 1200 and 2400 dpi modes are about to work.
>
> Regards,
> Stef
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20101008/797c2ec0/attachment.htm>

[sane-devel] HP Scanjet G4010

[Brian Shaver]

Hello,
I've got an HP Scanjet G4010.

I'd like to offer to assist with developing a backend for this model. If I'm
not mistaken, it looks like this is being actively worked on currently. Does
someone know the status of this effort?

I'd be willing to help with testing, tweaks or whatever.

Thanks,
Brian ..
-- next part --
An HTML attachment was scrubbed...
URL: 

[sane-devel] New magicolor backend for inclusion in git

[Brian Shaver]

I'm having some trouble compiling with these changes committed. Below is the
error I'm getting. I'll admit I haven't actually looked into the source code
to confirm the change comes from this set of commits, but it seemed like it
would be related. I'm running Fedora 13, and I've been able to build from
the latest source as recent as 2011.01.12.

Thanks,
Brian ..

/bin/sh ../libtool --silent  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
-I. -I../include/sane -I/usr/local/include -I. -I. -I../include -I../include
-DLIBDIR="/home/bshaver/test-root/lib/sane" -DBACKEND_NAME=magicolor
-DPATH_SANE_CONFIG_DIR=/home/bshaver/test-root/etc/sane.d
-DPATH_SANE_DATA_DIR=/home/bshaver/test-root/share
-DPATH_SANE_LOCK_DIR=/home/bshaver/test-root/var/lock/sane
-DV_MAJOR=1 -DV_MINOR=0  -g -O2 -W -Wall -Wcast-align -Wcast-qual
-Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wstrict-prototypes -pedantic -ansi -MT libmagicolor_la-magicolor.lo -MD -MP
-MF .deps/libmagicolor_la-magicolor.Tpo -c -o libmagicolor_la-magicolor.lo
`test -f 'magicolor.c' || echo './'`magicolor.c
magicolor.c: In function 'dump_hex_buffer_dense':
magicolor.c:400: warning: format '%04x' expects type 'unsigned int', but
argument 3 has type 'size_t'
magicolor.c: In function 'mc_send':
magicolor.c:492: warning: format '%d' expects type 'int', but argument 3 has
type 'size_t'
magicolor.c: In function 'cmd_start_scan':
magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
magicolor.c:680: warning: dereferencing 'void *' pointer
magicolor.c:680: error: invalid use of void expression
magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
magicolor.c:680: warning: dereferencing 'void *' pointer
magicolor.c:680: error: invalid use of void expression
magicolor.c:680: warning: left-hand operand of comma expression has no
effect
magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
magicolor.c:680: warning: dereferencing 'void *' pointer
magicolor.c:680: error: invalid use of void expression
magicolor.c:680: warning: left-hand operand of comma expression has no
effect
magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
magicolor.c:680: warning: dereferencing 'void *' pointer
magicolor.c:680: error: invalid use of void expression
magicolor.c:680: warning: left-hand operand of comma expression has no
effect
magicolor.c: In function 'cmd_read_data':
magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
magicolor.c:921: warning: dereferencing 'void *' pointer
magicolor.c:921: error: invalid use of void expression
magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
magicolor.c:921: warning: dereferencing 'void *' pointer
magicolor.c:921: error: invalid use of void expression
magicolor.c:921: warning: left-hand operand of comma expression has no
effect
magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
magicolor.c:921: warning: dereferencing 'void *' pointer
magicolor.c:921: error: invalid use of void expression
magicolor.c:921: warning: left-hand operand of comma expression has no
effect
magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
magicolor.c:921: warning: dereferencing 'void *' pointer
magicolor.c:921: error: invalid use of void expression
magicolor.c:921: warning: left-hand operand of comma expression has no
effect
magicolor.c: In function 'mc_network_discovery':
magicolor.c:1868: warning: unused parameter 'host'
make[2]: *** [libmagicolor_la-magicolor.lo] Error 1
make[2]: Leaving directory
`/home/bshaver/Documents/Projects/sane-backends/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/bshaver/Documents/Projects/sane-backends/backend'
make: *** [all-recursive] Error 1



On Wed, Jan 19, 2011 at 8:38 AM, m. allan noah  wrote:

> And this code is now part of sane-backends. Thanks Reinhold, and
> welcome to the team.
>
> http://www.sane-project.org/lists/sane-backends-cvs.html#S-MAGICOLOR
>
> allan
>
> On Thu, Jan 6, 2011 at 12:30 PM, Reinhold Kainhofer
>  wrote:
> > As you know, I have been developing a magicolor backend for KONICA
> MINOLTA
> > magicolor 1690MF devices (possibly also for other devices, but I don't
> have
> > access to any other KONICA MINOLTA device that uses the same protocol --
> The
> > bizhub devices use a different protocol).
> >
> > In my view, it is now in a state so that it can be included in
> sane-backends
> > (I'm using it regularly with xsane). The git patches can be found at:
> > http://www.fam.tuwien.ac.at/~reinhold/sane/magicolor_backend_patches/
> >
> > -) The first two (0001 and 0002) are for the sanei_usb functionality
> already
> > send yesterday,
> > -) 0003 is the actual backend,
> > -) 0004 fixes some compiler warnings in byteorder.h, and
> > -) 0005 includes only the changes from running autoreconf (i.e. no manual
> code
> > changes!)
> >
> >
> > The backend uses libsnmp (configure check added!) to optionally
> auto-detect a
> > LAN-connecte

[sane-devel] New magicolor backend for inclusion in git

[Brian Shaver]

I've attached the byteorder.h file.

Brian ..

On Thu, Jan 20, 2011 at 10:31 AM, m. allan noah  wrote:

> what is in your sane-backends/include/byteorder.h file?
>
> allan
>
> On Thu, Jan 20, 2011 at 10:24 AM, Brian Shaver 
> wrote:
> > I'm having some trouble compiling with these changes committed. Below is
> the
> > error I'm getting. I'll admit I haven't actually looked into the source
> code
> > to confirm the change comes from this set of commits, but it seemed like
> it
> > would be related. I'm running Fedora 13, and I've been able to build from
> > the latest source as recent as 2011.01.12.
> > Thanks,
> > Brian ..
> >
> > /bin/sh ../libtool --silent  --tag=CC   --mode=compile gcc
> -DHAVE_CONFIG_H
> > -I. -I../include/sane -I/usr/local/include -I. -I. -I../include
> -I../include
> > -DLIBDIR="/home/bshaver/test-root/lib/sane" -DBACKEND_NAME=magicolor
> > -DPATH_SANE_CONFIG_DIR=/home/bshaver/test-root/etc/sane.d
> >  -DPATH_SANE_DATA_DIR=/home/bshaver/test-root/share
> >  -DPATH_SANE_LOCK_DIR=/home/bshaver/test-root/var/lock/sane  -DV_MAJOR=1
> > -DV_MINOR=0  -g -O2 -W -Wall -Wcast-align -Wcast-qual
> -Wmissing-declarations
> > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes
> > -pedantic -ansi -MT libmagicolor_la-magicolor.lo -MD -MP -MF
> > .deps/libmagicolor_la-magicolor.Tpo -c -o libmagicolor_la-magicolor.lo
> `test
> > -f 'magicolor.c' || echo './'`magicolor.c
> > magicolor.c: In function 'dump_hex_buffer_dense':
> > magicolor.c:400: warning: format '%04x' expects type 'unsigned int', but
> > argument 3 has type 'size_t'
> > magicolor.c: In function 'mc_send':
> > magicolor.c:492: warning: format '%d' expects type 'int', but argument 3
> has
> > type 'size_t'
> > magicolor.c: In function 'cmd_start_scan':
> > magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:680: warning: dereferencing 'void *' pointer
> > magicolor.c:680: error: invalid use of void expression
> > magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:680: warning: dereferencing 'void *' pointer
> > magicolor.c:680: error: invalid use of void expression
> > magicolor.c:680: warning: left-hand operand of comma expression has no
> > effect
> > magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:680: warning: dereferencing 'void *' pointer
> > magicolor.c:680: error: invalid use of void expression
> > magicolor.c:680: warning: left-hand operand of comma expression has no
> > effect
> > magicolor.c:680: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:680: warning: dereferencing 'void *' pointer
> > magicolor.c:680: error: invalid use of void expression
> > magicolor.c:680: warning: left-hand operand of comma expression has no
> > effect
> > magicolor.c: In function 'cmd_read_data':
> > magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:921: warning: dereferencing 'void *' pointer
> > magicolor.c:921: error: invalid use of void expression
> > magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:921: warning: dereferencing 'void *' pointer
> > magicolor.c:921: error: invalid use of void expression
> > magicolor.c:921: warning: left-hand operand of comma expression has no
> > effect
> > magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:921: warning: dereferencing 'void *' pointer
> > magicolor.c:921: error: invalid use of void expression
> > magicolor.c:921: warning: left-hand operand of comma expression has no
> > effect
> > magicolor.c:921: warning: pointer of type 'void *' used in arithmetic
> > magicolor.c:921: warning: dereferencing 'void *' pointer
> > magicolor.c:921: error: invalid use of void expression
> > magicolor.c:921: warning: left-hand operand of comma expression has no
> > effect
> > magicolor.c: In function 'mc_network_discovery':
> > magicolor.c:1868: warning: unused parameter 'host'
> > make[2]: *** [libmagicolor_la-magicolor.lo] Error 1
> > make[2]: Leaving directory
> > `/home/bshaver/Documents/Projects/sane-backends/backend'
> > make[1]: *** [all] Error 2
> > make[1]: 

[sane-devel] New magicolor backend for inclusion in git

[Brian Shaver]

I can confirm this change also eliminates my compilation error. I'm running
Fedora 13 64-bit on Intel Core2 T5500 CPU.

Thanks,
Brian ..

On Thu, Jan 20, 2011 at 12:13 PM, Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:

> Hi Allan,
>
> On Jan 20, 2011, at 6:00 PM, m. allan noah wrote:
>
> > Hmm- looks like *p1 should not be void ptr. Try this change:
> >
> > sane-backends/backend/magicolor.c line 672
> >
> > void *p1;
> >
> > should be
> >
> > unsigned char * p1;
> >
> > perhaps?
>
> Indeed, that fixes the problem along with a second change in the same
> backend. I generated a patch so you can see what I actually changed.
>
> See attached.
>
> Adrian
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[sane-devel] New magicolor backend for inclusion in git

[Brian Shaver]

These changes compiled fine for me on Fedora 13 x64.

Thanks,
Brian ..

On Tue, Jan 25, 2011 at 3:38 PM, Reinhold Kainhofer
wrote:

> Am Samstag, 22. Januar 2011, um 11:54:29 schrieb Reinhold Kainhofer:
> > Anyway, I have a local patch that gets rid of all the byteorder.h macros
> > and instead copies all little-endian encoded values manually
> byte-by-byte.
> > I'm currently away from home, so I cant test it with my magicolor
> scanner.
> > I'll commit it as soon as I'm back home (probably tomorrow).
>
> Finally, I could test that patch and fix all the problems with it. I've now
> pushed a fix to the problems (I no longer use the htole32a etc. macros), so
> I
> hope that the backend now properly compiles also on 64-bit systems.
>
> Cheers,
> Reinhold
> --
> --
> Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
>  * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
>  * http://www.fam.tuwien.ac.at/, DVR: 0005886
>  * LilyPond, Music typesetting, http://www.lilypond.org
>
> --
> 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
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[sane-devel] A couple issues with genesys HP G4010

[Brian Shaver]

I'm using the Lineart mode and trying the --swdespeck option and I've
noticed its leaving a black band along the bottom of the image.

The 2nd issue, is that when I turn the debug up ( SANE_DEBUG_GENESYS=10 )
and try the same scan, the process seg faults. The following is the stack
from the core:

(gdb) bt
#0  0x7fa3e4ce35c8 in sanei_genesys_write_pnm_file
(filename=0x7fa3e4cec479 "unprocessed.pnm",
data=0x7fa3e2267000 , depth=1,
channels=1, pixels_per_line=2360, lines=3188)
at genesys_low.c:144
#1  0x7fa3e4caa60f in genesys_buffer_image (s=0x99e340) at
genesys.c:6895
#2  0x7fa3e4caccab in sane_genesys_start (handle=0x99e340) at
genesys.c:7864
#3  0x7fa3eae33ae2 in sane_dll_start (handle=0x99b2a0) at dll.c:1263
#4  0x7fa3eae20d38 in sane_start (h=0x99b2a0) at dll-s.c:48
#5  0x00406d1c in main (argc=13, argv=0x7fffe2b73a08) at
scanimage.c:2283

 The code is trying to write out a file ( unprocessed.pnm ) containing ... I
think the Lineart converted data before performing the despeck process.

I'd be happy to help with a fix for this, or provide further information or
testing.

Thanks,
Brian ..
-- next part --
An HTML attachment was scrubbed...
URL: 

[sane-devel] A couple issues with genesys HP G4010

[Brian Shaver]

allan,
If I comment out the function call which was causing the crash, then I'm
able to run with a high genesys debug level. This function call was just for
debug purposes to create the "unprocessed.pnm" file. The following commands
were executed with:

SANE_DEBUG_GENESYS=255
SANE_DEBUG_SANEI_MAGIC=255

./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y
138.9 --swdespeck=yes > /tmp/despeck.pnm 2> /tmp/despeck.log

./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y
138.9 > /tmp/no_despeck.pnm 2> /tmp/no_despeck.log

Attached are the images and log files. The black band at the bottom of the
despeck image does not change size based on the despeck value.

Thanks,
Brian ..

On Sat, Jan 29, 2011 at 11:30 AM, m. allan noah  wrote:

> brian- I did not write the genesys backend, but I did write the
> sanei_magic library that it uses to provide the swdespeck option. It
> would be interesting to see a low resolution version of the two
> images, and a log with:
>
> SANE_DEBUG_SANEI_MAGIC=255
>
> combined with whatever the highest debug level genesys will give
> without crashing.
>
> allan
>
> On Fri, Jan 28, 2011 at 8:19 AM, Brian Shaver 
> wrote:
> > I'm using the Lineart mode and trying the --swdespeck option and I've
> > noticed its leaving a black band along the bottom of the image.
> > The 2nd issue, is that when I turn the debug up ( SANE_DEBUG_GENESYS=10 )
> > and try the same scan, the process seg faults. The following is the stack
> > from the core:
> > (gdb) bt
> > #0  0x7fa3e4ce35c8 in sanei_genesys_write_pnm_file
> > (filename=0x7fa3e4cec479 "unprocessed.pnm",
> > data=0x7fa3e2267000 , depth=1,
> > channels=1, pixels_per_line=2360, lines=3188)
> > at genesys_low.c:144
> > #1  0x7fa3e4caa60f in genesys_buffer_image (s=0x99e340) at
> > genesys.c:6895
> > #2  0x7fa3e4caccab in sane_genesys_start (handle=0x99e340) at
> > genesys.c:7864
> > #3  0x7fa3eae33ae2 in sane_dll_start (handle=0x99b2a0) at dll.c:1263
> > #4  0x7fa3eae20d38 in sane_start (h=0x99b2a0) at dll-s.c:48
> > #5  0x00406d1c in main (argc=13, argv=0x7fffe2b73a08) at
> > scanimage.c:2283
> >  The code is trying to write out a file ( unprocessed.pnm ) containing
> ... I
> > think the Lineart converted data before performing the despeck process.
> > I'd be happy to help with a fix for this, or provide further information
> or
> > testing.
> > Thanks,
> > Brian ..
> > --
> > 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"
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110129/0f702484/attachment-0001.htm>
-- next part --
A non-text attachment was scrubbed...
Name: despeck.log.gz
Type: application/x-gzip
Size: 2004 bytes
Desc: not available
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110129/0f702484/attachment-0004.bin>
-- next part --
A non-text attachment was scrubbed...
Name: despeck.pnm.gz
Type: application/x-gzip
Size: 6504 bytes
Desc: not available
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110129/0f702484/attachment-0005.bin>
-- next part --
A non-text attachment was scrubbed...
Name: no_despeck.log.gz
Type: application/x-gzip
Size: 1943 bytes
Desc: not available
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110129/0f702484/attachment-0006.bin>
-- next part --
A non-text attachment was scrubbed...
Name: no_despeck.pnm.gz
Type: application/x-gzip
Size: 7021 bytes
Desc: not available
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110129/0f702484/attachment-0007.bin>

[sane-devel] A couple issues with genesys HP G4010

[Brian Shaver]

Thanks Stef!

Let me know if you'd like any additional information, or if I can be any
help with the fix.

Thanks,
Brian ..

On Sun, Jan 30, 2011 at 2:36 AM, stef  wrote:

> Le Saturday 29 January 2011 21:26:03 Brian Shaver, vous avez ?crit :
> > allan,
> > If I comment out the function call which was causing the crash, then I'm
> > able to run with a high genesys debug level. This function call was just
> > for debug purposes to create the "unprocessed.pnm" file. The following
> > commands were executed with:
> >
> > SANE_DEBUG_GENESYS=255
> > SANE_DEBUG_SANEI_MAGIC=255
> >
> > ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y
> > 138.9 --swdespeck=yes > /tmp/despeck.pnm 2> /tmp/despeck.log
> >
> > ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y
> > 138.9 > /tmp/no_despeck.pnm 2> /tmp/no_despeck.log
> >
> > Attached are the images and log files. The black band at the bottom of
> the
> > despeck image does not change size based on the despeck value.
> >
> > Thanks,
> > Brian ..
> >
> > On Sat, Jan 29, 2011 at 11:30 AM, m. allan noah 
> wrote:
> > > brian- I did not write the genesys backend, but I did write the
> > > sanei_magic library that it uses to provide the swdespeck option. It
> > > would be interesting to see a low resolution version of the two
> > > images, and a log with:
> > >
> > > SANE_DEBUG_SANEI_MAGIC=255
> > >
> > > combined with whatever the highest debug level genesys will give
> > > without crashing.
> > >
> > > allan
> > >
> > > On Fri, Jan 28, 2011 at 8:19 AM, Brian Shaver 
> > >
> > > wrote:
> > > > I'm using the Lineart mode and trying the --swdespeck option and I've
> > > > noticed its leaving a black band along the bottom of the image.
> > > > The 2nd issue, is that when I turn the debug up (
> SANE_DEBUG_GENESYS=10
> > > > ) and try the same scan, the process seg faults. The following is the
> > > > stack from the core:
> > > > (gdb) bt
> > > > #0  0x7fa3e4ce35c8 in sanei_genesys_write_pnm_file
> > > > (filename=0x7fa3e4cec479 "unprocessed.pnm",
> > > >
> > > > data=0x7fa3e2267000 ,
> > > > depth=1,
> > > >
> > > > channels=1, pixels_per_line=2360, lines=3188)
> > > >
> > > > at genesys_low.c:144
> > > >
> > > > #1  0x7fa3e4caa60f in genesys_buffer_image (s=0x99e340) at
> > > > genesys.c:6895
> > > > #2  0x7fa3e4caccab in sane_genesys_start (handle=0x99e340) at
> > > > genesys.c:7864
> > > > #3  0x7fa3eae33ae2 in sane_dll_start (handle=0x99b2a0) at
> > > > dll.c:1263 #4  0x7fa3eae20d38 in sane_start (h=0x99b2a0) at
> > > > dll-s.c:48 #5  0x00406d1c in main (argc=13,
> > > > argv=0x7fffe2b73a08) at scanimage.c:2283
> > > >
> > > >  The code is trying to write out a file ( unprocessed.pnm )
> containing
> > >
> > > ... I
> > >
> > > > think the Lineart converted data before performing the despeck
> process.
> > > > I'd be happy to help with a fix for this, or provide further
> > > > information
> > >
> > > or
> > >
> > > > testing.
> > > > Thanks,
> > > > Brian ..
> > > > --
> > > > 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"
>
> Hello,
>
>thanks for providing these detailed information. For the crash, the
> image
> writing function doesn't handle line art bitmap format. I'm currently
> fixing
> that. For the black band, it is due to incorrect settings in registers in
> line
> art mode which makes the backend reading too much data from the scanner.
> This
> extra data is filled with 'noise'. I am currently looking into that.
>
> Regards,
> Stef
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110130/61db34f1/attachment.htm>

[sane-devel] A couple issues with genesys HP G4010

[Brian Shaver]

On Mon, Jan 31, 2011 at 4:07 PM, stef  wrote:

> Le Sunday 30 January 2011 19:46:00 Brian Shaver, vous avez ?crit :
> > Thanks Stef!
> >
> > Let me know if you'd like any additional information, or if I can be any
> > help with the fix.
> >
> > Thanks,
> > Brian ..
> >
> > On Sun, Jan 30, 2011 at 2:36 AM, stef  wrote:
> > > Le Saturday 29 January 2011 21:26:03 Brian Shaver, vous avez ?crit :
> > > > allan,
> > > > If I comment out the function call which was causing the crash, then
> > > > I'm able to run with a high genesys debug level. This function call
> > > > was just for debug purposes to create the "unprocessed.pnm" file. The
> > > > following commands were executed with:
> > > >
> > > > SANE_DEBUG_GENESYS=255
> > > > SANE_DEBUG_SANEI_MAGIC=255
> > > >
> > > > ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7
> -y
> > > > 138.9 --swdespeck=yes > /tmp/despeck.pnm 2> /tmp/despeck.log
> > > >
> > > > ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7
> -y
> > > > 138.9 > /tmp/no_despeck.pnm 2> /tmp/no_despeck.log
> > > >
> > > > Attached are the images and log files. The black band at the bottom
> of
> > >
> > > the
> > >
> > > > despeck image does not change size based on the despeck value.
> > > >
> > > > Thanks,
> > > > Brian ..
> > > >
> > > > On Sat, Jan 29, 2011 at 11:30 AM, m. allan noah 
> > >
> > > wrote:
> > > > > brian- I did not write the genesys backend, but I did write the
> > > > > sanei_magic library that it uses to provide the swdespeck option.
> It
> > > > > would be interesting to see a low resolution version of the two
> > > > > images, and a log with:
> > > > >
> > > > > SANE_DEBUG_SANEI_MAGIC=255
> > > > >
> > > > > combined with whatever the highest debug level genesys will give
> > > > > without crashing.
> > > > >
> > > > > allan
> > > > >
> > > > > On Fri, Jan 28, 2011 at 8:19 AM, Brian Shaver <
> shakerlxxv at gmail.com>
> > > > >
> > > > > wrote:
> > > > > > I'm using the Lineart mode and trying the --swdespeck option and
> > > > > > I've noticed its leaving a black band along the bottom of the
> > > > > > image. The 2nd issue, is that when I turn the debug up (
> > >
> > > SANE_DEBUG_GENESYS=10
> > >
> > > > > > ) and try the same scan, the process seg faults. The following is
> > > > > > the stack from the core:
> > > > > > (gdb) bt
> > > > > > #0  0x7fa3e4ce35c8 in sanei_genesys_write_pnm_file
> > > > > > (filename=0x7fa3e4cec479 "unprocessed.pnm",
> > > > > >
> > > > > > data=0x7fa3e2267000 ,
> > > > > > depth=1,
> > > > > >
> > > > > > channels=1, pixels_per_line=2360, lines=3188)
> > > > > >
> > > > > > at genesys_low.c:144
> > > > > >
> > > > > > #1  0x7fa3e4caa60f in genesys_buffer_image (s=0x99e340) at
> > > > > > genesys.c:6895
> > > > > > #2  0x7fa3e4caccab in sane_genesys_start (handle=0x99e340) at
> > > > > > genesys.c:7864
> > > > > > #3  0x7fa3eae33ae2 in sane_dll_start (handle=0x99b2a0) at
> > > > > > dll.c:1263 #4  0x7fa3eae20d38 in sane_start (h=0x99b2a0) at
> > > > > > dll-s.c:48 #5  0x00406d1c in main (argc=13,
> > > > > > argv=0x7fffe2b73a08) at scanimage.c:2283
> > > > > >
> > > > > >  The code is trying to write out a file ( unprocessed.pnm )
> > >
> > > containing
> > >
> > > > > ... I
> > > > >
> > > > > > think the Lineart converted data before performing the despeck
> > >
> > > process.
> > >
> > > > > > I'd be happy to help with a fix for this, or provide further
> > > > > > information
> > > > >
> > > > > or
> > > > >
> > > > > > testing.
> > > > > > Thanks,
> > > > > > Brian ..
>

[sane-devel] A couple issues with genesys HP G4010

[Brian Shaver]

On Mon, Jan 31, 2011 at 11:30 PM, stef  wrote:

> Le Monday 31 January 2011 23:53:52 Brian Shaver, vous avez ?crit :
> > On Mon, Jan 31, 2011 at 4:07 PM, stef  wrote:
> > > Le Sunday 30 January 2011 19:46:00 Brian Shaver, vous avez ?crit :
> > > > Thanks Stef!
> > > >
> > > > Let me know if you'd like any additional information, or if I can be
> > > > any help with the fix.
> > > >
> > > > Thanks,
> > > > Brian ..
> > > >
> > > > On Sun, Jan 30, 2011 at 2:36 AM, stef  wrote:
> > > > > Le Saturday 29 January 2011 21:26:03 Brian Shaver, vous avez ?crit
> :
> > > > > > allan,
> > > > > > If I comment out the function call which was causing the crash,
> > > > > > then I'm able to run with a high genesys debug level. This
> > > > > > function call was just for debug purposes to create the
> > > > > > "unprocessed.pnm" file. The following commands were executed
> with:
> > > > > >
> > > > > > SANE_DEBUG_GENESYS=255
> > > > > > SANE_DEBUG_SANEI_MAGIC=255
> > > > > >
> > > > > > ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x
> > > > > > 148.7
> > >
> > > -y
> > >
> > > > > > 138.9 --swdespeck=yes > /tmp/despeck.pnm 2> /tmp/despeck.log
> > > > > >
> > > > > > ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x
> > > > > > 148.7
> > >
> > > -y
> > >
> > > > > > 138.9 > /tmp/no_despeck.pnm 2> /tmp/no_despeck.log
> > > > > >
> > > > > > Attached are the images and log files. The black band at the
> bottom
> > >
> > > of
> > >
> > > > > the
> > > > >
> > > > > > despeck image does not change size based on the despeck value.
> > > > > >
> > > > > > Thanks,
> > > > > > Brian ..
> > > > > >
> > > > > > On Sat, Jan 29, 2011 at 11:30 AM, m. allan noah
> > > > > > 
> > > > >
> > > > > wrote:
> > > > > > > brian- I did not write the genesys backend, but I did write the
> > > > > > > sanei_magic library that it uses to provide the swdespeck
> option.
> > >
> > > It
> > >
> > > > > > > would be interesting to see a low resolution version of the two
> > > > > > > images, and a log with:
> > > > > > >
> > > > > > > SANE_DEBUG_SANEI_MAGIC=255
> > > > > > >
> > > > > > > combined with whatever the highest debug level genesys will
> give
> > > > > > > without crashing.
> > > > > > >
> > > > > > > allan
> > > > > > >
> > > > > > > On Fri, Jan 28, 2011 at 8:19 AM, Brian Shaver <
> > >
> > > shakerlxxv at gmail.com>
> > >
> > > > > > > wrote:
> > > > > > > > I'm using the Lineart mode and trying the --swdespeck option
> > > > > > > > and I've noticed its leaving a black band along the bottom of
> > > > > > > > the image. The 2nd issue, is that when I turn the debug up (
> > > > >
> > > > > SANE_DEBUG_GENESYS=10
> > > > >
> > > > > > > > ) and try the same scan, the process seg faults. The
> following
> > > > > > > > is the stack from the core:
> > > > > > > > (gdb) bt
> > > > > > > > #0  0x7fa3e4ce35c8 in sanei_genesys_write_pnm_file
> > > > > > > > (filename=0x7fa3e4cec479 "unprocessed.pnm",
> > > > > > > >
> > > > > > > > data=0x7fa3e2267000  bounds>,
> > > > > > > > depth=1,
> > > > > > > >
> > > > > > > > channels=1, pixels_per_line=2360, lines=3188)
> > > > > > > >
> > > > > > > > at genesys_low.c:144
> > > > > > > >
> > > > > > > > #1  0x7fa3e4caa60f in genesys_buffer_image (s=0x99e340)
> at
> > > > > > > > genesys.c:6895
> > > > > > > > #2  0x7f

[sane-devel] HP Scanjet G4010

[Brian Shaver]

Sebastian,
I can confirm the G4010 is working well for me using the current git
snapshot. It also should be working in the latest release 1.0.22 as alan
indicated below ( I just haven't tried that yet). The support for this
scanner is new in 1.0.22 and it would NOT be working with 1.0.21 or earlier
version.

Brian ..

On Mon, Mar 14, 2011 at 9:22 AM, m. allan noah  wrote:

> Sorry, remove the word 'are' from #1.
>
> allan
>
> On Mon, Mar 14, 2011 at 9:21 AM, m. allan noah  wrote:
> > Two likely reasons:
> >
> > 1. you are must run the recently released sane-backends 1.0.22 or a
> > current git snapshot.
> >
> > 2. you have a permissions problem (try as root)
> >
> > allan
> >
> > On Mon, Mar 14, 2011 at 7:13 AM, Sebastian Klewin 
> wrote:
> >> Hi, I have an question about supporting the HP Scanjet G4010.
> >>
> >>
> >>
> >> At the homepage is the Info that this scanner is unsupported, but a few
> >> lines higher in the genesis-backend is this scanner listed with
> >> basic-support.
> >>
> >> But when I try to use it, the scanner will not be recognized .
> >>
> >>
> >>
> >> Can I get it to work?
> >>
> >>
> >>
> >> Greetings
> >>
> >> Sebastian
> >>
> >> --
> >> 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"
> >
>
>
>
> --
> "The truth is an offense, but not a sin"
>
> --
> 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
>
-- next part --
An HTML attachment was scrubbed...
URL: