[sane-devel] genesys backend

[Pierre Willenbrock]

Brian J Densmore schrieb:
> Pierre Willenbrock wrote:
> 
>>
>> I did a major restructuring on the gl841 part. You may want to take a
>> look at that.
>>
> Are you referring to the patch you created? I've already applied that.

Just wanted to make sure you are not working with old code ;-).

> 
>> Essentially to add support for a gl841/gl842 based scanner you need to
>> find out the motor acceleration curve and type(half-step, quarter step
>> capable), ccd settings and analog frontend settings.
>>
> Well as for the motor acceleration, I'm not sure I need to do anything
> there except
> use the code that the Medion 6228 uses. At least for resolution up to
> 2400 xdpi.

If these settings work, use them. But for optimal performance you need
to tweak the settings. AFAIR the settings for all scanners except Canon
LiDE 35/40/50 are guessed, and rather pessimistic. Provided you use the
new slope generation code(The old code doesn't fit with the gl841 part
very well).

The acceleration curve is completely independent of the horizonzal
resolution. It is even independent of the vertical resolution. The new
code uses the time per (full-, half-, quarter-, eighth-)step, derived
from the exposure time at a given resolution. Further it uses a
predefined acceleration slope, defined by its start and end speed(in
time per full step) and an exponent to make the slope slightly
non-linear. The acceleration curve for a given minimum time per step is
the predefined curve capped at that minimum time per step.

> I'm currently building a Windows machine with USB support so I can do some
> USB sniffing. I am still trying to get the datasheet for the GL843, I am
> hopeful
> of getting that from a tech at genesys soon. I'm sure the registers are
> different
> from the 842. Also the 8400 is eighth step capable.
> 

My guess is that the allowed values of STEPSEL/FSTPSEL (in register
0x67/0x68) are expanded to include the value of 3 for eighth step. At
least that's what i hope, as that fits with the current code.

>>
>> Transparent adapter support is completely missing.
>>
> Any ideas on where I could steal some code from to try to make work.
> I've seen the
> registers in the 842 specs that need to be populated. If you'd like I
> could work
> on adding that to the existing scanners. Not sure if any of them are
> capable.
> 

On the gl841 side there are no scanners currently supported which have a
transparent adapter. Perhaps there is a scanner with transparent adapter
in the gl646 part.

>> We will need to add support for horizontal resolutions which do not
>> directly map to one of the gl841 settings(600, 1200, 2400dpi). Using
>> these settings the chip decides which memory layout to use, and how to
>> treat the dpiset setting. Technically, in 2400dpi mode you can equip the
>> scanner with a 43690 pixel ccd with arbitrary resolution, in 1200dpi
>> mode half of that.
>>
>>  
>>
> I noticed you were using a 'non-supported' resolution on the LiDE. Why
> not not just use the
> resolutions that the GL84x are designed for? There is also the
> possibility of using the deletion
> type bit in the AVEENB register (bit 6 of reg 3)? That is the one you
> were talking about
> right? The 842 chip should have 1200,600,400,300,200,150,120,80 for a
> 1200 xdpi scanner,
> by setting registers 44 and 45 (0x2C, 0x2D) and clearing the AVEENB bit.
> I don't know
> what the bit settings are for those resolutions though. They aren't
> defined in the spec, that I can see.
> 

Cleared AVEENB bit means use of deletion. With deletion the range for
DPISET(reg 0x2c/0x2d) is not limited. Using averaging(AVEENB is set) you
are only allowed to set DPISET to 1/1, 1/2, 1/3, 1/4, 1/5, 1/6, 1/8,
1/10, 1/12, 1/15 of the hardware dpi setting DPIHW. You simply set these
values in DPISET(eg. DPISET=600 for DPIHW 1200 and 1/2 averaging).

What i tried to explain was, that you cannot set DPIHW for 3200dpi in
hardware. We will need to add code, which adjusts DPISET to gain the
correct averaging values(eg for DPIHW 2400, real hardware 3200xdpi,
requested 1600xdpi you would need to set DPISET to 1200).

There is already a similar problem: for speed reasons most ccd/cis chips
can be switched to a half resolution mode, making scanning a single line
twice as fast as in full resolution mode. When we switch to half
resolution, we don't change the DPIHW setting, so we need to adjust
DPISET accordingly. That code can be expanded to account for hardware
resolutions the scanner doesn't support in DPIHW.

Using half resolution mode i get averaged resolutions of 1200xdpi,
600xdpi, 300xdpi, 200xdpi, 150xdpi, 120xdpi, 100xdpi, 75xdpi, 60xdpi,
50xdpi and 40xdpi for my DPIHW 1200 scanner.

I hope i explained that more understandable now.

Regards,
  Pierre