[sane-devel] rts8891: Umax Astra 4450 does not work

[Ondrej Zary]

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.

>     - 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


-- 
Ondrej Zary