Epson Perfection V39 & V600 Scanner Support on Jetson Orin NX (JetPack 6.2, ARM64)

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

Hi NVIDIA Jetson Community,

I’m working on a project using an NVIDIA Jetson Orin NX 16GB with an AVerMedia D131 carrier board, running JetPack 6.2 [L4T 36.4.3, Ubuntu 22.04 ARM64].

I need to connect two Epson scanners (Perfection V39 and Perfection V600) to this setup. Here’s what I have tried:

  1. Installed sane and sane-utils – both scanners are detected by lsusb, but scanimage -L does not fully recognize them.
  2. The open-source epson2 backend in SANE provides limited functionality.
  3. Epson’s proprietary iscan drivers only provide .deb packages for x86_64 and fail to install on ARM64.

Questions:

  • Is there any ARM64-compatible Epson driver or workaround?
  • Has anyone successfully used Epson V39 or V600 with Jetson Orin NX?
  • Are there alternative solutions (custom builds of epkowa, Docker with QEMU, etc.)?

Environment:

  • Board: Jetson Orin NX 16GB
  • Carrier: AVerMedia D131
  • OS: JetPack 6.2 (L4T 36.4.3) / Ubuntu 22.04 ARM64

Any help, patches, or recommendations would be greatly appreciated.
Thanks in advance!

2

*** Please note that this reply is generated by LLM automatically ***

I’d be happy to help you with your question.

It appears that you’re trying to connect two Epson scanners, Perfection V39 and Perfection V600, to your NVIDIA Jetson Orin NX 16GB module with an AVerMedia D131 carrier board, running JetPack 6.2, L4T 36.4.3, and Ubuntu 22.04 ARM64.

You’ve tried installing the scanners, and they are detected by the system, but not fully recognized. The open-source backend in SANE provides limited functionality, and Epson’s proprietary drivers only provide packages for x86-64, which fail to install on ARM64.

Unfortunately, I couldn’t find any ARM64-compatible Epson drivers or workarounds in the provided context. However, I can offer some suggestions and alternatives:

  1. Custom builds of SANE: You can try building SANE from source with custom configurations to support your scanners. This might require modifying the SANE backend to support the Epson scanners.
  2. Docker with QEMU: As you mentioned, you can try using Docker with QEMU to run an x86-64 environment on your ARM64 system. This would allow you to install and run the Epson proprietary drivers, but it might introduce additional complexity and performance overhead.
  3. Alternative scanner drivers: You can explore alternative scanner drivers, such as the ones provided by the Linux Foundation’s OpenPrinting project. They might not be specifically designed for Epson scanners, but they could offer better support for your devices.
  4. Contact Epson support: Reach out to Epson’s support team and ask if they have any plans to release ARM64-compatible drivers for their scanners. They might be able to provide you with a custom build or a workaround.
  5. Community forums: Post your question on the NVIDIA Jetson forums, Linux forums, or other relevant communities to see if anyone has successfully used Epson V39 or V600 scanners with the Jetson Orin NX.

In terms of comparison, the Jetson Orin NX 16GB module is a powerful device, and it’s surprising that there aren’t more resources available for connecting Epson scanners. However, the ARM64 architecture is still relatively new, and it might take some time for manufacturers to release compatible drivers.

To summarize, while there isn’t a straightforward solution available, you can try custom builds of SANE, Docker with QEMU, alternative scanner drivers, contacting Epson support, or reaching out to community forums for help.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

Hi ashishpati04,

It seems a question for your vendor(Epson) of scanner since it is not developed from us.

Sorry that we don’t have similar setup to verify it locally and any experience with this scanner.

Is the scanner connected through USB interface?
If so, please check if there’s any error in dmesg when you connect them.

5

Does the scanimage -L work with another Linux computer?

For reference, USB seeing the device with “lsusb” means USB works, and it won’t be a hardware issue. The less obvious part is that when a device is detected in USB, then there is a broadcast of the device ID which other software can then use to determine if there is a driver available; if so, then a driver takes ownership. The driver itself is not part of USB (there are some “standard class” device drivers which come with USB, e.g., for keyboards, but although packaged with USB they are not technically part of USB itself…they are just simplified because a number of devices work with that driver).

Once you have (A) USB detection, and (B) a driver associated, then you get to the (C) user space software, e.g., your scanimage software. If a custom driver is required, then there will be no choice other than finding an arm64/aarch64 architecture driver which can work with the running kernel. The real question is whether you need some sort of kernel hardware driver specific to this architecture, or if there is some other software (possibly user space and not a driver) required.

In the case of needing a driver (which plugs into the kernel), then if that driver is in the form of a proprietary binary module, there won’t be anyone who can help other than the manufacturer. If there is instead a driver needed (it might not be a driver which is missing, it could be user space or configuration) and that driver is available in the stock kernel (L4T R36.x uses the stock kernel), then likely you just need to compile the kernel module from kernel source (which is publicly available).

If you were to monitor “dmesg --follow”, which logs continuously, and only then plug in the scanner, then no doubt it will mention the USB connect event along with an ID. If there is an existing driver which takes ownership (specific to the scanner, and not part of USB other than perhaps shipping with USB for the case of a standard device), then that is likely also going to be logged. Copy and paste the log lines which occur as a result of plugging in the USB and put them in the forum (you don’t need the entire dmesg, just the plug-in logs). Do this on both the Jetson and a working Linux PC and label the logs; this will allow comparing what we see for the Jetson and for the PC which works, and we’ll have an idea if this is a missing kernel driver which can we can look on a web search to see if it is part of the Linux kernel versus something proprietary. Or maybe both systems will have this, and then we’ll know it is a user space software issue.