Sorry, I have to correct myself. The dmesg output I got was due to xscanimage probing parport modules while checking for other scanners, not the Mustek I have.
On Mon, 10 Feb 2003, Helmut Walle wrote: ... > The BIOS parport setting is EPP (I also tried ECP/EPP), and dmesg > says: > > ... > parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP] > parport0: cpp_daisy: aa5500ff(38) > parport0: assign_addrs: aa5500ff(38) > parport0: cpp_daisy: aa5500ff(38) > parport0: assign_addrs: aa5500ff(38) > lp0: using parport0 (polling). > ... Now I set up dll.conf to contain only the two lines for the Mustek parport scanners and the respective daemon. When I scan now, dmesg does not give me anything, and lsmod says ipv6 124736 -1 (autoclean) ide-scsi 7552 0 Funny, isn't it? Nothing about parports here... However, when I use the printer, lsmod has parport_pc 19280 1 (autoclean) lp 5248 1 (autoclean) parport 22240 1 (autoclean) [parport_pc lp] ipv6 124736 -1 (autoclean) ide-scsi 7552 0 So parport functionality definitely runs as a module. This means that the scanner is accessed without using the kernel (module) parport support! So the mustek_pp folks must have written their own parport driver, and the sane backend is talking to the hardware directly. That would also explain why it does not support parport sharing, and why it does not (in contrast to the other sane backends) accept a logical device name, but only a hex port address as device. Things are getting interesting... Cheers, Helmut. +----------------+ | Helmut Walle | | [EMAIL PROTECTED] | | 03 - 388 39 54 | +----------------+
