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
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
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.
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
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
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
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);
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
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
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
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
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
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
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
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
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:
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 ;).
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;
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
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
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.
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
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
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
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
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
26 matches
Mail list logo
