ScanMagic 600 CP & Ubuntu Server Edition

I’m the owner of a rather aged ScanMagic 600 CP flatbed scanner.
I want to connect it to my Ubuntu Server (Maverick).
For some unknown reason the scanner is not recognized and it is not recognized when I connect to a laptop with Ubuntu desktop version.

But there’s a catch. The scanner is equipped with a parallel (“LPT”) port only.
Once I connected it to an old PC that has a parallel port I could make Ubuntu to recognize the scanner. It took a bit fiddling and tweaking but it worked.

The server (and laptop) only have USB ports so I use a USB to LPT cable in order to connect the scanner to the computer.
The cable identifies as: 067b:2305 Prolific Technology, Inc. PL2305 Parallel Port.

I did the same trick with an inkjet printer and that works perfectly.

So how do I make the server to recognize the scanner?

Does the USB → Parallel port adapter load the parport driver ?

lsmod | grep parport

What happens if you uncomment this lines in /etc/sane.d/dll.conf


and also uncomment these lines in /etc/sane.d/mustek_pp.conf

option no_epp scanner Mustek-600CP * cis600

is it now detected when you run:

sudo sane-find-scanner -p

Hi Mark,

lsmod | grep parport gives:

parport_pc 26378 0
parport 31492 3 parport_pc,ppdev,lp

sudo sane-find-scanner -p after uncommenting those specific lines gives:

found USB scanner (vendor=0x148f [Ralink], product=0x3070 [802.11 n WLAN]) at libusb:001:002

So apparently it thinks that my Ralink wireless USB adapter is a scanner. The real scanner isn’t detected so far.

is anything useful reflected in dmesg, just after connecting the scanner and switching it on ?

I’m wondering if -


Need uncommenting in /etc/sane.d/mustek.conf

Just had an idea… can you check the port address of the parallel port:

cat /proc/ioports

Maybe the I/O port address for the parallel port is non-standard (ie. NOT 0x378), in which case we can try adding it manually in /etc/sane.d/mustek_pp.conf

something like:
scanner Mustek-600CP 0x278 cis600
or whatever the correct address is.

cat /proc/ioports produces a long output but as far as I can see not much useful. It gives:

0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:02.5
0170-0177 : pata_sis
01f0-01f7 : 0000:00:02.5
01f0-01f7 : pata_sis
0290-0297 : pnp 00:04
0376-0376 : 0000:00:02.5
0376-0376 : pata_sis
03c0-03df : vga+
03f6-03f6 : 0000:00:02.5
03f6-03f6 : pata_sis
0480-048f : pnp 00:04
04d0-04d1 : pnp 00:04
0800-087f : pnp 00:04
0800-0803 : ACPI PM1a_EVT_BLK
0804-0805 : ACPI PM1a_CNT_BLK
0808-080b : ACPI PM_TMR
0810-0815 : ACPI CPU throttle
081e-081e : ACPI PM2_CNT_BLK
0820-0823 : ACPI GPE0_BLK
0830-0833 : ACPI GPE1_BLK
0880-08ff : pnp 00:04
0a00-0a0f : pnp 00:08
0c00-0c05 : pnp 00:04
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
0d00-0d05 : pnp 00:04
b800-b87f : 0000:00:05.0
b800-b87f : sata_sis
bc00-bc0f : 0000:00:05.0
bc00-bc0f : sata_sis
c000-c003 : 0000:00:05.0
c000-c003 : sata_sis
c400-c407 : 0000:00:05.0
c400-c407 : sata_sis
c800-c803 : 0000:00:05.0
c800-c803 : sata_sis
cc00-cc07 : 0000:00:05.0
cc00-cc07 : sata_sis
d000-dfff : PCI Bus 0000:01
dc00-dc7f : 0000:01:00.0
e000-efff : PCI Bus 0000:02
ec00-ecff : 0000:02:00.0
ec00-ecff : r8169
fff0-ffff : 0000:00:02.5
fff0-ffff : pata_sis

BTW: it seems that the devices are connected as /dev/usb/lp0 (the printer which works) and /dev/usb/lp1 (the scanner which does not work yet).
According to this thread: [all variants] Base address of /dev/usb/lp0?, the base address of /dev/usb/lp1 is 0x378. The cable depicted there looks very much like mine.

Would it be useful to state: scanner Mustek-600CP * cis600? Then the real base address doesn’t matter because * will be always right.

I didn’t look into dmesg yet. The scanner doesn’t have a powerswitch anyway so it is on as soon as the power cable is plugged.

I’m not sure using a wildcard will work… it might… or it could attempt to connect to EVERY address.

Can you run:

dmesg > ~/dmesg.log

then attach the dmesg.log file you’ll now find in your home directory to your next post.

what I was expecting was a line like the one in my /proc/ioports:

0378-037a : parport0

so I’m beginning to think it may not have a base address as USB ports don’t use them, so we may need to find a way to use the character device /dev/lp1.


I wonder if something like:
scanner Mustek-600CP /dev/lp1 cis600
would work ?

Still looking :slight_smile:

Hmm… you might be right a wildcard might work:

[EDIT 2]

What is contained at /proc/sys/dev/parport ? … and is there anything useful in the sub-directories and files ?

In particular, look for any sub-directories with names like parport0, parport1 etc. … then look for files called base-addr and (if exists) post the contents.

I’ve resumed the experiments with the laptop otherwise I have to restart the server each time.
The laptop produces pretty much the same results as the server.

The /dev/lp1 approach doesn’t seem to work because it appears to be reserved for printers.

In /proc/sys/dev/parport there’s not much useful stuff.
It contains a sub-directory named default. That directory contains two files: spintime containing the value 500 and timeslice containing the value 200.

dmesg.log is attached.

OK I’m guessing the important lines in dmesg appear to be:

[ 23.025226] usblp0: USB Bidirectional printer dev 7 if 0 alt 1 proto 2 vid 0x067B pid 0x2305 [ 23.025676] usbcore: registered new interface driver usblp

have you now got anything called /dev/usblp0

or maybe in /dev/bus/usb

Yes, there’s a /dev/@usblp0 entry that is clearly associated with the scanner (or perhaps the converter cable) because it disappears when the cable is disconnected.
There’s also an entry in /dev/bus/usb that corresponds to the bus and device values as reported by lsusb for the converter cable. The device value is not always the same but increases each time the cable is connected to the computer.

I’m wondering if it is now being recognised as a USB scanner ?

What is the output from:


If we can find the scanners vendor:product ID string (if it advertises one at all, not being a USB device), maybe adding it to /etc/sane.d/mustek_usb.conf would work ?

Or maybe just adding the adapter cables vendor:product ID string to /etc/sane.d/mustek_usb.conf … as in adding the line:

usb 0x067b 0x2305

to /etc/sane.d/mustek_usb.conf


Or maybe adding these 2 lines:

option 600cu

(600cu seems to be the closest option to your 600cp)


option 600cu

(if the @ symbol is supposed to be there)

to /etc/sane.d/mustek_usb.conf instead.

Though I’m beginning to think something like this:
may be a better bet… though you’d want to check its compatibility first too :wink:

Your previous post has inspired me to take a different approach.
I’ve decided to go back to basics first. I’ve hooked up the scanner to an old computer with a regular parallel port and using a regular parallel cable.
Using a Ubunty 10.10 live CD I learned that in its original state the scanner is recognized by Ubuntu using the autoprober feature. So that’s a partial success.
The scanimage -L command initially couldn’t find the scanner. I needed to do sudo scanimage -L. So apparently there’s a rights management issue too.

In one of the man pages I’ve found information about manual configuration instead of auto probing. I’m going to find out how I should do that. If I succeed in that too I’ll continue with that adapter cable.
I’m going to report the results back in this thread. I hope you can offer me interesting information just like we did in the RaLink thread.

Concerning your question about lsusb in your previous post:
If I hook up the scanner with the adapter cable then the lsusb command still shows the information about the adapter cable but not from the scanner.
I think this will never produce results because the scanner is not a usb device.

BTW: do devices connected to other than usb ports have ID’s too? And if yes: how to detect these ID’s?

Erm… NO, as far as I’m aware the idVendor and idProduct descriptors (at least in this case) are part of the USB standard.

And herein lies the problem…

mustek_pp.conf (the config file for Mustek parallel port scanners) expects the base memory address of the parallel port… but USB devices (including your adapter) don’t have base memory addresses, and even if they did, they would change every time the cable was re-plugged, or the system rebooted etc.


mustek_usb.conf (the config file for Mustek USB scanners) expects an idVendor:idProduct ID string … which your parallel port scanner doesn’t supply because it isn’t a USB device.

What I was hoping is that by connecting the scanner to the adapter, it had effectively created a USB scanner that couldn’t be detected because it doesn’t have a unique ID string… if you see what I mean.

But if you read the bottom part of mustek_usb.conf -

# [b]If autodetection doesn't work uncomment or add your device file and one[/b] # [b]suitable option[/b] (1200ub is also for Trust Compact Scan USB 19200).

#option 1200ub
#option 1200cu
#option 1200cu_plus
#option 600cu

#option 1200ub
#option 1200cu
#option 1200cu_plus
#option 600cu

So I wondered if adding:

option 600cu

would work.

Of course this assumes that /dev/usblp0 is the actual device (it may not be).
and that the 600cu option is the closest to your 600cp scanner.

Though it may be that this monster hybrid USB/Parallel port scanner thingamyjig you’ve created turns out to be impossible to configure… in which case you’ll have no option but to add a proper parallel port and thereby gain a base memory address to use in mustek_pp.conf :wink:

But we can certainly keep digging if you want :slight_smile:

I’m done with this. It’s not gonna work.
Using a regular parallel port the scanner does work on Ubuntu but with the converter cable it doesn’t.
To be certain that the problems don’t arise from the suck-ish hardware detection of Ubuntu I’ve connected the scanner to a Windows based computer.
On that computer the scanner works with a regular parallel port but with the converter cable it doesn’t work either. The scanner isn’t even detected!
Moreover in Windows the cable advertizes itself as being a usb printing cable.
So apparently either the scanner has special needs or I’ve been ripped off by the store that provided this wrong cable which is not a truly parallel cable.

You’re probably right… the adapter cable is unlikely to work with a scanner… it was always a bit of a long shot.

If memory serves it was detected in Ubuntu as usblp0 (so would probably have worked with a printer), as in Windows… so I fail to see how Ubuntu hardware detection is at fault.

Did Windows automatically load any drivers ? … or as usual, have the Linux devs done a VERY good job (with what must be considered obscure hardware) where the manufacturer failed to support Linux ?

If the store stated it would work with a scanner… why not take it back, and ask for a PCI parallel port card.

Seems to me you’re kind of blaming Linux for something the hardware manufacturers failed to do… and to a certain extent something you failed to do, check it had Linux drivers before buying… would you buy something that said Apple Mac only on the box for Windows without checking there were Windows drivers available ?

Personally I’ve found Ubuntu’s hardware detection second to none… well maybe Debian testing or unstable :slight_smile:

From what I’ve read, it sounds again like your hardware not Ubuntu. Also remember manufacturers tend NOT to support Linux (very careless move imo). Your cable clearly is not truly parallel most likely because it is a converter, therefore data will be missing. The hardware detection system on Ubuntu is miles ahead of Windows & Mac, and to back-up my point here’s a short story.

My laptop, originally a Windows Vista Home Premium OEM copy, came with a 6-1 card reader. Funnily enough, it didn’t work without having to put the card in, an then restarting the whole laptop (not what’s the point in that?). However when I moved to Ubuntu, my card reader worked like a charm after a few commands in terminal. So how’s that for hardware detection? I’d say pretty awesome.

What you should do is look to see if there is some kind of transformer you can use on your scanner/printer so it’s like a USB device, or PCI device that your laptop can use. That’s about the best advice I can give you right now.

Yes sure it is the hardware. The sole problem is that cable not being a genuine parallel port.
Without that cable the scanner is working fine.
I don’t get your point that data is missing because it is a converter.
Is a converter not supposed to be a device that does send all data between the two sides? Why should it drop data?
I bought that cable to convert the parallel scanner to an usb one (or the other way around to let the computer think that it is communicating to a parallel port). So it is supposed to be a transformer.

I know that story about the card reader. I had a similar experience.

My point about Ubuntu’s hardware detection is not exactly that it is just bad but it is inaccurate in some ways.
It sees hardware/chipset then looks it up in a relative small file and says "all right it is device X from manufacturer Y. Compared to Windows at least with that converter cable it is wrong.
And since that usb id file is regularly updated I think I do have a point about the hardware detection (and I’m not the only one complaining about it).

Agreed, but Linux/Ubuntu can’t be held responsible if the device manufacturers don’t supply the information and/or drivers that insert the ID’s, and it’s left to the kernel devs to continually update the file(s) with known ID’'s for hardware the manufacturers don’t submit for testing as they do to M$… personally (in those circumstances) I think they do an exceptional job with most hardware, but the USB → Parallel adapter is somewhat obscure :slight_smile:

Sorry if I came across as some kind of Linux evangelist earlier :slight_smile:

It sees hardware/chipset then looks it up in a relative small file and says "all right it is device X from manufacturer Y

Without manufacturer supplied drivers, that’s exactly what Windows does… and fails much more often than Linux.