Hi,
On Mon, Apr 09, 2001 at 05:07:08PM -0400, Adam Polkosnik wrote:
> After looking at hp4200 backend and lm9830 data sheet I find it rather
> cumbersome
> support for the whole family(there is some differences in register mapping
> between lm9830 and the rest of the bunch). lm9831-lm9833 is a piece of cake
> since there are almost no differences aside from 48bit capabilities of
> lm9833. Though we'll need a smart way of detecting lm9833 since the standard
> way (register 0x69 (Version Number) has defined the same values for lm9832
> and lm9833). The differences between 31,32, and 33 are minimal and porting
> hp4200 backend (dropping the parallel interface, and ironing out the
> differences in register mapping would be the simplest way to get a working
> backend in shortest time)
Ok, so we don't support lm9830. Another reason is that we don't need
to look for the parport problems (run as root etc.) this way.
> In the next few days I'll focus on:
> - getting as much info on the scanners using those chips ( all sorts of data
> eg. optical resolution, .ini files ,snoopy logs, CIS/CCD, etc.)
Some data:
Mustek BearPaw 1200: lm9831, 600x1200 dpi, ISO A4, 5 Buttons, 1 LED,
512 kb Mem (at least that's what the manual says) one
sensor at the beginning of the scan area, no sensor at the end,
there is no ini file (at least in the source code package), but
I can send the c++ file containig the initialisation of the registers
Mustek BearPaw 2400: lm9832, 1200x1200 dpi, ISO A4, 5 Buttons, 1 LED,
2048 kb mem (according to the manual this is the "maximum value",
whatever this means), one sensor at the beginning, no sensor at the
end of the scan area. No source code but I can try to find some sort
of ini file if I start Windows sometime. However I think there won't
be one, see above.
Both sensors seem to be CCD.
> - adapting hp4200 backend to work for lm983[1-3]
> - detecting lm983x (I got a routine for that, except lm9833 needs to be
> added(though I got an idea on how to tell the difference between 32 and 33))
We probably need a mechanism to tell the backend which scanner is
connected by keywords in lm983x.conf (or whatever) anyway, e.g.
type bearpaw-1200
/dev/usbscanner1
so it's not strictly necessary to distinguish the subtype of the
chipset because that can be hardcode for each scanner type.
> - detecting the size of DRAM
> - coarse calibration
> - fine calibration
I looked at this in the Mustek Windows source code months ago but I
didn't understand much. By the way: If you want to get this source
code you can have it (and everyone who wants to help with this
backend) but it's not allowed to publish it by putting it on e.g. a
web server.
> > I think after we find out about the existing code we should start writing
> some
> > kind of mechanism to set the basic values of the chip depending on the
> > scanner type.
>
> May I propose an easy approach?
> How does taking those basic values from .ini settings from windoze drivers
> sound?
Yes, that's ok. I just thought about moving the ini files (if they
exist) into the code (e.g. as constants in a header file). I don't
want to have ini files hanging around e.g. in /etc/sane.d/.
> should I start a project on sourceforge?
Yes, this would be fine.
There is at least one existing CVS repository (from Claus-Justus
Heine), there is a sane-backend. I don't know how far he came,
however.
Bye,
Henning
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Tue Apr 10 2001 - 10:37:47 PDT