Re: [sane-devel] libsane udev rule
If you only have one scanner, you don't need to name the device.
Where do you see those libusb error messages?
allan
On Tue, Jun 10, 2014 at 4:57 PM, gobo wrote:
> thanks for the reply.
>
> changed my approach and used scanimage -f "%d" to capture the device
> in my script. this works well enough since i have only one scanner.
>
> is there a way to suppress the
>
> libusb couldn't open USB device /dev/bus/usb/001/001: Permission denied.
> libusb requires write access to USB device nodes.
>
> messages libusb puts out? not a problem, just an annoyance.
>
>
> thanks.
>
>
> On 6/9/14, Olaf Meeuwissen wrote:
>> gobo writes:
>>
>>> generally, i know how to write udev rules. but i'm not sure how to
>>> write one for libsane.
>>>
>>> scanimage -L returns something like:
>>> device `canon_dr:libusb:001:002' is a CANON DR-2580C scanner
>>>
>>> where the 001:002 is always changing. :005, :008, etc.
>>>
>>> so in 55-libsane.rules there is:
>>> # Canon DR-2580C
>>> ATTR{idVendor}=="04a9", ATTR{idProduct}=="1608", MODE="0664",
>>> GROUP="lp", ENV{libsane_matched}="yes"
>>>
>>> what do i add to the rule to force this device to always have the same
>>> libusb name?
>>
>> In short, you can't.
>>
>> You can assign a value to the SYMLINK key in a udev rule. That will
>> dutifully create a device with that name no matter what bus and device
>> number it has. However, as long as the canon_dr backend (or probably
>> most any backend) creates device names using the bus and device numbers,
>> you are out of luck.
>>
>> Hope this clarifies,
>> --
>> Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
>> FSF Associate Member #1962 Help support software freedom
>> http://www.fsf.org/jf?referrer=1962
>>
>
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to sane-devel-requ...@lists.alioth.debian.org
--
"The truth is an offense, but not a sin"
--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-requ...@lists.alioth.debian.org
Re: [sane-devel] libsane udev rule
thanks for the reply.
changed my approach and used scanimage -f "%d" to capture the device
in my script. this works well enough since i have only one scanner.
is there a way to suppress the
libusb couldn't open USB device /dev/bus/usb/001/001: Permission denied.
libusb requires write access to USB device nodes.
messages libusb puts out? not a problem, just an annoyance.
thanks.
On 6/9/14, Olaf Meeuwissen wrote:
> gobo writes:
>
>> generally, i know how to write udev rules. but i'm not sure how to
>> write one for libsane.
>>
>> scanimage -L returns something like:
>> device `canon_dr:libusb:001:002' is a CANON DR-2580C scanner
>>
>> where the 001:002 is always changing. :005, :008, etc.
>>
>> so in 55-libsane.rules there is:
>> # Canon DR-2580C
>> ATTR{idVendor}=="04a9", ATTR{idProduct}=="1608", MODE="0664",
>> GROUP="lp", ENV{libsane_matched}="yes"
>>
>> what do i add to the rule to force this device to always have the same
>> libusb name?
>
> In short, you can't.
>
> You can assign a value to the SYMLINK key in a udev rule. That will
> dutifully create a device with that name no matter what bus and device
> number it has. However, as long as the canon_dr backend (or probably
> most any backend) creates device names using the bus and device numbers,
> you are out of luck.
>
> Hope this clarifies,
> --
> Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
> FSF Associate Member #1962 Help support software freedom
> http://www.fsf.org/jf?referrer=1962
>
--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-requ...@lists.alioth.debian.org
Re: [sane-devel] CANOSCAN 8400F
On 04/06/2014 12:22, Myroslav Kavatsyuk wrote:
Dear Stef,
thanks a lot for your suggestions and scripts. The more I dig into the
source code, the more
questions I have. Here they are:
1) file genesys_devices.c, definition of Genesys_Model
canon_8400f_model (line 1691). I realized that the dpi list does not
correspond to the model (CS8400F has maximum resolution of 3200dpi).
- Shell I change the array with values available in the windows driver
of the scanner? Is the length of the array fixed?
You may do such. But be aware that the resolution advertised by the
windows driver GUI are usually different from the DPI used to do the
scan. It is safer to work with resolution you find in USB log, or
resolution derived for other working ones. Try to do USB log of
resolution matching physical hardware, or divided by a round factor.
The length is fixed, and has a MAX_RESOLUTIONS size.
- Are the other values extracted from some logs, or shell I
disassemble unit to measure all constants (position of white strip)?
Tune scanarea geometry only when you have made scan working. No
need to dismantle your scanner, change all offsets to be zero (in
genesys_device.c), and it will scan itself where you cannot see.
- I have performed test scan with resolution of 100dpi of size 10x10
cm (specified with -x -y option). The resulting image had proper
number of lines/rows (393), proper aspect ratio. However, the scan are
was about 15x15 cm. I assume this has something to do with wrong array
with dpi setting...
BTW, you can find GL843 datasheet on internet, it will help you
understand what all the registers are for. Real dpi is a combination of
sensor DPISET, deletion factor and exposure.
2) genesys_gl843.h, There is definition of the Sensor_Profile sensors.
For the CS8400F there is defined array (line 666). I logged several
scans with different dpi settings using usbsnoop. After processing
logs with your script I found that there are different possible values
reported for the sensor_profile and motor_profile. This profiles do
not coincide with the one in the genesys_gl843.h. Here are ones,
extracted from the logs:
sensor_profile { sensor_id, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168,
0,0x,
0xfeff, 0xfeff, 0xfeff,
0x, 0x01, 0x02, 0x, 0x,
{0x, 0x, 0x,
0x, 0x, 0x, 0x33,
0x0c, 0x13, 0x, 0x30, 0x, 0x00, 0x84, },
{0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,0x,0x40,0x00,0x00,0x,0x85,},
}
sensor_profile { sensor_id, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168,
0,0x,
0xfeff, 0xfeff, 0xfeff,
0x, 0x01, 0x02, 0x, 0x,
{0x, 0x, 0x,
0x, 0x, 0x, 0x33,
0x0c, 0x13, 0x, 0x30, 0x, 0x00, 0x84, },
{0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,0x,0x40,0x00,0x00,0x,0x88,},
},
sensor_profile { sensor_id, dpi, 22000, 0x0, 0xff, 0x0, 5168, 0,0x2a,
0x 0, 0x 0, 0x 0, 0x, 0x07, 0x08, 0x,
0x,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3b, 0x0c, 0x10, 0x2a, 0x30,
0x00, 0x00, 0x9a, },
{0x01,0x04,0x07,0x0a,0x0d,0x10,0x1b,0x00,0x40,0x00,0x00,0x,0x88,},
},
sensor_profile { sensor_id, dpi, 10800, 0xe3f, 0x0, 0x1b6db, 5168, 0,0x2a,
0x 0, 0x 0, 0x 0, 0x, 0x01, 0x02, 0x,
0x,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x0c, 0x13, 0x2a, 0x30,
0x00, 0x00, 0x84, },
{0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,0x00,0x40,0x00,0x00,0x,0x88,},
},
sensor_profile { sensor_id, dpi, 14400, 0x1ff, 0x0, 0x24924, 5168, 0,0x2a,
0x 0, 0x 0, 0x 0, 0x, 0x00, 0x01, 0x,
0x,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x0c, 0x11, 0x2a, 0x30,
0x00, 0x00, 0x84, },
{0x0b,0x0e,0x11,0x02,0x05,0x08,0x63,0x00,0x40,0x00,0x00,0x,0x88,},
},
sensor_profile { sensor_id, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168, 0,0x2a,
0x 0, 0x 0, 0x 0, 0x, 0x01, 0x02, 0x,
0x,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x0c, 0x13, 0x2a, 0x30,
0x00, 0x00, 0x84, },
{0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,0x00,0x40,0x00,0x00,0x,0x85,},
}
They are all different. Do you have any suggestions what to do with
this? For each sensor_profile there is a motor_profile. They have the
following structure:
motor_profile={id,7200,2, {0, 0, ..} all skipped numbers are zeros
(in contrast to one in the genesys_gl843.h, line 677). The second
number coincides with the first number reported in the sensor_profile.
I would appreciate you suggestions for f
Re: [sane-devel] genesys Canon Lide 210 aspect-ratio-problem at 600 dpi
On 04/06/2014 22:48, M G Berberich wrote: Hello, Am Montag, den 02. Juni schrieb Stef: I have fixed the issue of distorted pictures in grey mode for DPI >= 600 dpi. I have also fixed 600 dpi accurracy problem. All these fixes are available in SANE's git source tree, with genesys backend internal build version 2504. 600 dpi lineart and gray scans work fine now. Thanks a lot. Am Sonntag, den 11. Mai schrieb Andrew Kanaber: Am Montag, den 05. Mai schrieb Stef: M G Berberich wrote: 2400 dpi and 4800 dpi do not work at all, but never did. 2400 and 4800 dpi scans works on my LiDE 210. So I'd need some logs or better information on what is not working for you. For what it's worth I also see 2400dpi and 4800dpi working fine on my LiDE 110, and producing correct (undistorted) aspect ratio. 2400 dpi and 4800 dpi still do not work at all on my LiDE 210. MfG bmg Hello, could you send me a test case where 2400 dpi scan doesn't work as a scanimage command ? For instance something like: export SANE_DEBUG_GENESYS=255 export SANE_DEBUG_GENESYS_LOW=255 export SANE_DEBUG_GENESYS_GL124=255 scanimage -d genesys --clear-calibration --width 50.0 --height 50.0 --resolution 2400 --mode Gray 2>scan.log >scan.pnm changing scan parameters an color mode. Then send me the scan.log and scan.pnm files, and scan parameters son I can try to run the same in my dev environment and have a chance to reproduce it? Regards, Stef -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
