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

2011-01-31 Thread Reinhold Kainhofer 
Am Sonntag, 30. Januar 2011, um 20:31:13 schrieb m. allan noah:
> I'm trying to build this now on Fedora 14 with net-snmp enabled, and I
> get the following error:
> 
> magicolor.c: In function 'mc_network_discovery_handle':
> magicolor.c:1800:2: error: 'netsnmp_indexed_addr_pair' undeclared
> (first use in this function)
[...]
> make[2]: *** [libmagicolor_la-magicolor.lo] Error 1
> 
> And poking around in /usr/include/net-snmp reveals no definition for
> netsnmp_indexed_addr_pair. This is using net-snmp 5.5, which seems
> like it might still be a current release?

Ah, sorry. It seems like the snmp auto-detection really needs net-snmp 5.6 :(

In net-snmp 5.5 the UDP broadcast option was added, but apparently the devs 
missed to add a public-API method of extracting the responding IP address to 
the broadcast package. In 5.5 the netsnmp_udp_addr_pair struct was used in 
snmplib/snmpUDPDomain.cc, but that structure was never made public in any 
header file, so there was not way to get the IP address of the responding 
scanner.

In net-snmp 5.6, the new netsnmp_indexed_addr_pair struct provides access to 
that information, so I now increased the required net-snmp version to 5.6, as 
5.5 does not provide the required functionality...

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] New magicolor backend for inclusion in git

2011-01-30 Thread m. allan noah 
I'm trying to build this now on Fedora 14 with net-snmp enabled, and I
get the following error:

magicolor.c: In function 'mc_network_discovery_handle':
magicolor.c:1800:2: error: 'netsnmp_indexed_addr_pair' undeclared
(first use in this function)
magicolor.c:1800:2: note: each undeclared identifier is reported only
once for each function it appears in
magicolor.c:1800:29: error: 'responder' undeclared (first use in this function)
magicolor.c:1800:69: error: expected expression before ')' token
magicolor.c:1801:2: warning: ISO C90 forbids mixed declarations and code
magicolor.c: In function 'mc_network_discovery':
magicolor.c:1909:20: warning: pointer targets in assignment differ in signedness
magicolor.c:1910:2: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
/usr/include/string.h:399:15: note: expected 'const char *' but
argument is of type 'u_char *'
magicolor.c:1912:20: warning: assignment discards qualifiers from
pointer target type
make[2]: *** [libmagicolor_la-magicolor.lo] Error 1

And poking around in /usr/include/net-snmp reveals no definition for
netsnmp_indexed_addr_pair. This is using net-snmp 5.5, which seems
like it might still be a current release?

allan

On Tue, Jan 25, 2011 at 5:17 PM, Brian Shaver  wrote:
> These changes compiled fine for me on Fedora 13 x64.
> Thanks,
> Brian ..
>
> On Tue, Jan 25, 2011 at 3:38 PM, Reinhold Kainhofer  kainhofer.com>
> 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
>
>
> --
> 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] New magicolor backend for inclusion in git

2011-01-25 Thread Reinhold Kainhofer 
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] New magicolor backend for inclusion in git

2011-01-25 Thread 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] New magicolor backend for inclusion in git

2011-01-22 Thread Richard Ryniker 
Reinhold Kainhofer  wrote:

>If I use "unsigned char*", then I get no warning. However, I fail to see why 
>using an additional variable makes a difference...
>
>This does not work (&b[0] is a pointer to an unsigned char, right?):
>   unsigned char b[4];
>   htole32a(&b[0], value);
>
>while this does:
>   unsigned char b[4];
>   unsigned char *bp=&b[0];
>   htole32a(bp, value);

The first argument to htole32a must be an lvalue.  It is used in the
left-hand side of an assignment by htole32a; this is the exact meaning of
lvalue.

b[0] is an lvalue.  It is certainly well-defined to write something like:

b[0] = 2;

&b[0] looks like it should be the address of the first element of b, and
indeed it is, but it is not an lvalue: it does not denote a target (such
as a variable) to which some value may be assigned.  It is not a pointer
type, which can be dereferenced by the * operator. What is needed for the
first argument of htole32a is a pointer P that can be used in a statement
like:

*P = 2;

The statement:

unsigned char * bp=&b[0];

is well-defined: the variable bp is assigned a value which is the address
of the unsigned char b[0].  bp is an actual variable, therefore it is an
lvalue and an acceptable first argument to ntole32a.

A statement such as:

*&b[0] = 2;

is invalid according to the C language grammar (even if you, a human, can
say you know what it should mean).  That is why the compiler complains
when it parses:

htole32a(&b[0], value);

but the compiler is happy with the correct:

htole32a(bp, value);

because that expands into:

*bp = value;

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

2011-01-22 Thread Reinhold Kainhofer 
Am Donnerstag, 20. Januar 2011, um 21:26:42 schrieb m. allan noah:
> What if you make the pointer unsigned char instead?

If I use "unsigned char*", then I get no warning. However, I fail to see why 
using an additional variable makes a difference...

This does not work (&b[0] is a pointer to an unsigned char, right?):
   unsigned char b[4];
   htole32a(&b[0], value);

while this does:
   unsigned char b[4];
   unsigned char *bp=&b[0];
   htole32a(bp, value);

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).

Sorry for the breakage!
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] New magicolor backend for inclusion in git

2011-01-22 Thread m. allan noah 
A good portion of the problem may be GCC's optimization routines. As
the -O level rises, the compiler makes assumptions about things like
pointers which are more strict than the standard requires.
Unfortunately, these routines can become confused unless your code is
laid out very explicitly.

I think most backends do manual manipulation of char arrays. Look at
fujitsu-scsi.h for instance.

allan

On Sat, Jan 22, 2011 at 5:54 AM, Reinhold Kainhofer
 wrote:
> Am Donnerstag, 20. Januar 2011, um 21:26:42 schrieb m. allan noah:
>> What if you make the pointer unsigned char instead?
>
> If I use "unsigned char*", then I get no warning. However, I fail to see why
> using an additional variable makes a difference...
>
> This does not work (&b[0] is a pointer to an unsigned char, right?):
> ? unsigned char b[4];
> ? htole32a(&b[0], value);
>
> while this does:
> ? unsigned char b[4];
> ? unsigned char *bp=&b[0];
> ? htole32a(bp, value);
>
> 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).
>
> Sorry for the breakage!
> 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
>



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

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

2011-01-20 Thread Reinhold Kainhofer 
Am Donnerstag, 20. Januar 2011, um 18:13:09 schrieb Adrian Glaubitz:
> 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.

It fixes the error, but still adds a compiler warning about signedness...
I'm currently really thinking of getting rid of those htole32a calls and 
instead simply copying over all four bytes (in little endian) manually.

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] New magicolor backend for inclusion in git

2011-01-20 Thread Adrian Glaubitz 
Damn, I should have figured out the problem and written a patch yesterday
and I could have had my first contribution to SANE already :(. I actually
stumbled across this already yesterday when playing around with the
HP2410 code in the genesys backend.

But anyway, I hope it gets fixed anyway  ;).

Adrian

On Jan 20, 2011, at 8:11 PM, Brian Shaver wrote:

> 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  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
>

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

2011-01-20 Thread Reinhold Kainhofer 
Am Donnerstag, 20. Januar 2011, um 16:24:06 schrieb 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.

Yes, these warning/errors come from my new magicolor backend.
FWIW, I have been developing on a 32-bit KUbuntu Linux machine.


> 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'

Oops, that's a portability problem: How shall I print size_t objects with 
printf in SANE? A google search showed some people advocating the use of 
casting to unsigned long and printf'ing that:
printf("%lu\n", (unsigned long)x);
Shall I use that instead in SANE code?
Or is it possible to use the z modifier for size_t arguments (which is not 
C90, AFAICS)? i.e.
printf("%zu\n", x);


> 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

That line (and the other error in line 921) is simply calling the htole32a 
macro that is defined in byteorder.h (I didn't touch that one).
Apparently, on your system, htole32a does not like a void* pointer as its 
first argument. On my system, I tried using the same code as the epson2-ops.c 
file:
unsigned char params1[4];
htole32a(¶ms1[0], value);
but that gave me the compiler warning 

magicolor.c: In function 'cmd_start_scan':
magicolor.c:678: warning: dereferencing type-punned pointer will break strict-
aliasing rules

The code
unsigned char params1[4];
void *tmp = ¶ms1[0];
htole32a(tmp, value);
didn't give me any warnings and worked fine on my system.


> magicolor.c: In function 'mc_network_discovery':
> magicolor.c:1868: warning: unused parameter 'host'

That warning is there, because HAVE_LIBSNMP is not defined, so all of the 
commands in mc_network_discovery are commented out by a #if HAVE_LIBSNMP.

Unfortunately, the autofoo reconf seems to have missed to add the HAVE_LIBSNMP 
variable to configure.h.in (so SNMP was never enabled, even if you have the 
net-snmp development files installed). I'll commit a fix for that shortly, so 
that warning won't appear when you have the net-snmp library (and dev files) 
installed. If you don't have it, then you'll still get that warning.

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] New magicolor backend for inclusion in git

2011-01-20 Thread Adrian Glaubitz 
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 --
A non-text attachment was scrubbed...
Name: 0001-Fix-compile-errors-for-magicolor-backend.patch
Type: application/octet-stream
Size: 930 bytes
Desc: not available
URL:

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

2011-01-20 Thread Adrian Glaubitz 
Hi,

On Jan 20, 2011, at 4:24 PM, 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.
> 

I'm having exactly the same problem. I'm attaching my byteorder.h.

System is Debian Squeeze on amd64:

[glaubitz at sulphur:~]$ uname -a
Linux sulphur 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 
GNU/Linux
[glaubitz at sulphur:~]$ lsb_release -c
Codename:   squeeze

Adrian

-- next part --
A non-text attachment was scrubbed...
Name: byteorder.h
Type: application/octet-stream
Size: 4383 bytes
Desc: not available
URL: 

-- next part --

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

2011-01-20 Thread m. allan noah 
What if you make the pointer unsigned char instead?

allan

On Thu, Jan 20, 2011 at 3:20 PM, Reinhold Kainhofer
 wrote:
> Am Donnerstag, 20. Januar 2011, um 18:13:09 schrieb Adrian Glaubitz:
>> 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.
>
> It fixes the error, but still adds a compiler warning about signedness...
> I'm currently really thinking of getting rid of those htole32a calls and
> instead simply copying over all four bytes (in little endian) manually.
>
> 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
>



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

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

2011-01-20 Thread 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

2011-01-20 Thread m. allan noah 
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?

allan

On Thu, Jan 20, 2011 at 11:50 AM, Adrian Glaubitz
 wrote:
> Hi,
>
> On Jan 20, 2011, at 4:24 PM, 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.
>>
>
> I'm having exactly the same problem. I'm attaching my byteorder.h.
>
> System is Debian Squeeze on amd64:
>
> [glaubitz at sulphur:~]$ uname -a
> Linux sulphur 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 
> GNU/Linux
> [glaubitz at sulphur:~]$ lsb_release -c
> Codename: ? ? ? squeeze
>
> Adrian
>
>
>
>
>
>



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

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

2011-01-20 Thread m. allan noah 
what platform and cpu is this?

allan

On Thu, Jan 20, 2011 at 11:00 AM, Brian Shaver  wrote:
> 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]: 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 als

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

2011-01-20 Thread 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]: 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

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

2011-01-20 Thread m. allan noah 
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]: 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,
>

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

2011-01-20 Thread 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

2011-01-19 Thread m. allan noah 
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-connected magicolor device. I have set the timeout to a very low value (a
> little more than 1 second!), so all systems without a magicolor scanning in
> the network are not held up by the SNMP auto-detection of the magicolor
> devices.
> On the other hand, if the network is really slow, this might mean that we miss
> an SNMP response that takes longer than 1 second!
>
> What do you think of this backend?
>
> 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
>



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

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

2011-01-15 Thread m. allan noah 
On Fri, Jan 14, 2011 at 4:32 PM, Reinhold Kainhofer
 wrote:
> Am Freitag, 7. Januar 2011, um 02:34:20 schrieb m. allan noah:
>> I took a quick look at the code, and only see a few minor issues at
>> first glance.
>>
>> 1. MC_AutoDetectionTimeout is not configurable at runtime
>> 2. the code only calls sanei_usb_init during sane_init. This prevents
>> long-running programs like button press daemons from finding
>> hotplugged scanners. This was discussed recently on the list.
>> 3. Some of your Option Groups could get their names from saneopts.h
>> (SANE_NAME_GEOMETRY, TITLE, DESC, etc)
>>
>> Other than those things, it looks fine to me.
>
> Okay, here are updated patches (amended, so the whole backend is in one
> patch):
> http://www.fam.tuwien.ac.at/~reinhold/sane/magicolor_backend_patches/
>
> -) Patches 0001 and 0002 are the USB patches you already reviewed (with
> copyright notices added as you wanted), so they are ready to be applied.
>
> -) Patch 0003 fixes a compiler warning that macros like htobe16 (byteorder.h)
> etc. are already defined. In that case, don't overwrite the existing
> definitions. (Chris Bagwell okay'ed it)
>
> -) Patch 0004 is the actual backend
>
> -) Patch 0005 is an alternative to running autoreconf (No manual changes done
> by me!). This patch should probably not be applied to git master, but someone
> (Chris Bagwell already volunteered) should run autoreconf with the recommended
> auto(conf|make|...) versions for sane installed.
>
>
>
> Changes to patch 0003 are in detail (compared to the last version you looked
> at):
> -) All three timeouts (SNMP detection, scan data read, other scanner
> responses) are configurable in the magicolor.conf file
> -) Cleaned up the options, reused pre-defined values as much as possible
> -) Call sanei_usb_init also in get_devices
> -) get_devices does not erase the list of scanners any more, but keeps still-
> existing scanners untouched, just removes removed and adds new scanners.
>

Thank you very much for making those updates. I'll commit the code
this weekend, and take a swing at all the autofoo. I'll ask Chris for
help if required.

> There is, however, one issue that needs to be discussed in principle:
> How shall network auto-detection work in a sane way, once several backends
> support auto-detecting network-connected scanners? AFAICS, all backends are
> loaded sequentially, and the network auto-detection of each backend needs to
> wait for a certain time before timing out (even if one response was received,
> you have to wait the whole timeout, as there might be another device on the
> network).
> So, if 10 backends support auto-detection, and each uses a 2 second timeout,
> sane would have a startup time of >20 seconds... Clearly, that's not
> desirable.
>
> On Windows, that's not an issue, as the user only installs drivers for the
> scanners he really owns. However, sane provides all backends by default and
> runs each backend's initialization (get_devices), so here it is a problem.

Yes- the SUSE way is to comment out backends in dll.conf.
Unfortunately, we dont have a generic way to do that.

You should register for an alioth account, and request to join the
project, and I will ad you.

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

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

2011-01-14 Thread Reinhold Kainhofer 
Am Freitag, 7. Januar 2011, um 02:34:20 schrieb m. allan noah:
> I took a quick look at the code, and only see a few minor issues at
> first glance.
> 
> 1. MC_AutoDetectionTimeout is not configurable at runtime
> 2. the code only calls sanei_usb_init during sane_init. This prevents
> long-running programs like button press daemons from finding
> hotplugged scanners. This was discussed recently on the list.
> 3. Some of your Option Groups could get their names from saneopts.h
> (SANE_NAME_GEOMETRY, TITLE, DESC, etc)
> 
> Other than those things, it looks fine to me.

Okay, here are updated patches (amended, so the whole backend is in one 
patch):
http://www.fam.tuwien.ac.at/~reinhold/sane/magicolor_backend_patches/

-) Patches 0001 and 0002 are the USB patches you already reviewed (with 
copyright notices added as you wanted), so they are ready to be applied.

-) Patch 0003 fixes a compiler warning that macros like htobe16 (byteorder.h) 
etc. are already defined. In that case, don't overwrite the existing 
definitions. (Chris Bagwell okay'ed it)

-) Patch 0004 is the actual backend

-) Patch 0005 is an alternative to running autoreconf (No manual changes done 
by me!). This patch should probably not be applied to git master, but someone 
(Chris Bagwell already volunteered) should run autoreconf with the recommended 
auto(conf|make|...) versions for sane installed.



Changes to patch 0003 are in detail (compared to the last version you looked 
at):
-) All three timeouts (SNMP detection, scan data read, other scanner 
responses) are configurable in the magicolor.conf file
-) Cleaned up the options, reused pre-defined values as much as possible
-) Call sanei_usb_init also in get_devices
-) get_devices does not erase the list of scanners any more, but keeps still-
existing scanners untouched, just removes removed and adds new scanners.


There is, however, one issue that needs to be discussed in principle: 
How shall network auto-detection work in a sane way, once several backends 
support auto-detecting network-connected scanners? AFAICS, all backends are 
loaded sequentially, and the network auto-detection of each backend needs to 
wait for a certain time before timing out (even if one response was received, 
you have to wait the whole timeout, as there might be another device on the 
network). 
So, if 10 backends support auto-detection, and each uses a 2 second timeout, 
sane would have a startup time of >20 seconds... Clearly, that's not 
desirable.

On Windows, that's not an issue, as the user only installs drivers for the 
scanners he really owns. However, sane provides all backends by default and 
runs each backend's initialization (get_devices), so here it is a problem.

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] New magicolor backend for inclusion in git

2011-01-06 Thread m. allan noah 
I took a quick look at the code, and only see a few minor issues at
first glance.

1. MC_AutoDetectionTimeout is not configurable at runtime
2. the code only calls sanei_usb_init during sane_init. This prevents
long-running programs like button press daemons from finding
hotplugged scanners. This was discussed recently on the list.
3. Some of your Option Groups could get their names from saneopts.h
(SANE_NAME_GEOMETRY, TITLE, DESC, etc)

Other than those things, it looks fine to me.

allan

On Thu, Jan 6, 2011 at 4:39 PM, m. allan noah  wrote:
> Is the timeout controllable from the config file?
>
> 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-connected magicolor device. I have set the timeout to a very low value (a
>> little more than 1 second!), so all systems without a magicolor scanning in
>> the network are not held up by the SNMP auto-detection of the magicolor
>> devices.
>> On the other hand, if the network is really slow, this might mean that we 
>> miss
>> an SNMP response that takes longer than 1 second!
>>
>> What do you think of this backend?
>>
>> 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
>>
>
>
>
> --
> "The truth is an offense, but not a sin"
>



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

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

2011-01-06 Thread Reinhold Kainhofer 
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-connected magicolor device. I have set the timeout to a very low value (a 
little more than 1 second!), so all systems without a magicolor scanning in 
the network are not held up by the SNMP auto-detection of the magicolor 
devices.
On the other hand, if the network is really slow, this might mean that we miss 
an SNMP response that takes longer than 1 second!

What do you think of this backend?

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] New magicolor backend for inclusion in git

2011-01-06 Thread m. allan noah 
Is the timeout controllable from the config file?

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-connected magicolor device. I have set the timeout to a very low value (a
> little more than 1 second!), so all systems without a magicolor scanning in
> the network are not held up by the SNMP auto-detection of the magicolor
> devices.
> On the other hand, if the network is really slow, this might mean that we miss
> an SNMP response that takes longer than 1 second!
>
> What do you think of this backend?
>
> 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
>



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

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

2011-01-06 Thread Chris Bagwell 
I can commit on patches 0004 and 0005.

* 0004 looks OK to submit at any time.
* 0005 - I just updated the files in this area this week based on
Fedora 14's version of autofoo tools.  Compared to that update, you
have a newer version of autoconf then I do but a quite older version
of libtool.  On top of that, your update overwrote our hand patched
ltmain.sh file.

If you want to keep it simple, I suggest once you've submitted patch
0003 I can just regenerate all the Makefiles on your behalf.

Chris

On Thu, Jan 6, 2011 at 11:30 AM, 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-connected magicolor device. I have set the timeout to a very low value (a
> little more than 1 second!), so all systems without a magicolor scanning in
> the network are not held up by the SNMP auto-detection of the magicolor
> devices.
> On the other hand, if the network is really slow, this might mean that we miss
> an SNMP response that takes longer than 1 second!
>
> What do you think of this backend?
>
> 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
>