[sane-devel] New magicolor backend for inclusion in git
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
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 shakerlxxv at gmail.com wrote: These changes compiled fine for me on Fedora 13 x64. Thanks, Brian .. On Tue, Jan 25, 2011 at 3:38 PM, Reinhold Kainhofer reinhold at 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
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
These changes compiled fine for me on Fedora 13 x64. Thanks, Brian .. On Tue, Jan 25, 2011 at 3:38 PM, Reinhold Kainhofer reinhold at kainhofer.comwrote: 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: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110125/a7405643/attachment.htm
[sane-devel] New magicolor backend for inclusion in git
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
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 reinhold at kainhofer.com 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
Reinhold Kainhofer reinhold at kainhofer.com 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
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 kitno455 at gmail.com 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 reinhold at kainhofer.com 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
[sane-devel] New magicolor backend for inclusion in git
what is in your sane-backends/include/byteorder.h file? allan On Thu, Jan 20, 2011 at 10:24 AM, Brian Shaver shakerlxxv at gmail.com 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 kitno455 at gmail.com 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 reinhold at kainhofer.com 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
[sane-devel] New magicolor backend for inclusion in git
I've attached the byteorder.h file. Brian .. On Thu, Jan 20, 2011 at 10:31 AM, m. allan noah kitno455 at gmail.com wrote: what is in your sane-backends/include/byteorder.h file? allan On Thu, Jan 20, 2011 at 10:24 AM, Brian Shaver shakerlxxv at gmail.com 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 kitno455 at gmail.com 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 reinhold at kainhofer.com 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:
[sane-devel] New magicolor backend for inclusion in git
what platform and cpu is this? allan On Thu, Jan 20, 2011 at 11:00 AM, Brian Shaver shakerlxxv at gmail.com wrote: I've attached the byteorder.h file. Brian .. On Thu, Jan 20, 2011 at 10:31 AM, m. allan noah kitno455 at gmail.com wrote: what is in your sane-backends/include/byteorder.h file? allan On Thu, Jan 20, 2011 at 10:24 AM, Brian Shaver shakerlxxv at gmail.com 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 kitno455 at gmail.com 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 reinhold at kainhofer.com 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
[sane-devel] New magicolor backend for inclusion in git
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: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110120/811fe65c/attachment.obj -- next part --
[sane-devel] New magicolor backend for inclusion in git
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 glaubitz at physik.fu-berlin.de 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
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: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110120/4d498a31/attachment.obj
[sane-devel] New magicolor backend for inclusion in git
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(params1[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 = params1[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
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: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110120/ea65a8c7/attachment-0001.htm
[sane-devel] New magicolor backend for inclusion in git
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 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
[sane-devel] New magicolor backend for inclusion in git
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
What if you make the pointer unsigned char instead? allan On Thu, Jan 20, 2011 at 3:20 PM, Reinhold Kainhofer reinhold at kainhofer.com 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
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 reinhold at kainhofer.com 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
On Fri, Jan 14, 2011 at 4:32 PM, Reinhold Kainhofer reinhold at kainhofer.com 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
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
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
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 reinhold at kainhofer.com 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
[sane-devel] New magicolor backend for inclusion in git
Is the timeout controllable from the config file? allan On Thu, Jan 6, 2011 at 12:30 PM, Reinhold Kainhofer reinhold at kainhofer.com 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
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 kitno455 at gmail.com wrote: Is the timeout controllable from the config file? allan On Thu, Jan 6, 2011 at 12:30 PM, Reinhold Kainhofer reinhold at kainhofer.com 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
