[sane-devel] problems with genesys and MD6228
Le Friday 13 June 2008 21:13:33 Werner Holtfreter, vous avez ?crit?: > Am Mittwoch, 11. Juni 2008 21:39:01 schrieb stef: > > so this isn't a USB_SUSPEND issue. Could you try your scanner at > > 100 dpi gray scan on a windows PC ? If so, you can check that the > > scanner is working (ie no hardware issue), then record the USB > > communication with the usb sniffer available at > > http://www.pcausa.com/Utilities/UsbSnoop/default.htm . Then send > > me the log file of a 100 pdi scan so that I check that your > > scanner has really the same hardware than mine. > > The scanner works on windows. I sent the UsbSnoop.log direct to you. > -- > Viele Gr??e > Werner Holtfreter Hello, thanks for the data. Unfortunately, the log is too small. A typical log should be a few MB big. For instance I recorded a preview and 100 dpi gray scan a couple centimeters high, and that led to a 22 MB log. I'm going to analyze the log I done to try to find a bug in the backend. But if you can produce a more complete windows log, I'd be able to compare it with the one I have to find if we have similar or slightly different hardware. Regards, Stef
[sane-devel] anyone working on Lexmark X2330 support?
Hi. On Sat, 14 Jun 2008 19:37:10 +0800 Paul Wise wrote: > Hi all, > > [Please CC me in all replies] > > I've had a Lexmark X2330 sitting next to the family Windows box for a > couple of years, figured it was time to make it work in Linux. > > Is anyone else working on Lexmark X2330 support? > > The protocol seems fairly simple at first glance, so it shouldn't be > much work if no-one has attempted to get it working yet. > I tried to hack compression algo used on Lexmark lx2480 without success. I sort of gave up because it turned out being so difficult to get any sort of "controlled data" out of it. Every scan is different and lexmark drivers only saves in lossy image format, making comparison difficult. Tying some of the data pins high/low might help with this to some degree. It didn't appear to be adaptive IIRC. http://lists.alioth.debian.org/pipermail/sane-devel/2007-October/020075.html has some speculation and some data if you want to compare. -- Aapo Tahkola
[sane-devel] Python bindings segfault
While testing sane python bindings I found a segmentation fault while trying to open the device. I attach a couple of logs. 'sane.log' is the output of running: SANE_DEBUG_HP5590=50 SANE_DEBUG_SANEI_USB=255 ./test-sane.py 'valgrind.log' is the output of running my test script with "valgrind --trace-children=yes" The script is very simple (the device exists): import sane sane.init() sane.open( 'hp5590:libusb:004:005' ) This is running Debian unstable with the following packages: python-imaging-sane 1.1.6 sane 1.0.14 libsane 1.0.19 plus -deb packages, as as you can see in valgrind.log Do you think this is a Debian specific problem, any other tests I could make? -- Albert Cervera i Areny http://www.NaN-tic.com -- next part -- A non-text attachment was scrubbed... Name: sane.log.bz2 Type: application/x-bzip2 Size: 3890 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080615/e1c7c0a7/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: valgrind.log.bz2 Type: application/x-bzip2 Size: 4820 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080615/e1c7c0a7/attachment-0001.bin
[sane-devel] Python bindings segfault
A Diumenge 15 Juny 2008, Albert Cervera i Areny va escriure: > This is running Debian unstable with the following packages: > python-imaging-sane 1.1.6 > sane 1.0.14 > libsane 1.0.19 > plus -deb packages, as as you can see in valgrind.log I meant "-dbg" pacakges, of course. > > Do you think this is a Debian specific problem, any other tests I could > make? -- Albert Cervera i Areny http://www.NaN-tic.com
[sane-devel] Python bindings segfault
On 15.06.2008 14:56, Albert Cervera i Areny wrote: > While testing sane python bindings I found a segmentation fault while trying > to open the device. I attach a couple of logs. > > 'sane.log' is the output of running: > SANE_DEBUG_HP5590=50 SANE_DEBUG_SANEI_USB=255 ./test-sane.py > > 'valgrind.log' is the output of running my test script > with "valgrind --trace-children=yes" > > The script is very simple (the device exists): > > import sane > sane.init() > sane.open( 'hp5590:libusb:004:005' ) Am I right that this is the complete Pytjon code leading to the segfault? > > This is running Debian unstable with the following packages: > python-imaging-sane 1.1.6 > sane 1.0.14 > libsane 1.0.19 > plus -deb packages, as as you can see in valgrind.log > > Do you think this is a Debian specific problem, any other tests I could make? Unfortunately, the C extension _sane.so does not automatically ensure the correct sequence of the calls sane_close() and sane_exit(). (sane_close should be called for all opened devices before sane_exit; if sane_close is called after sane_exit, weird things may happen) sane_close isn't even called automatically -- you must do that explicitly. Could you try something like import sane sane.init() device = sane.open( 'hp5590:libusb:004:005' ) device.close() If this does not help, can you send me gdb's "bt" output? Abel PS: This requirement to explicitly call device.close() bothers me since years, but I never got of my ass to write a more "pythonic" implementation of _sane.c ...
[sane-devel] problems with genesys and MD6228
Am Sonntag, 15. Juni 2008 07:12:50 schrieb stef: > thanks for the data. Unfortunately, the log is too small. A > typical log should be a few MB big. For instance I recorded a > preview and 100 dpi gray scan a couple centimeters high, and that > led to a 22 MB log. > > I'm going to analyze the log I done to try to find a bug in the > backend. But if you can produce a more complete windows log, I'd > be able to compare it with the one I have to find if we have > similar or slightly different hardware. Hello Stef, here are the next 3 experiments with UsbSnoop: 1 all from plug in 2 prescan and scann 3 only scann, 100 dpi, gray, full A4. Odd, the snoop-log grew while the mouse was moving, but not while the scanning! Of course, the marker "installed" was set only on the line "USB scanner". (Files direct to you.) -- Viele Gr??e Werner Holtfreter