[sane-devel] rts8891: Umax Astra 4450 does not work
Stef
stef.dev at free.fr
Mon Jun 29 20:06:29 UTC 2015
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
More information about the sane-devel
mailing list