[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] Canon PIXMA MX870
On Sun, 2011-01-16 at 02:04 -0800, Kenton Varda wrote: I leave your first question for Nicolas to answer. I don't understand the backend well enough to dig into this part. sorry for the late reply, I have been out of the country for a few days and busy with work... Unfortunately, there is another, less-deterministic problem. It seems that the scanner very frequently refuses sane's TCP connections: [pixma] Reader task terminated Scanned page 1. (scanner status = 5) Scanning page 2 [pixma] Reader task id=14568 (forked) [pixma] Reader task started [pixma] sanei_bjnp_activate (0) [pixma] udp_command: Sending UDP command to 10.0.1.22:8612 [pixma] bjnp_open_tcp: Can not connect to scanner: Connection refused [pixma] sanei_bjnp_deactivate (0) [pixma] udp_command: Sending UDP command to 10.0.1.22:8612 [pixma] [pixma] Reader task terminated: EINVAL read_image():reader task closed the pipe:0 bytes received, 10718400 bytes expected scanimage: sane_read: Invalid argument Scanned page 2. (scanner status = 4) [pixma] pixma_close(): Canon PIXMA MX870 [pixma] sanei_bjnp_close(0): It's hard to pin down a pattern describing when this happens, but: - It never happens if the scanner was just powered on (and had time to boot). Or in other words, power cycling the scanner fixes problems, suggesting that the scanner is getting into a bad state. I have seen cases before where we got stuck opening a TCP connection where the scanner got confused. Your guess is most likely correct. - It always happens when the ADF runs out of paper. sane appears to form a new connection for each page. After the last page, sane tries to connect again even though there are no more pages, and this connection always fails AFAICT. This causes scanimage to exit with an error code even though technically it completed its task successfully. - After having completed a batch, the scanner is sometimes (but not always) left in a state where all further connections are refused until the device is power-cycled. Sometimes the device will recover from this state magically without a power cycle, if I retry a few times. Sometimes running Scangear MP can revive the device from this state, but not always. - I changed the TCP connection code to retry once, and the result is even odder: The retry sometimes succeeds, but then the scanner apparently does not reply to any requests on the new connection. I has a look at the bjnp code again, but can not check details as some of the information is missing. Can you please get me a log file with log-level 14 or (maybe even better) a wireshark trace? I am especially interested to see what the unknown1 value of the last UDP command is before we try to open the TCP connection. I have never seen it set, but that may be due to the fact that I don't have an ADFIt may be that your scanner uses that unknown stuff to signal that is is not ready to read more data. It may also be that we need to teach the higher level of the backend when no more pages will be available. Does a USB connection behave any better? I tried comparing network dumps between SANE and Scangear MP, but they were completely different. Scangear MP appears to make only one TCP connection for the whole batch, rather than one per page. That is due to the fact that the backend closes the bjnp connection (like if does for the USB-connection). Any ideas? Please provide some detailed traces so we can see what is happening best regards, Louis
[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] Canon PIXMA MX870
Hi Louis, Sorry, but after fighting with this scanner for all of last weekend and realizing just how pitiful Canon's Linux support is, I returned it and bought an HP instead. The HP works perfectly with Sane. I do have quite a few debug logs recorded and it looks like the unknown1 value in the job details response is always zero. I actually added some code to write out the members of the struct in addition to the raw bytes, so this is pretty easy to grep for. I've attached two logs. In the first one, the scanner successfully scanned three pages (and then refused the connection for the fourth page, because there was no physical fourth page). In the second one, the scanner refuses to connect on the first page, presumably because it has been left in a bad state. Of course, since I don't have this scanner anymore I don't expect anyone to actually look at these. -Kenton On Sat, Jan 22, 2011 at 7:32 AM, Louis Lagendijk louis at lagendijk.xs4all.nlwrote: On Sun, 2011-01-16 at 02:04 -0800, Kenton Varda wrote: I leave your first question for Nicolas to answer. I don't understand the backend well enough to dig into this part. sorry for the late reply, I have been out of the country for a few days and busy with work... Unfortunately, there is another, less-deterministic problem. It seems that the scanner very frequently refuses sane's TCP connections: [pixma] Reader task terminated Scanned page 1. (scanner status = 5) Scanning page 2 [pixma] Reader task id=14568 (forked) [pixma] Reader task started [pixma] sanei_bjnp_activate (0) [pixma] udp_command: Sending UDP command to 10.0.1.22:8612 [pixma] bjnp_open_tcp: Can not connect to scanner: Connection refused [pixma] sanei_bjnp_deactivate (0) [pixma] udp_command: Sending UDP command to 10.0.1.22:8612 [pixma] [pixma] Reader task terminated: EINVAL read_image():reader task closed the pipe:0 bytes received, 10718400 bytes expected scanimage: sane_read: Invalid argument Scanned page 2. (scanner status = 4) [pixma] pixma_close(): Canon PIXMA MX870 [pixma] sanei_bjnp_close(0): It's hard to pin down a pattern describing when this happens, but: - It never happens if the scanner was just powered on (and had time to boot). Or in other words, power cycling the scanner fixes problems, suggesting that the scanner is getting into a bad state. I have seen cases before where we got stuck opening a TCP connection where the scanner got confused. Your guess is most likely correct. - It always happens when the ADF runs out of paper. sane appears to form a new connection for each page. After the last page, sane tries to connect again even though there are no more pages, and this connection always fails AFAICT. This causes scanimage to exit with an error code even though technically it completed its task successfully. - After having completed a batch, the scanner is sometimes (but not always) left in a state where all further connections are refused until the device is power-cycled. Sometimes the device will recover from this state magically without a power cycle, if I retry a few times. Sometimes running Scangear MP can revive the device from this state, but not always. - I changed the TCP connection code to retry once, and the result is even odder: The retry sometimes succeeds, but then the scanner apparently does not reply to any requests on the new connection. I has a look at the bjnp code again, but can not check details as some of the information is missing. Can you please get me a log file with log-level 14 or (maybe even better) a wireshark trace? I am especially interested to see what the unknown1 value of the last UDP command is before we try to open the TCP connection. I have never seen it set, but that may be due to the fact that I don't have an ADFIt may be that your scanner uses that unknown stuff to signal that is is not ready to read more data. It may also be that we need to teach the higher level of the backend when no more pages will be available. Does a USB connection behave any better? I tried comparing network dumps between SANE and Scangear MP, but they were completely different. Scangear MP appears to make only one TCP connection for the whole batch, rather than one per page. That is due to the fact that the backend closes the bjnp connection (like if does for the USB-connection). Any ideas? Please provide some detailed traces so we can see what is happening best regards, Louis -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110122/3c11d688/attachment-0001.htm -- next part -- A non-text attachment was scrubbed... Name: mydebug1.log Type: text/x-log Size: 6834121 bytes Desc: not available URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110122/3c11d688/attachment
