>
> > > I want to get it to work with SANE, so off I went to update it to work
> > > with Linux 2.2.
> >
> > Do you have that working ? Would you like to become the new maintainer ?
>
> Well, I haven't done any kernel stuff, or low-level x86 stuff before, and I
> haven't bothered to try to compile it for older kernels, so I haven't really
> _used_ it at all yet. Nevertheless, I have it compiling and nearly working,
> and much cleaner (IMO). It should theoretically support multiple scanners,
> don't know if that's of any practical use, though.
I've got one of those Logitech beasts myself (a Scanman Color). After
getting
the driver to work with the latest kernel, I started rewriting it. I
found
it a bit unreadable and I wanted a lighter driver. So far I have a very
thin
ioctl interface, just enough to get the data into user space. If you
want to
collaborate, send me email!
>
> However, I haven't yet gotten DMA to work (the dma buffer just stays
> untouched..), so obviously something yet needs to be done.. Shouldn't take too
> long, though..
Some DMA-IRQ setting don't seem to work on my system (even though they
should
AFAICT). Try changing the IRQ...
>
> > I don't have the device anymore, and I'd like to pass it on to someone who
> > _REALLY_ cares.
>
> Well, right now I really care, I got a new toy and I want to use it from
> linux. I'm not sure about future, but being a gimp developer I expect the toy
> will have some use in the future (at least until I decide to get a "real"
> scanner). I won't commit to anything before I get the bloody thing working,
> though..
Yeah, same here. I don't want to make empty promises...
[some stuff deleted...]
>
> > With SANE, one could employ a KGI-like scheme. That is _thin_ hardware layer
> > in kernel, and then tailored userspace-lib that knows how to talk to it.
>
> That has always seemed the Right Thing to me. The kernel should just provide a
> safe, possibly standardized interface to access the hardware, and not do
> anything to the actual data coming from the hardware, unless emulation is
> _really_ necessary. All manipulation stuff should be done in user space.
I agree. For example, it looks like some s/w calibration is required
for the Scanman Color, which doesn't belong in the kernel.
>
> > > Also, is there any hardware documentation existing (available),
> > > besides the small document and (somewhat sparse) comments in the driver
> > > source?
I made some updates to the HARDWARE.txt file w.r.t. my experiments with
the
SMC, so it probably won't apply to other SM variations.
> >
> > No. The driver was reverse engineered from the logitech DOS driver.
Shiver... The SMC only came with winblows drivers. I tried to
disassemble
the driver with nasm from linux, but couldn't make much out of it.
> >
> > I don't know myself what it _exactly_ does.
>
> You wouldn't happen to have the disassembly stored anywhere? As I don't have
> much dos debugging tools...
>
> There's a mention of some specification in the CREDITS file, though..
Anyone know any disgruntled ex-Logitech employees...:) Oh yeah, I
emailed
Logitech's tech support and inquired about a contact person for
programming
information. All I got was a "sorry this information is not available".
No surprise really...
Cheers,
Frank.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com