On 15/06/2015 23:25, Ondrej Zary wrote:
On Monday 15 June 2015 22:19:14 Stef wrote:
On 12/06/2015 23:45, Ondrej Zary wrote:
On Monday 08 June 2015 23:06:55 Ondrej Zary wrote:
On Saturday 30 May 2015 23:54:28 Ondrej Zary wrote:
On Friday 29 May 2015 23:02:38 Ondrej Zary wrote:
On Monday 11 May 2015 22:05:33 Stef wrote:
On 09/05/2015 00:32, Ondrej Zary wrote:
On Friday 08 May 2015 21:46:36 Ondrej Zary wrote:
On Friday 08 May 2015 16:17:53 Ondrej Zary wrote:
On Thursday 07 May 2015 23:32:28 Ondrej Zary wrote:
Hello,
I just got Umax Astra 4450 (same as 4400 except with UTA?) for a
while and tested it with SANE. Unfortunately, it does not work.
The lamp turns on and the head moves a bit, then goes back (two
times) and the scan ends with these errors:
[rts8891] simple_scan: failed to wait for data
[rts8891] gain_calibration: failed scan data
[rts8891] sane_start: failed to do gain calibration!
scanimage: sane_start: Error during device I/O
I've modified sane_start() in rts8891.c to not fail if
gain_calibration() returns error. It now scans the complete area
and the output resembles what's in the scanner (black template
for UTA use with green text) but it's blurry, shifted
horizontally (and the gain is wrong, of course):
http://www.rainbow-software.org/linux_files/umax_astra_4450/no_ga
in _c al ib ra tion.ppm.gz
http://www.rainbow-software.org/linux_files/umax_astra_4450/no_ga
in _c al ib ra tion.log
Looks like there's a problem with the sensor type?
Gain calibration fails because dev->left_offset (and thus xstart)
is negative. If I set xstart to 4, gain calibration passes
(although it's wrong: ends after first pass with 0x1f,0x1f,0x1f).
So find_margin() does not work...
Hello,
you could try to hardcode gain values at the end of gain
calibration to see if scan is close to be correct.
The dumps from Windows are very different. I've transferred the
register settings to sane-rts8891 but with only partial success.
150dpi and 300dpi seems to work if I don't touch 0x7a register. 75dpi,
600dpi and 1200dpi are broken no matter what I tried.
The experimental patch is available at
http://www.rainbow-software.org/linux_files/umax_astra_4450/umax_astra
4 45 0- test.diff
Found a bug causing 600dpi scans to return only solid color area. It
was a problem with 0xaa "escaping" - I misread the dump because of that
and used wrong registers. After fixing, it didn't work at all - because
the original sane-rts8891 code does not "escape" 0xaa values in
registers above 0xb3.
After fixing that, 600dpi is still broken but at least some real data
is coming from the scanner now.
New patch:
http://www.rainbow-software.org/linux_files/umax_astra_4450/umax_astra4
45 0- test2.diff
Here's a new, more polished patch:
http://www.rainbow-software.org/linux_files/umax_astra_4450/umax_astra44
50- test3.diff
- buttons now work
- lamps work correctly (main lamp turns off at close, UTA lamp always
off) - xsane now works for scanning at 150 or 300 dpi
- preview (75dpi) is broken as well as 75dpi, 600dpi and 1200dpi
Found out that the Windows driver lies about resolution. It claims to
support 75, 100, 150, 200, 300, 400, 600, 800 and 1200 dpi but the
reality is different:
driver dpi real dpi
-------------------------
75 (+preview) 200x100 very fast
100 200x100 very fast
150 150x150
200 200x200
300 300x300
400 600x400
600 600x600
800 1200x1200
1200 1200x1200
So there's no real 75 dpi support - removed it and introduced emulated
100dpi mode so xsane will choose it for preview (without that, xsane
prefers slower 150dpi). So preview now works, although it's too dark.
New patch available at:
http://www.rainbow-software.org/linux_files/umax_astra_4450/umax_astra445
0-test4.diff
Hello,
nice work.
Here are my remarks:
- your patch applies with some fuzz, is it based on latest git ?
I'm working on Debian stable (1.0.24). Instead of compiling and installing
complete custom sane-backends, I just made a symlink from
/usr/lib/i386-linux-gnu/sane/libsane-rts8891.so.1.0.24 to
/usr/src/sane-backends-1.0.24/backend/.libs/libsane-rts8891.so.1.0.24
If it compiles, I can test it right away without any additional steps.
- please include a signed-by and add your name to the copyright
notice in rts8891.c file
- no // comments this breaks C compile
Will fix that when the patch will be ready for merging.
- why does the code bail out early in set_lamp_brigthness() ? You
added code handling the SENSOR_TYPE_UMAX in it.
I added the code probably by a mistake and forgot to remove it later. The lamp
control seems to be completely different from HP scanners and the lamp
functions turn on the UTA lamp instead.
- what the LAMP_REG value should be for your scanner. I see several :
- dev->regs[LAMP_REG] = 0x8d;
- sanei_rts88xx_write_reg (dev->devnum, LAMP_REG,
+ if (dev->sensor != SENSOR_TYPE_UMAX)
+ {
+ dev->regs[LAMP_REG] = 0x8d;
+ sanei_rts88xx_write_reg (dev->devnum, LAMP_REG,
&(dev->regs[LAMP_REG]));
+ }
So 0x8d doesn't seem working for you, what should it be ?
That seems to control UTA lamp instead and I want to keep it off for now.
The main lamp is controlled by bit 5 of register 0x11.
- the margin_level value of 32 in find_margin() is surely a sign
that the scanner is either no set up correctly, or the inner image
pattern is different. Could you send the find_margin.pnm file to compare
with my scanner ?
Yes, it seems to be wrong, the image is very dark probably because of wrong
dark calibration.
I'm now examining the calibration.
Dark calibration seems to always read 750 pixels.
Then a single line of 316px is scanned, starting at 67 - that seems to be
find_margin.
Then a series of single-line 9600px scans is done, which seems to be a waiting
for the lamp to warm up.
Then gain calibration is done at the scanning dpi.
Then offset calibration is done, with 750px.
Then shading data is read at the scanning dpi.
- what do you mean by no 75 dpi ? In windows or in backend ? I don't
think an emulated 100 dpi is useful since we can operate other models at
75 dpi.
Windows driver never scans at 75 dpi. When set to 75 dpi, it scans at
200x100dpi instead (and then probably resizes the image). So this scanner
probably cannot scan at 75dpi.
The lowest resolution then is 150dpi but that's slow. We need 100dpi for fast
preview in xsane.
Have you tried the WIA scanning utility ? Or HP's scanning program
for the Scanjet 4470c ? When I used it logn ago, it would let me scan
with other scanner's brand, and mayby it will use another resolution.
- in rts8891_devices.c, your are modifying a model, not adding
another one, why ?
Looks like the Umax Astra 4400/4450 model was added blindly to the backend and
never tesed. The device ID matches my scanner so I'm modifying that model.
Regards,
Stef
I've check, and the 4450 model is only a place holder and not a
fully supported model. So it is OK to use it. Shouldn't you also use the
sensor instead of creating another one ?
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
