[sane-devel] problems with genesys and MD6228

2008-06-15 Thread stef
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?

2008-06-15 Thread Aapo Tahkola
Hi.

On Sat, 14 Jun 2008 19:37:10 +0800
Paul Wise pabs3 at bonedaddy.net 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

2008-06-15 Thread Albert Cervera i Areny
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

2008-06-15 Thread Albert Cervera i Areny
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

2008-06-15 Thread abel deuring
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

2008-06-15 Thread Werner Holtfreter
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