[sane-devel] Canon Canoscan Lide50 broken in 1.0.21 ...
Hi Stef, ahh, thanks for the reply. 1.0.22 from your PPA seems to work! In case they are of interest, I have attached the debug logs for all three versions I tested. I have no idea, whether this is significant, but one difference I saw was a line concerning the invocation of "gl841_init_motor_regs_scan": [genesys_gl841] gl841_init_motor_regs_scan : scan_exposure_time=5600, scan_yres=300, scan_step_type=1, scan_lines=3531, scan_dummy=0, feed_steps=373, scan_power_mode=0, flags=0 For 1.0.20 and 1.0.22, flags is set to 0, whereas it is set to 2 in 1.0.21. Ok, so lets see, if can get it work again on that armel system. Kind regards, Mali Am 03.01.2011 22:08, schrieb stef: > Le Monday 03 January 2011 13:57:35 Mali, vous avez ?crit : >> Hi, >> >> as of 1.0.21 support for Lide 50 (genesys backend) seems to be broken. >> >> Scanning in gray or lineart mode makes the head move a little bit (some >> millimeters), stay in that position and make a high-frequency noise for >> some time and then return to the starting position. As to my >> understanding the head is positioned at the starting position for the >> actual scan, the scan itself fails. The resulting image is completely >> black. >> >> When scanning in color mode, the behaviour is different. The head >> actually moves during scanning. It looks like it is moving at twice the >> intended speed: When the whole page has been scanned, it can be seen in >> "Simple Scan" compressed to half the normal height. The head continues >> to move against a mechanical stop inside the scanner for the some time, >> producing the other half of the image in "Simple Scan" (and a noise even >> uglier than the one above). >> >> I am quite sure that I have seen the gray/lineart behaviour in color >> mode, too, but at the moment cannot explain what triggers either of the >> failure modes. >> >> I am trying this on a Ubuntu Maverik x86_64 system. Debian Squeeze >> (x86_64 and Armel) behave the same. Frontends used were Simple Scan and >> scanimage. >> >> After going back from libsane 1.0.21-2ubuntu2 to 1.0.20-13ubuntu2, >> everything again works as normal. So, to me, it looks like something >> might have changed from 1.0.20 to 1.0.21 breaking the compatibility with >> the older scanners. >> >> As far as I see, others are affected by the same problem: >> >> https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/680892 >> >> http://lists.alioth.debian.org/pipermail/sane-devel/2010-August/027343.html >> >> Otherwise, I found no indication this behaviour has been discussed on >> this list. >> >> Maybe, it already to late for 1.0.22, but hopefully the working state >> can be restored. >> >> Kind regards, >> >> Mali >> >> >> >> -- >> 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 > Hello, > > thanks for the bug report. Since you can run a working and a non working > version, it would be higly interesting to run scanimage with debug enabled > with bot versions so that I can try to compare bog debug traces and find what > is going on. > You'll enable debug log by doing in a command shell: > export SANE_DEBUG_GENESYS=255 > export SANE_DEBUG_GENESYS_LOW=255 > export SANE_DEBUG_GENESYS_GL841=255 > then by running scanimage in the same command shell: > scanimage -d genesys>scan.pnm 2>debug.log > You'll need the debug version of the packages. Send both debug.log > files. > > Last you may try a recent package at https://launchpad.net/~stef- > dev/+archive/sane-backend-genesys so you'll can check if the bug is still > present in the git tree. > > Regards, > Stef -- next part -- A non-text attachment was scrubbed... Name: debug-1.0.20.log.bz2 Type: application/x-bzip Size: 9842 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110104/b7053844/attachment-0003.bin> -- next part -- A non-text attachment was scrubbed... Name: debug-1.0.21.log.bz2 Type: application/x-bzip Size: 9948 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110104/b7053844/attachment-0004.bin> -- next part -- A non-text attachment was scrubbed... Name: debug-1.0.22.log.bz2 Type: application/x-bzip Size: 7876 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110104/b7053844/attachment-0005.bin>
[sane-devel] Epson Stylus SX100 not detected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.01.2011 23:08, schrieb m. allan noah: > are you trying this as root? > As normal user and as root. Same results (should have mentioned that). Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNI57OAAoJEH5ihYAc9I7c314H/iEtYdZcmZcbwPZ+gFSvU1/5 C6LQm0pkK8ZOpsBitb0kmAwWqq9sEAYDP05OUyir0mS+10a6ChIDoe3s6KLqEPRw XvLJlJaa56S0mqslwNOTBPfqZP/gRBycsyxDVGtLiO6RSYxnolrgJU+TRBPoPy0f mPUVBdkSYGxmHShYmoc3xVL7Yt/DNsdo75UeaZm/CgZnULdWG6+nrdAUxySbQMh7 /saz6hqD1bTanoQ24zW1rfTOEN7tM2sGrELh+7VvHkg0Y385fSJ7Ajti4zMhNRmf r5YC2PxH4nxOMxnmmz0MhL7LIZuLhmqyPabtDjlRT0FrBR0EiNzCaokCw5Bx1yQ= =O4k4 -END PGP SIGNATURE-
[sane-devel] Epson Stylus SX100 not detected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey everyone, I hope this is the right place for my question. I fetched and build sane from git. sane-config --version says I am running 1.0.22. On http://www.sane-project.org/sane-mfgs.html#Z-EPSON Stylus SX100 is listed as good. I am running the Ubuntu 10.04 as amd64. The printer is auto detected by Ubuntu, so i guess it is connected. Despite that, sane-find-scanner does not detect my SX100. What am I missing? Kind regards Jan Murawski -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNI5QQAAoJEH5ihYAc9I7cQlYH+gMHqFuR0isKFsRAn3+SVyVU 2OcMTLMJvHd7/budjoPQEyTCDKY80RiIlccaYkzqPXfGTg+hDHJpLRqc4+uSzXjD CfOxH5QNURfUofLLWwSHUDpuFYjWEbawQHmQg66DA2hqiP7Y+lrjXrGYqyStP68B YeUbOYCOB3U3zd5z3LuDpKSMWQA7Hrc2PpThGXWK6C0QCpP8aebbfHPIpnOZa2oP XsGF/9KzxTOveb7+PF6o1u1o70C7l/nl2xKN5hjzqrw/V4YA1nFi6eS7BSNmZDSG EjUhtgvV53LefJZNPWGG1lqtPPY15YqQXLrVxc8D8Uh7e5icUJwttcUP434LQzI= =3gUj -END PGP SIGNATURE-
[sane-devel] Fwd: sanei_usb limitations
Am Samstag, 27. November 2010, um 00:10:54 schrieb m. allan noah: > Reinhold Kainhofer has recently worked up a patch with an alternative > implementation of your idea- and there was some discussion about yet a > third mechanism, which relies on a 'setting' function to be called > prior to transferring the data, much as the existing timeout control > code works. I think that would be the best choice, not sure if > Reinhold has gotten a chance to work on it. I have now updated my patch to also include a callback function to sanei_usb_open_extended, which is called before all available endpoints are listed. Patch is here: http://codereview.appspot.com/2823041/ The callback function (if given) is called for each combination of USB_DIR_IN/USB_DIR_OUT and USB_ENDPOINT_TYPE_CONTROL/USB_ENDPOINT_TYPE_ISOCHRONOUS/USB_ENDPOINT_TYPE_BULK/USB_ENDPOINT_TYPE_INTERRUPT. If a value >0 is returned, it is used as the default endpoint of that type (instead of the first encountered endpoint of that type). The old functionality of an additional argument to each usb read/write function to explicitly override the endpoint for a single transaction is still there, so one can now override the default used for all transfers as well as the endpoint for a single transfer. Any comments? Of course, I would love to get this into the 1.0.22 release, so other backends that need different endpoints for different communication types finally have this functionality available. 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] Fwd: sanei_usb limitations
On Tue, Jan 4, 2011 at 8:01 PM, Reinhold Kainhofer wrote: > Am Dienstag, 4. Januar 2011, um 22:19:16 schrieb m. allan noah: >> I think your previous idea of adding a a new function to set the >> currently 'active' endpoint would be simpler. > > Actually, that was never my idea for overriding the endpoints for a single > transactions, only for setting the global defaults. For the defaults, it is > definitely cleaner/easier to use one function to set the default endpoints. certainly easier than a callback, but really you don't need the defaults to be changed once you have the ability to override it on a per-call basis. > For overriding the ep of a single transaction I don't like this approach too > much. Having to call a setter function first to set a global variable, before > you do the actual function call is highly thread-unsafe, and I would prefer to > pass the ep right to the function itself. Yes- it does seem cleaner to pass the ep to the function, but I'm not sure about your threading argument. You are pretty sure to break something if you've got two threads talking to the scanner at the same time. > >> something like: >> >> /*endpoint types*/ >> #define SANEI_USB_BULK_OUT 0 >> #define SANEI_USB_BULK_IN ?1 >> ... > > What do you have against bitmasks like (USB_DIR_IN | USB_ENDPOINT_TYPE_BULK)? > Then we don't need any new constants... where are USB_DIR_IN and USB_ENDPOINT_TYPE_BULK defined? :) allan -- "The truth is an offense, but not a sin"
[sane-devel] Adding 700F/5600F to the gensys backend
Le Friday 31 December 2010 13:36:20 Stefan Larsson, vous avez ?crit : > Thank you for the information. > > I have extracted some information but it is a bit unclear how to proceed. I > need to be able to isolate which portions are doing what. How do you > usually perform the analysis in an efficient manner? Since I am totally > unfamiliar with the protocol I am not sure how to start finding the > appropriate information. > > All the files are present in the attached file. Check readme.txt for > further information. > > I also contacted Canon Sweden to ask for any technical information or a > contact person which may simplify things. The support issue just got > escalated to another department. We will see what that could give. > > /Stefan > Hello, the decoded windows log seems to be missing the first URB when scanner is plugged. Important things happen then. You should logged it at least once. It helps determining the memory layout, the initial reigster set and the starting GPIO. Try to record it, then the first step you could try is to adjust the registers for the memory layout. There is a table 'layouts' in genesys_gl847.h where you should tune registers d0-d2, e0-e7 based on the value you'll find in the decoded log. The next step would be the GPIO, the registers to look are used in gl847_init_pio(), have special care for REG6C occurences. Regards, Stef
[sane-devel] Epson Stylus SX100 not detected
[sanei_usb] sanei_usb_init: SANE is built without support for libusb you need to install libusb-devel package, then reconfigure, remake, reinstall sane-backends. allan On Tue, Jan 4, 2011 at 6:40 PM, Jan Murawski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am 04.01.2011 23:58, schrieb m. allan noah: >> sane-find-scanner does not even use sane libraries to detect scanners, >> it just asks the OS for a list of possible devices. Is there anything >> else installed on the machine which would block access to the device? >> > > The device shows up when using lsusb but sane-find-scanner can not find it. > Any ideas what could be blocking it? > > > Jan > > > (Sorry, skipped the list) > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJNI6/pAAoJEH5ihYAc9I7cFygH/i2s8QrT6BN9ibBPkU/ceUL5 > EIlwgbG0t2pI6MCWurB20fbtwPGiLhmKWCjw5l3AJHeogAn9+1LUy0GFQtYh4wGM > CadEgOTyskKjznMfltk2i7fEvaH2w6xJZaqfM4fqTK9ePyU4RvzBafNaJQ1bmOpu > OmVodJSDX7qcxl090aAQZUkU4jSjEN9iRfC0On02jhH/F7bt7RlMOhIgXAqTMVMc > hhLpnWkIQuMVvcBvLtffi6nbQy5X9TheiZDCdy5yO/UX91DD/3X1KX8IsjQaKRvu > 5IohxR29WbELm7eRs1ye9AfatLIzQ+FEgu5+RFHhkOw4x1L5VZeHt0R5gHJre84= > =UHTp > -END PGP SIGNATURE- > -- "The truth is an offense, but not a sin"
[sane-devel] Epson Stylus SX100 not detected
as root run the following, all on one line: SANE_DEBUG_SANEI_USB=15 sane-find-scanner hopefully the error messages will give some hint. allan On Tue, Jan 4, 2011 at 6:40 PM, Jan Murawski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am 04.01.2011 23:58, schrieb m. allan noah: >> sane-find-scanner does not even use sane libraries to detect scanners, >> it just asks the OS for a list of possible devices. Is there anything >> else installed on the machine which would block access to the device? >> > > The device shows up when using lsusb but sane-find-scanner can not find it. > Any ideas what could be blocking it? > > > Jan > > > (Sorry, skipped the list) > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJNI6/pAAoJEH5ihYAc9I7cFygH/i2s8QrT6BN9ibBPkU/ceUL5 > EIlwgbG0t2pI6MCWurB20fbtwPGiLhmKWCjw5l3AJHeogAn9+1LUy0GFQtYh4wGM > CadEgOTyskKjznMfltk2i7fEvaH2w6xJZaqfM4fqTK9ePyU4RvzBafNaJQ1bmOpu > OmVodJSDX7qcxl090aAQZUkU4jSjEN9iRfC0On02jhH/F7bt7RlMOhIgXAqTMVMc > hhLpnWkIQuMVvcBvLtffi6nbQy5X9TheiZDCdy5yO/UX91DD/3X1KX8IsjQaKRvu > 5IohxR29WbELm7eRs1ye9AfatLIzQ+FEgu5+RFHhkOw4x1L5VZeHt0R5gHJre84= > =UHTp > -END PGP SIGNATURE- > -- "The truth is an offense, but not a sin"
[sane-devel] Epson Stylus SX100 not detected
sane-find-scanner does not even use sane libraries to detect scanners, it just asks the OS for a list of possible devices. Is there anything else installed on the machine which would block access to the device? allan On Tue, Jan 4, 2011 at 5:27 PM, Jan Murawski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am 04.01.2011 23:08, schrieb m. allan noah: >> are you trying this as root? >> > > As normal user and as root. Same results (should have mentioned that). > > Jan > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJNI57OAAoJEH5ihYAc9I7c314H/iEtYdZcmZcbwPZ+gFSvU1/5 > C6LQm0pkK8ZOpsBitb0kmAwWqq9sEAYDP05OUyir0mS+10a6ChIDoe3s6KLqEPRw > XvLJlJaa56S0mqslwNOTBPfqZP/gRBycsyxDVGtLiO6RSYxnolrgJU+TRBPoPy0f > mPUVBdkSYGxmHShYmoc3xVL7Yt/DNsdo75UeaZm/CgZnULdWG6+nrdAUxySbQMh7 > /saz6hqD1bTanoQ24zW1rfTOEN7tM2sGrELh+7VvHkg0Y385fSJ7Ajti4zMhNRmf > r5YC2PxH4nxOMxnmmz0MhL7LIZuLhmqyPabtDjlRT0FrBR0EiNzCaokCw5Bx1yQ= > =O4k4 > -END PGP SIGNATURE- > > -- > 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] trying Canon DR-5060-F
Hi, thank you for the new version. The scan is not exactly what it should be (see the file test5.tar.gz). The scanned image is not at the right position. Probably a shift problem. Note that for all the tests I've done it was a A4 paper and the Canon DR-5060-F is a A3 scanner. the file test5.tar.gz can be downloaded here : http://dl.free.fr/baKWwnrcy Christophe. Le 04/01/2011 16:23, m. allan noah a ?crit : > here is a new version of two files. use these to replace your existing > copies, and recompile. This should contain all of your current fixes, > and it should (hopefully) produce proper grayscale scans. > > If you can test this also in lineart mode, it might need the same > width fix as grayscale... > > allan > > On Tue, Jan 4, 2011 at 4:33 AM, Christophe Largeau (liste) > wrote: >> Thank you for the information, waiting for your fix. >> >> Christophe. >> >> Le 03/01/2011 20:03, m. allan noah a ?crit : >>> >>> It appears that the corrupt image is because the scanner sends us 1728 >>> pixels per line, but we asked for only 1700. Likely this means that >>> the scanner is limited to image widths which are a multiple of 32 >>> pixels. I will see if I can come up with a fix. >>> >>> allan >>> >>> On Mon, Jan 3, 2011 at 12:54 PM, m. allan noah >>> wrote: jpg destroys too much image information. Any chance to can compress the pnm instead, and send that to me directly? allan On Mon, Jan 3, 2011 at 12:11 PM, Christophe Largeau (liste) wrote: > > OK, > > my A4 page (basically 0.5 millimeter squares) has been processed > > you can view the result here > http://i37.servimg.com/u/f37/15/57/48/39/test3p10.jpg : not really the > expected result ;) > > You'll find the compressed test3.log attached to this message. > > Do you need other informations for ssm_df() and ssm_do() debugging ? > > Christophe. > > Le 03/01/2011 17:45, m. allan noah a ?crit : >> >> Ah- same thing, this time also comment out ssm_df(). It would be nice >> to get those two commands working for your machine (if they are >> supported by the hardware), but they are not required for proper >> functioning. >> >> allan >> >> On Mon, Jan 3, 2011 at 11:40 AM, Christophe Largeau (liste) >> wrote: >>> >>> Here is the new test2.log ;) >>> >>> Christophe. >>> >>> Le 03/01/2011 17:31, m. allan noah a ?crit : Excellent. set_window is now accepted by the scanner, but it does not like our ssm_do() call. So, edit canon_dr.c around line 3273, and comment out the call to ssm_do(). Then try again with test2 :) allan On Mon, Jan 3, 2011 at 11:19 AM, Christophe Largeau (liste) wrote: > > Hi, > > change, recompile and test done. > > The test1pnm file is empty. > > The compressed test1.log is attached to this message. > > Christophe. > > Le 03/01/2011 16:50, m. allan noah a ?crit : >> >> ok- can you make some changes, recompile, and test? >> >> canon_dr.c in function set_window, around line 3615 comment out >> these >> lines: >> >> set_WD_brightness (desc1, s->brightness+128); >> set_WD_threshold (desc1, s->threshold); >> set_WD_contrast (desc1, s->contrast+128); >> >> Then compile, copy the library, and scan again, using this command: >> >> SANE_DEBUG_CANON_DR=30 scanimage --resolution 200 --mode Gray >>> >>> test1pnm 2>test1.log >> >> Hopefully test1.pnm will contain an image. If not, compress the log >> and send it to me. >> >> allan >> >> On Mon, Jan 3, 2011 at 10:11 AM, m. allan noah >> wrote: >>> >>> Yes- I can see some set window data in it, though I am not sure it >>> is >>> complete. This sniffer program seems to miss some of the data. I >>> will >>> look some more today. >>> >>> allan >>> >>> On Mon, Jan 3, 2011 at 8:06 AM, Christophe Largeau (liste) >>> wrote: Hi, have you checked the log ? Is it helpful ? Christophe. Le 29/12/2010 17:04, Christophe Largeau (liste) a ?crit : > > Thank you. > > Note that I'll be away until next monday. > > Christophe. > > Le 29/12/2010 17:00, m. allan noah a ?crit : >> >> Thanks. I'll look at it tonight. >> >> allan >> >> On Wed, Dec 29, 2010 at 10:07 AM, Christophe Largeau (liste) >>
[sane-devel] Epson Stylus SX100 not detected
are you trying this as root? allan On Tue, Jan 4, 2011 at 4:41 PM, Jan Murawski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey everyone, > > I hope this is the right place for my question. > > I fetched and build sane from git. > sane-config --version says I am running 1.0.22. > On http://www.sane-project.org/sane-mfgs.html#Z-EPSON Stylus SX100 is > listed as good. > I am running the Ubuntu 10.04 as amd64. > The printer is auto detected by Ubuntu, so i guess it is connected. > > Despite that, sane-find-scanner does not detect my SX100. What am I missing? > > Kind regards > Jan Murawski > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJNI5QQAAoJEH5ihYAc9I7cQlYH+gMHqFuR0isKFsRAn3+SVyVU > 2OcMTLMJvHd7/budjoPQEyTCDKY80RiIlccaYkzqPXfGTg+hDHJpLRqc4+uSzXjD > CfOxH5QNURfUofLLWwSHUDpuFYjWEbawQHmQg66DA2hqiP7Y+lrjXrGYqyStP68B > YeUbOYCOB3U3zd5z3LuDpKSMWQA7Hrc2PpThGXWK6C0QCpP8aebbfHPIpnOZa2oP > XsGF/9KzxTOveb7+PF6o1u1o70C7l/nl2xKN5hjzqrw/V4YA1nFi6eS7BSNmZDSG > EjUhtgvV53LefJZNPWGG1lqtPPY15YqQXLrVxc8D8Uh7e5icUJwttcUP434LQzI= > =3gUj > -END PGP SIGNATURE- > > -- > 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] Fwd: sanei_usb limitations
I think your previous idea of adding a a new function to set the
currently 'active' endpoint would be simpler. something like:
/*endpoint types*/
#define SANEI_USB_BULK_OUT 0
#define SANEI_USB_BULK_IN 1
...
sanei_usb_set_endpoint(SANE_Int dn, SANE_Int endpoint_type, SANE_Int
endpoint_number){
switch/case setting devices[devcount].
}
Then you've only got one new function, and no other code changes?
allan
On Tue, Jan 4, 2011 at 4:01 PM, Reinhold Kainhofer
wrote:
> Am Samstag, 27. November 2010, um 00:10:54 schrieb m. allan noah:
>> Reinhold Kainhofer has recently worked up a patch with an alternative
>> implementation of your idea- and there was some discussion about yet a
>> third mechanism, which relies on a 'setting' function to be called
>> prior to transferring the data, much as the existing timeout control
>> code works. I think that would be the best choice, not sure if
>> Reinhold has gotten a chance to work on it.
>
> I have now updated my patch to also include a callback function to
> sanei_usb_open_extended, which is called before all available endpoints are
> listed.
> Patch is here:
> http://codereview.appspot.com/2823041/
>
> The callback function (if given) is called for each combination of
> USB_DIR_IN/USB_DIR_OUT and
> USB_ENDPOINT_TYPE_CONTROL/USB_ENDPOINT_TYPE_ISOCHRONOUS/USB_ENDPOINT_TYPE_BULK/USB_ENDPOINT_TYPE_INTERRUPT.
> If a value >0 is returned, it is used as the default endpoint of that type
> (instead of the first encountered endpoint of that type).
>
> The old functionality of an additional argument to each usb read/write
> function to explicitly override the endpoint for a single transaction is still
> there, so one can now override the default used for all transfers as well as
> the endpoint for a single transfer.
>
> Any comments? Of course, I would love to get this into the 1.0.22 release, so
> other backends that need different endpoints for different communication types
> finally have this functionality available.
>
> 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] trying Canon DR-5060-F
Thank you for the information, waiting for your fix. Christophe. Le 03/01/2011 20:03, m. allan noah a ?crit : > It appears that the corrupt image is because the scanner sends us 1728 > pixels per line, but we asked for only 1700. Likely this means that > the scanner is limited to image widths which are a multiple of 32 > pixels. I will see if I can come up with a fix. > > allan > > On Mon, Jan 3, 2011 at 12:54 PM, m. allan noah wrote: >> jpg destroys too much image information. Any chance to can compress >> the pnm instead, and send that to me directly? >> >> allan >> >> On Mon, Jan 3, 2011 at 12:11 PM, Christophe Largeau (liste) >> wrote: >>> OK, >>> >>> my A4 page (basically 0.5 millimeter squares) has been processed >>> >>> you can view the result here >>> http://i37.servimg.com/u/f37/15/57/48/39/test3p10.jpg : not really the >>> expected result ;) >>> >>> You'll find the compressed test3.log attached to this message. >>> >>> Do you need other informations for ssm_df() and ssm_do() debugging ? >>> >>> Christophe. >>> >>> Le 03/01/2011 17:45, m. allan noah a ?crit : Ah- same thing, this time also comment out ssm_df(). It would be nice to get those two commands working for your machine (if they are supported by the hardware), but they are not required for proper functioning. allan On Mon, Jan 3, 2011 at 11:40 AM, Christophe Largeau (liste) wrote: > > Here is the new test2.log ;) > > Christophe. > > Le 03/01/2011 17:31, m. allan noah a ?crit : >> >> Excellent. set_window is now accepted by the scanner, but it does not >> like our ssm_do() call. So, edit canon_dr.c around line 3273, and >> comment out the call to ssm_do(). Then try again with test2 :) >> >> allan >> >> On Mon, Jan 3, 2011 at 11:19 AM, Christophe Largeau (liste) >> wrote: >>> >>> Hi, >>> >>> change, recompile and test done. >>> >>> The test1pnm file is empty. >>> >>> The compressed test1.log is attached to this message. >>> >>> Christophe. >>> >>> Le 03/01/2011 16:50, m. allan noah a ?crit : ok- can you make some changes, recompile, and test? canon_dr.c in function set_window, around line 3615 comment out these lines: set_WD_brightness (desc1, s->brightness+128); set_WD_threshold (desc1, s->threshold); set_WD_contrast (desc1, s->contrast+128); Then compile, copy the library, and scan again, using this command: SANE_DEBUG_CANON_DR=30 scanimage --resolution 200 --mode Gray > > test1pnm 2>test1.log Hopefully test1.pnm will contain an image. If not, compress the log and send it to me. allan On Mon, Jan 3, 2011 at 10:11 AM, m. allan noah wrote: > > Yes- I can see some set window data in it, though I am not sure it is > complete. This sniffer program seems to miss some of the data. I will > look some more today. > > allan > > On Mon, Jan 3, 2011 at 8:06 AM, Christophe Largeau (liste) > wrote: >> >> Hi, >> >> have you checked the log ? Is it helpful ? >> >> Christophe. >> >> Le 29/12/2010 17:04, Christophe Largeau (liste) a ?crit : >>> >>> Thank you. >>> >>> Note that I'll be away until next monday. >>> >>> Christophe. >>> >>> Le 29/12/2010 17:00, m. allan noah a ?crit : Thanks. I'll look at it tonight. allan On Wed, Dec 29, 2010 at 10:07 AM, Christophe Largeau (liste) wrote: > > the trace.wsl file taken from the snifer is attached to this > message. > > Christophe. > > > Le 29/12/2010 15:38, m. allan noah a ?crit : >> >> the sniffer utility: >> >> >> >> >> ftp://ftp.compuware.com/pub/driverstudio/outgoing/utility/wdmsniffer.zip >> >> >> We need to use that to capture traffic of a low-resolution black >> and >> white >> scan. >> >> I cannot give more specific instructions, because I rarely use >> this >> program. >> >> allan >> >> On Wed, Dec 29, 2010 at 9:29 AM, Christophe Largeau (liste) >> wrote: >>> >>> I will replug the scsi card into the orignal windows machine. >>> Do >>> you have >>> instruction for the log capture on windows ? >>> >>
[sane-devel] trying Canon DR-5060-F
Hi, I've done another test today (the test3pnm file was deleted). You can download the file test4.tar.gz (test4.pnm and tes4t.log) here http://dl.free.fr/b25kqUna1 You'll have to follow the link "T?l?charger ce fichier" Christophe. Le 03/01/2011 18:54, m. allan noah a ?crit : > jpg destroys too much image information. Any chance to can compress > the pnm instead, and send that to me directly? > > allan > > On Mon, Jan 3, 2011 at 12:11 PM, Christophe Largeau (liste) > wrote: >> OK, >> >> my A4 page (basically 0.5 millimeter squares) has been processed >> >> you can view the result here >> http://i37.servimg.com/u/f37/15/57/48/39/test3p10.jpg : not really the >> expected result ;) >> >> You'll find the compressed test3.log attached to this message. >> >> Do you need other informations for ssm_df() and ssm_do() debugging ? >> >> Christophe. >> >> Le 03/01/2011 17:45, m. allan noah a ?crit : >>> >>> Ah- same thing, this time also comment out ssm_df(). It would be nice >>> to get those two commands working for your machine (if they are >>> supported by the hardware), but they are not required for proper >>> functioning. >>> >>> allan >>> >>> On Mon, Jan 3, 2011 at 11:40 AM, Christophe Largeau (liste) >>> wrote: Here is the new test2.log ;) Christophe. Le 03/01/2011 17:31, m. allan noah a ?crit : > > Excellent. set_window is now accepted by the scanner, but it does not > like our ssm_do() call. So, edit canon_dr.c around line 3273, and > comment out the call to ssm_do(). Then try again with test2 :) > > allan > > On Mon, Jan 3, 2011 at 11:19 AM, Christophe Largeau (liste) > wrote: >> >> Hi, >> >> change, recompile and test done. >> >> The test1pnm file is empty. >> >> The compressed test1.log is attached to this message. >> >> Christophe. >> >> Le 03/01/2011 16:50, m. allan noah a ?crit : >>> >>> ok- can you make some changes, recompile, and test? >>> >>> canon_dr.c in function set_window, around line 3615 comment out these >>> lines: >>> >>> set_WD_brightness (desc1, s->brightness+128); >>> set_WD_threshold (desc1, s->threshold); >>> set_WD_contrast (desc1, s->contrast+128); >>> >>> Then compile, copy the library, and scan again, using this command: >>> >>> SANE_DEBUG_CANON_DR=30 scanimage --resolution 200 --mode Gray test1pnm 2>test1.log >>> >>> Hopefully test1.pnm will contain an image. If not, compress the log >>> and send it to me. >>> >>> allan >>> >>> On Mon, Jan 3, 2011 at 10:11 AM, m. allan noah >>> wrote: Yes- I can see some set window data in it, though I am not sure it is complete. This sniffer program seems to miss some of the data. I will look some more today. allan On Mon, Jan 3, 2011 at 8:06 AM, Christophe Largeau (liste) wrote: > > Hi, > > have you checked the log ? Is it helpful ? > > Christophe. > > Le 29/12/2010 17:04, Christophe Largeau (liste) a ?crit : >> >> Thank you. >> >> Note that I'll be away until next monday. >> >> Christophe. >> >> Le 29/12/2010 17:00, m. allan noah a ?crit : >>> >>> Thanks. I'll look at it tonight. >>> >>> allan >>> >>> On Wed, Dec 29, 2010 at 10:07 AM, Christophe Largeau (liste) >>> wrote: the trace.wsl file taken from the snifer is attached to this message. Christophe. Le 29/12/2010 15:38, m. allan noah a ?crit : > > the sniffer utility: > > > > > ftp://ftp.compuware.com/pub/driverstudio/outgoing/utility/wdmsniffer.zip > > > We need to use that to capture traffic of a low-resolution black > and > white > scan. > > I cannot give more specific instructions, because I rarely use > this > program. > > allan > > On Wed, Dec 29, 2010 at 9:29 AM, Christophe Largeau (liste) > wrote: >> >> I will replug the scsi card into the orignal windows machine. >> Do >> you have >> instruction for the log capture on windows ? >> >> Christophe. >> >> Le 29/12/2010 15:22, m. allan noah a ?crit : >>> >>> hmm- it is mad about something we ask it to do in the set >>> window >>> command. I don't have a protocol manual for this machine, so >>> we
