[sane-devel] LiDE 90 half ccd
Hello, No progress on 2400dpi. DPIHW is 2400 and dpiset 600 for a 300dpi scan. Don't know where to look yet for that problem ! about byte nibbles modifying reg_0x79 from 0x3f to 0x3e (very few contrasted image) or 0x40(black image) gives me bad images !!! What is effect of this register on clk3 ?? It's very sensible. Ideas ? regards, Guillaume
[sane-devel] Question about Genesys_Frontend
Guillaume Gastebois schrieb:
Hello,
In genesys backend, we can find :
typedef struct
{
u_int8_t reg[4];
u_int8_t sign[3];
u_int8_t offset[3];
u_int8_t gain[3];
u_int8_t reg2[3];
} Genesys_Frontend;
but in WM8199 regs don't have the same name.
For me registers addresses are :
reg[0]=0x01,reg[1]=0x02,reg[2]=0x03,reg[3]=0x06,
sign[0]=?,sign[1]=?,sign[2]=?,
offset[0]=0x20,offset[1]=0x21,offset[2]=0x22,
gain[0]=0x28,gain[1]=0x29,gain[2]=0x2a,
reg2[0]=0x08,reg2[1]=0x09,reg2[2]=?,
I anybody able to replace ? and/or correct mistakes in text before ?
There are some AFEs that use these registers, and some, that don't. If
the windows driver does not set them, most likely they are not
used/defined and ignored by the AFE. So it should be safe to set them to 0.
Thanks
Regards
Guillaume
Regards,
Pierre
[sane-devel] (no subject)
Guillaume Gastebois schrieb:
Hello,
Is there a possibility to determine a maximum of parameter like :
typedef struct
{
int optical_res; (OK, for me 2400)
int black_pixels;(don't know how to determine)
int dummy_pixel; (content of 0x34 ?)
int CCD_start_xoffset; (test of page upper border ?)
The ccd line first gives a few dummy pixels, then there are a few black
pixels, to enable the afe to do per-line black level compensation.
CCD_start_xoffset counts into one of these. I didn't need to change
these, yet.
int sensor_pixels; (just 216/2.54*2400 ?)
i would think so.
int fau_gain_white_ref; (don't know how to determine)
int gain_white_ref;(don't know how to determine)
the two above are used in calibration of some gl646-models.
u_int8_t regs_0x08_0x0b[4]; (OK windows snoop)
u_int8_t regs_0x10_0x1d[14]; (OK windows snoop)
u_int8_t regs_0x52_0x5e[13]; (OK windows snoop)
float red_gamma; (don't know how to determine)
float green_gamma; (don't know how to determine)
float blue_gamma;(don't know how to determine)
As ccd cells are largely linear in response, these should very probably
be 1.0. But i don't know if they are even used. Anyways, gamma tables
are definitely not used for 16bit modes on gl841/2.
u_int16_t *red_gamma_table; (OK NULL)
u_int16_t *green_gamma_table;(OK NULL)
u_int16_t *blue_gamma_table; (OK NULL)
} Genesys_Sensor;
or :
typedef struct
{
SANE_Int base_ydpi;(4800 ? : Lide90 is 2400x4800)
SANE_Int optical_ydpi; (4800 ? : Lide90 is 2400x4800)
SANE_Int max_step_type;(don't know how to determine)
SANE_Int power_mode_count; (don't know how to determine)
Genesys_Motor_Slope slopes[2][3]; (don't know how to determine)
} Genesys_Motor;
Unless you figure out multiple power modes, power_mode_count needs to be
set to 1. This is intended for scanners that can use a reduced power
mode for smoother head moves, when speed is not needed(high resolution
scans with slow moving head).
The stepper motors used are capable of doing full steps or half steps,
most of the time. the gl842 handles quarter step, gl843 seems to handle
eighth step, too. This is reflected by max_step_type:
max_step_type ! smallest steps
0 ! full
1 ! half
2 ! quarter
3 ! eighth
base_ydpi is very probably 2400 dpi. manufacturers tend to go by the
maximum possible value, which would be 4800 when using a 2400 dpi
full-step drive in half-step mode. The relationship between
optical_ydpi, max_step_type and base_ydpi is thus:
optical_ydpi = base_ydpi * 2 ^ max_step_type
The slopes-array is fixed to 2x3, but the used size is:
slopes[power_mode_count][max_step_type+1]
Each slope describes a speed slope for a specific motor setting. These
slopes are needed for acceleration/deceleration of the scanning head, as
the stepper motors are not powerful enough to get the head to full
speed in a single step.
The backend selects one fitting the requested mode, higher power mode
indexes give better quality but less speed, same with step modes,
although higher step modes(higher step divider) may be forced by the
requested mode(2400 ydpi on my scanner forces half step mode, because
full steps only do 1200dpi).
The gl84x reads the time it needs to wait between each step from a table
submitted by the backend. Thus, the units of the slopes reflects this:
All speeds are merely times between steps.
maximum_start_speed is the maximum speed this slope can start at. This
is the maximum speed the head can reach from a stand-still.
maximum_speed is the maximum final speed, after doing acceleration. The
backend may generate a slope that does stay slower than any one of
these, but it will do a slope when the head needs to go faster than
maximum_start_speed. The minimum_steps gives how many steps a
acceleration to maximum_speed needs to take. When the head does not need
to reach this speed, the backend may decide to take fewer steps. g
brings some non-linearity.
The values here can be found by experiment, or by analyzing the slope
tables from an usb log. The values from the windows driver may be a bit
conservative. When experimenting, one would decrease the values of
maximum_speed, maximum_start_speed and minimum_steps until the head
fails to speed up, and then increase them a bit. Positioning the scanner
such that the head goes upwards gives a nice safety margin while
experimenting. A final warning: when doing this, you may destroy your
scanner. Although i doubt that the loud noises from a not-moving head
stem from slipping gears, but instead from the stepper motor itself
oscillating back and forth.
Guillaume Gastebois schrieb:
Hello,
I remember that LiDE 90 is a 2400DPI scanner. And I did nothing in code to
port
that. I backend ready for
[sane-devel] LiDE 90 half ccd
Guillaume Gastebois schrieb: Hello, No progress on 2400dpi. DPIHW is 2400 and dpiset 600 for a 300dpi scan. Don't know where to look yet for that problem ! I'd try to get a log from a 2400dpi scan from windows and compare. about byte nibbles modifying reg_0x79 from 0x3f to 0x3e (very few contrasted image) or 0x40(black image) gives me bad images !!! What is effect of this register on clk3 ?? It's very sensible. register 0x77 to 0x79 describe a bitmask, that determines when the clk3 signal is high or low. For 0x0003f(lsb is register 0x79), this would give: time=== ! next pixel bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 ___ ___ |___| | 0x40 is this: bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 _ _ ___| |_| | As you can see, this gives a very short pulse, which will probably not be recognized by the ccd, while 0x3e just shortens the clock pulse at the beginning. The datasheet mentions that the scanner does not need to use the full 18 bits of the bitmask, but uses the first 6, 12 or 18 bits depending on the scanning mode. 12 seems to be correct for the mode the backend programs for cis scanners. Please try if modifying bitmask for clk4(0x7a to 0x7c iirc) shows any effects. Also, other values you may want to try on clk3: 0xff03f, 0xff801f, 0xffc00f. Another thing to try may be to send two clock pulses, for example 0x001c7. If clk3 is connected to the ccd, this may give interesting results(like, reducing the resolution by half), but for the 4-bit latch/D-FlipFlop, only the last clock pulse before the gl841 samples the data bits is relevant. regards, Guillaume Regards, Pierre
[sane-devel] Doubt about sane_get_devices
well, it appears that the sanei_usb support library intentionally does not re-gather the list of devices. This makes sense in the average sane installation, cause dozens of backends each gather the list within a fraction of a second, as the dll backend cycles thru them. in your case, it is the wrong behaviour, since the long-running daemon needs to know the list has changed. I think i can change the current code to retry occasionally. allan On Thu, Apr 24, 2008 at 11:58 PM, m. allan noah kitno455 at gmail.com wrote: ahh, but you dont just query the list again, you call sane_exit and sane_init first. just call sane_get_devices, and see if that helps. allan On 4/24/08, tobias alarcon extobias at gmail.com wrote: Nop, doesnt work. Maybe im doing something wrong. I got this logs. Log 1 ##Start the program with scanner disconnected [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu] find_scanners: start [fujitsu] find_scanners: reading config file fujitsu.conf [fujitsu] find_scanners: setting buffer-size to 65536 [fujitsu] find_scanners: looking for 'scsi FUJITSU' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1041' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1042' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1095' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1096' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1097' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ad' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ae' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10af' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e0' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e1' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e7' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10f2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10fe' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1135' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x114d' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1155' [fujitsu] find_scanners: found 0 scanner(s) [fujitsu] find_scanners: finish [fujitsu] sane_get_devices: finish ##Connect scanner and wait a seconds, query list [fujitsu] sane_exit: start [fujitsu] sane_exit: finish [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu] find_scanners: start [fujitsu] find_scanners: reading config file fujitsu.conf [fujitsu] find_scanners: setting buffer-size to 65536 [fujitsu] find_scanners: looking for 'scsi FUJITSU' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1041' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1042' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1095' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1096' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1097' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ad' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ae' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10af' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e0' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e1' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e7' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10f2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10fe' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1135' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x114d' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1155' [fujitsu] find_scanners: found 0 scanner(s) [fujitsu] find_scanners: finish [fujitsu] sane_get_devices: finish [fujitsu] sane_exit: start [fujitsu] sane_exit: finish Log 2 [doors at localhost ~]$ export SANE_DEBUG_FUJITSU=30 [doors at localhost ~]$ doors [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu]
[sane-devel] How do I scan as a normal user?
man sane-usb you need to change perms in /proc/bus/usb/ or in /dev/bus/usb, these are usually manage by udev. allan On 4/25/08, Marc Shapiro mshapiro_42 at yahoo.com wrote: I recently purchased an EPSON CX7400 All-In-One and it prints and copies great. Scanning has been a problem. I am running Debian Etch and have sane and xsane installed. Until this evening I could not get sane to recognize that I had a scanner installed at all. I'm not sure what changed that, but it now recognizes the scanner if I run scanimage, or xscanimage as root, but NOT if I run as a normal user. Running xsane as root gives me warnings that this is not a good idea. I would much rather run as a normal user. I have added scanner0 to /dev/.static/dev (that is probably what made it start to work at all) and I have changed its ownership to root:scanner with permissions of 664. I am in the scanner group, so I expected to be able to use it as non-root. Do I need to reboot for this to take effect. What else do I need to do to run xscanimage as non-root? All help will be appreciated. -- Marc Shapiro mshapiro_42 at yahoo.com -- 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] Calling a script after USB scanner is plugged
Am Donnerstag, 24. April 2008 schrieb Julien BLACHE:
Johannes Meixner jsmeix at suse.de wrote:
Hi,
Be careful with the labels you use. Always use a unique label name, or
you're asking for troubles. (been there, done that, accidentally
rendered a number of systems unbootable due to that ...)
Many thanks for this enlightening info!
Impressive: A thoroughly thought out fail-safe design!
udev is an incredible piece of crap, but the good news is that this
piece of crap is mostly stable those days. Which is a big step forward
already.
(and I'll refrain from saying anything at all about the genius who
invented udev. I'll just mention that he's also the author of stable
API is a nonsense.)
I can only guess that what udev actually does is to
concatenate all udev rules files into one single set
of rules and then it is not surprising when arbitrary
nonsense happens depending on which individual udev rules
files exist on a particular system which depends on which
individual software packages are installed on this system.
You got it.
Very nice to debug!
deWHAT?
I tried that before after I saw the z60_libsane.rules
ACTION!=add, GOTO=post_lamp_off
SYSFS{idVendor}==1606, SYSFS{idProduct}==0010, MODE=0664,
GROUP=scanner, NAME=umax%n, RUN+=/usr/local/bin/umax1220u start,
ENV{lamp_off}=yes
LABEL=post_lamp_off
But given the events, it is obvious not surprising that this is not
working.
Is anybody aware of a more elegant solution for this problem?
You need to copy a bit more than that from. See the top of the file,
there's more to it than that, also the way to identify a USB device
event changed starting with 2.6.22 and the rules are
backward-compatible in this respect too.
You cannot have udev and elegant at the same time
Actually, you can, but you need a bit of udev/uevent knowledge and
some time on your hands.
and you cannot have HAL and elegant at the same time.
It's all HALegant, pff.
Welcome to udev-land, Johannes!
The script works now reasonably robust (for now) when I plug the USB scanner.
My problem is though, that the script does not get called when I boot the
system and the scanner is plugged already during bootup. Why is this?
I call the script using
blackbox:~# cat /etc/udev/rules.d/z_local.rules
ACTION==add, SYSFS{idVendor}==1606, SYSFS{idProduct}==0010, MODE=0664,
GROUP=scanner, NAME=umax%n, RUN+=/usr/local/bin/umax1220u start,
ENV{lamp_off}=yes
blackbox:~#
/etc/init.d/udev restart does not call the script either.
Any ideas what I am missing are welcome...
Thanks,
Rainer
--
Rainer Dorsch
L?rchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch at web.de
jabber: rdorsch at jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
[sane-devel] Calling a script after USB scanner is plugged
Rainer Dorsch rdorsch at web.de wrote: Hi, The script works now reasonably robust (for now) when I plug the USB scanner. My problem is though, that the script does not get called when I boot the system and the scanner is plugged already during bootup. Why is this? Chances are the coldplugging happens from the initrd and your script isn't available in the initrd. So check that. Otherwise, I see no reason why the script would not be executed. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Doubt about sane_get_devices
On 4/24/08, tobias alarcon extobias at gmail.com wrote: Hi all Im just wanna know if this function retrives the list of devices at every moment. Let me explain, i launch my program with the scanner disconected, then i conect it and call this function. Doc say This function can be called repeatedly to detect when new devices become available but this is not my case, i get a null pointer. thanks in advance Tobias. -- 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 -- The truth is an offense, but not a sin -- The truth is an offense, but not a sin -- The truth is an offense, but not a sin -- The truth is an offense, but not a sin -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080426/82a6b921/attachment-0001.htm
[sane-devel] Doubt about sane_get_devices
On 4/26/08, Francisco Miguel Felix Santini fesm788m at gmail.com wrote: May be this can help: Is sane-backend installed at /usr or /usr/local/. I ask you this, because it appears that libusb is installed at /usr and sane-backend doesn't or viceversa. I mean Sane Backend is not using all of the libraries from libusb. You sure that both of them are installed at /usr or /usr/local, i suggested you that both must be installed at /usr. it is a good idea to remove existing sane packages first, and install new versions of sane where the original one was, just to make sure the new version is getting used by existing apps. however, there is no reason that all your libs must be in the same dir. /etc/ld* and $LDPATH take care of that. the problem here seems to be in sane itself. allan Greetings. Miguel Felix. 2008/4/26, m. allan noah kitno455 at gmail.com: well, it appears that the sanei_usb support library intentionally does not re-gather the list of devices. This makes sense in the average sane installation, cause dozens of backends each gather the list within a fraction of a second, as the dll backend cycles thru them. in your case, it is the wrong behaviour, since the long-running daemon needs to know the list has changed. I think i can change the current code to retry occasionally. allan On Thu, Apr 24, 2008 at 11:58 PM, m. allan noah kitno455 at gmail.com wrote: ahh, but you dont just query the list again, you call sane_exit and sane_init first. just call sane_get_devices, and see if that helps. allan On 4/24/08, tobias alarcon extobias at gmail.com wrote: Nop, doesnt work. Maybe im doing something wrong. I got this logs. Log 1 ##Start the program with scanner disconnected [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu] find_scanners: start [fujitsu] find_scanners: reading config file fujitsu.conf [fujitsu] find_scanners: setting buffer-size to 65536 [fujitsu] find_scanners: looking for 'scsi FUJITSU' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1041' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1042' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1095' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1096' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1097' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ad' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ae' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10af' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e0' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e1' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e7' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10f2' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10fe' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1135' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x114d' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1155' [fujitsu] find_scanners: found 0 scanner(s) [fujitsu] find_scanners: finish [fujitsu] sane_get_devices: finish ##Connect scanner and wait a seconds, query list [fujitsu] sane_exit: start [fujitsu] sane_exit: finish [sanei_debug] Setting debug level of fujitsu to 30. [fujitsu] sane_init: start [fujitsu] sane_init: fujitsu backend 1.1.59, from sane-backends 1.1.0-cvs [fujitsu] sane_init: finish [fujitsu] sane_get_devices: start [fujitsu] find_scanners: start [fujitsu] find_scanners: reading config file fujitsu.conf [fujitsu] find_scanners: setting buffer-size to 65536 [fujitsu] find_scanners: looking for 'scsi FUJITSU' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1041' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1042' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1095' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1096' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x1097' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ad' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10ae' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10af' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e0' [fujitsu] find_scanners: looking for 'usb 0x04c5 0x10e1' [fujitsu] find_scanners: looking
