Hardware testing: FireWire Coolscans (LS-4000, LS-8000, LS-9000)

[rohanpandula]

The LS-4000, LS-8000, and LS-9000 are FireWire scanners. ScanStudio's device lane is USB-only today, so current builds cannot drive them yet — on any OS. Support for these models is a future track, and this issue is where that track starts: the owners in this thread are the hardware access it needs, and there are useful things you can run right now.

Today

1. Comment with your model, OS, and how you physically connect (native FireWire port, Thunderbolt-to-FireWire adapter chain, PCIe 1394 card).
2. Linux — the best path today. The nkscan CLI (a separate open-source Coolscan driver; the 9000 is its best-supported scanner, and list is read-only) will tell us whether your setup is drivable. Download nkscan-x86_64-unknown-linux-musl from the nkscan releases page, then with the scanner on and connected:

chmod +x nkscan-x86_64-unknown-linux-musl && ./nkscan-x86_64-unknown-linux-musl list

If you get a permission error, retry with sudo and say so. Paste the output here either way — "listed", "not listed", and errors are all useful.

3. Windows with a working 1394 setup: download nkscan-x86_64-pc-windows-msvc.exe from the same page and run it with list in PowerShell. Legacy 1394 driver stacks vary a lot on Windows 11, so report whatever happens, including failures.
4. macOS: no open-source software can drive these scanners on macOS today — nkscan's FireWire support there is stubbed, not working (VueScan can, commercially). Your comment from step 1 — especially the adapter chain that physically works on your Mac, and whether VueScan sees the scanner through it — is the useful contribution.
5. If nkscan lists your scanner and you are comfortable going further, its README documents actual scanning for the 9000. Experience reports on their tracker directly feed what multi-scanner support here would build on.

I will not promise a date, but this thread is the direct input for when and what gets built. Every report here moves it.

---

Using an AI assistant

Copy this block into your assistant (Claude, ChatGPT, etc.) and it will walk you through everything, including submitting:

You are helping me report my FireWire Nikon Coolscan (LS-4000, LS-8000, or LS-9000)
for ScanStudio, an open-source scanning app that is USB/LS-5000-only today. Ask my OS
and how the scanner is physically connected (native FireWire, Thunderbolt-to-FireWire
adapter chain, PCIe 1394 card), then:

- Linux: download nkscan-x86_64-unknown-linux-musl from
  https://github.com/activexray/nkscan/releases/latest, `chmod +x` it, run it with
  `list` with the scanner on (read-only — it only enumerates). If permission is
  denied, retry with sudo and note that.
- Windows with a working 1394 setup: download nkscan-x86_64-pc-windows-msvc.exe from
  the same page and run it with list. Record whatever happens, including failures.
- macOS: no open-source software can drive these scanners on macOS today, so collect
  my model, macOS version, the exact adapter chain that physically connects, and — if
  I have VueScan — whether VueScan sees the scanner through that chain.

Run only these commands or direct equivalents. Collect full outputs.

Then draft a comment for https://github.com/rohanpandula/ScanStudio/issues/28 with —
Setup (scanner model, OS, connection chain), Steps completed, Outputs (code blocks),
Result ("listed", "not listed", or the error). All three outcomes are useful. Show me
the draft and do not post without my explicit approval; if you cannot post, format it
so I can paste it myself.

[rohanpandula]

opening this track up: if you own one of these firewire units and want to move support forward, you dont need to be a programmer anymore. the model that just carried the windows lane from zero to almost-scanning in one night: you + your scanner + any ai assistant (claude, chatgpt, whatever) running prompts we prepare. the assistant walks you through each session step by step, you paste back what it collects, and on this side the data turns into driver work.

concretely for firewire that means:

• guided sessions with your scanner connected -- if vuescan drives it today, your setup qualifies
• everything is read-only probing or ordinary scans, nothing risky to the hardware
• each session ends with data files you attach here

@Odysseus-56 with two LS-4000s and a working vuescan setup youd be the ideal first person for this -- interested?

engineer types: the open-source driver effort for these scanners is nkscan (https://github.com/activexray/nkscan) and their scsi_proxy tooling is the contribution path for capturing new models. we coordinate with that work rather than duplicate it.

no timeline promises, same as always. but hardware access is literally the only gate on this track, and this is how the gate opens.

[rohanpandula]

here is session 1, ready to run. copy everything in the box into claude or chatgpt and it will walk you through the whole thing -- about 10 minutes, read-only, no scanning:

you are helping me contribute hardware data for a Nikon firewire film scanner
(LS-4000, LS-8000, or LS-9000) to the ScanStudio project. work interactively --
one step at a time, wait for my answer. everything is read-only: no scanning, no
writes to the scanner.

1. ask me: which scanner model, how it is physically connected (every adapter in
   the chain, e.g. thunderbolt 3 -> thunderbolt 2 -> firewire 800 -> 400), which
   macos version, and whether i also have access to any linux machine (useful for
   a later session, fine if no)
2. with the scanner plugged in and powered on, walk me through running these in
   Terminal, one at a time, and have me paste each output back to you:
   system_profiler SPFireWireDataType
   ioreg -rd1 -c IOFireWireDevice
   ioreg -l -w0 | grep -iA4 "nikon"
3. have me open vuescan (which drives this scanner today): note the exact vuescan
   version, the name it lists the scanner under, and whether a preview works right
   now. no full scans needed
4. bundle everything -- the chain, macos version, all three command outputs, the
   vuescan facts -- into one clearly labeled github comment, show it to me, and
   only after i say ok help me post it on
   https://github.com/rohanpandula/ScanStudio/issues/28
5. if a command errors or prints nothing, capture the exact text instead of
   retrying blindly, and ask me what i see on screen

if a step doesnt match my screen, ask me instead of guessing

what this gets us: the scanners firewire identity block (its "config ROM") is the first thing any driver needs, and nobody has published one for these units through a modern adapter chain. session 2 gets designed around whatever this one returns.

[Odysseus-56]

Hello Rohan, Are the last 2 emails you sent me about a totally different project than the USB scan studio I'm already trying to use? Does USB version debugging continue on its own path? Thanks! Alberto Da: Rohan Pandula ***@***.***> Risposta: rohanpandula/ScanStudio ***@***.***> Data: giovedì 6 agosto 2026 13:36 A: rohanpandula/ScanStudio ***@***.***> Cc: Odysseus-56 ***@***.***>, Mention ***@***.***> Oggetto: Re: [rohanpandula/ScanStudio] Hardware testing: FireWire Coolscans (LS-4000, LS-8000, LS-9000) (Issue #28) rohanpandula left a comment (rohanpandula/ScanStudio#28) opening this track up: if you own one of these firewire units and want to move support forward, you dont need to be a programmer anymore. the model that just carried the windows lane from zero to almost-scanning in one night: you + your scanner + any ai assistant (claude, chatgpt, whatever) running prompts we prepare. the assistant walks you through each session step by step, you paste back what it collects, and on this side the data turns into driver work. concretely for firewire that means: · guided sessions with your scanner connected -- if vuescan drives it today, your setup qualifies · everything is read-only probing or ordinary scans, nothing risky to the hardware · each session ends with data files you attach here @Odysseus-56 with two LS-4000s and a working vuescan setup youd be the ideal first person for this -- interested? engineer types: the open-source driver effort for these scanners is nkscan (https://github.com/activexray/nkscan) and their scsi_proxy tooling is the contribution path for capturing new models. we coordinate with that work rather than duplicate it. no timeline promises, same as always. but hardware access is literally the only gate on this track, and this is how the gate opens. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[activexray]

we coordinate with that work rather than duplicate it

Let me know what you need from the python-library side. I'm almost done with my spec-compliant rewrite that should theoretically unlock support for every scanner and adapter, which I'll follow up with the new python bindings.

[rohanpandula]

we coordinate with that work rather than duplicate it

Let me know what you need from the python-library side. I'm almost done with my spec-compliant rewrite that should theoretically unlock support for every scanner and adapter, which I'll follow up with the new python bindings.

You the best! main thing i need is the transport surface, idk how it works on non strip fed machines like 9000/8000. i would imagine its alot simplier than how it works on the 5000 but lmk. tag me the rewrite when its up? if the bindings give me open/claim + read/write on the device i can build the protocol layer on top same way the usb lane sits on libusb

@Odysseus-56 those two emails were just github notifications from this thread, not a separate project and nothing you need to act on. your USB LS-5000 testing continues exactly as before on its own path -- 0.4.0-beta.1 just went out with the multi-batch fix, and the feed-detector work your reports feed into is the next round

[activexray]

The transport surface I'd say is the easiest part. I just read the linux man page for scsi generic and wrote a trait that covered that and scsiscan.sys in windows. I don't know how I'd express the transport in python, perhaps you mean Device? But at that point, we're duplicating stuff because you have your own pyusb stack. I guess I'd hoped we'd converge and use one driver (and tbh Rust makes more sense for this because I can compile a binary library artifact and use it in python/C#/Java/whatever where the converse is not true. Plus, as a systems language there's already tooling for stuff like the linux ioctls and Win32 APIs). But it seems you're just going to rewrite the scsi layer in python anyway so I'm not sure if anyone cares abt python bindings anymore.