Hi Ralph, Yuri, list, Yuri, thanks for chiming in. I was a bit pre-occupied with getting the sane-backends-1.0.30 security bug fix release out :-/
Yuri Chornoivan writes: > пʼятниця, 15 травня 2020 р. 19:49:16 EEST ви написали: >> Hi, >> >> On Fri, May 15, 2020, 09:44 Yuri Chornoivan, <yurc...@ukr.net> wrote: >> > пʼятниця, 15 травня 2020 р. 19:39:05 EEST Ralph Little написано: >> > > On the supported scanners page, the listed backend is >> > > epson2. However, the comment says that it is "supported by the >> > > epkowa backend plus non-free interpreter". Does that mean that >> > > epson2 *might* support it, and additionally there is a >> > > proprietary option also? No, it means that the epson2.desc file lists a number of EPSON devices that are supported by *other* backends (or not all all). You can blame me for that because I started doing that in epkowa.desc. That file has for a longish time been merged/copied with epson2.desc without actually checking what did and did not work :-( >> > > If so, what is the likelihood that epson2 would work with this >> > > scanner with moderate modifications? None. The non-free interpreter is dlopen()ed by the epkowa backend and it converts the regular ESC/I protocol to the device's native protocol, insofar possible. Mind you, there are *several* such native protocols. These native protocol are not even remotely close to the ESC/I protocol. You'd be better of trying to find a backend that uses something close. For a few of the interpreter using devices, the snapscan backend is a good match. For others, I don't know. Maybe sane-find-scanner can be of help to check whether it's something genesys-like, I don't know. While porting those interpreters at part of my work duties, I have tended not to look at the closed source more than absolutely needed to get them to compile and "work". That was about a decade (or more) ago so I don't have any recollection anyway beyond what found its way into epkowa.desc :-P >> > Mine (Epson V330 Photo) works with Epson interpreter (proprietary) >> > just fine. Insofar using a proprietary plugin is "fine" :-P >> So that would be the epkowa backend then? Yes but only in the presence of the non-free interpreter for that particular model. OK, so some of those interpreters may support multiple models (by marketing name at least). The epkowa backend started life as a fork of the epson backend, notice that's without the 2 (or ds). In its first incarnation it linked with the plugins so you couldn't even use it *without* the non-free stuff, even if you didn't need the interpreter. That scratched an itch, so I sent myself at the office a patch developed by myself at home to make things work via dlopen()ing. That way, you could at least get rid of the non-free bits if you didn't have a need for them. At the office, I "managed" to get this merged :-) After that interpreters started to proliferate and the "customer" was glad that "end-users" (do I hate that term!) did not have to download binary packages with *all* those interpreters linked into the backend and the developers did not have to recompile all those interpreters every time a new release was due. BTW, the interpreters would have profilerated even without my dlopen() patch. It was just good timing, call me prescient ;-) > From README file in the esci-interpreter-perfection-v330-1.0.0.rpm, > > This plugin converts between the native protocol of the supported > devices and the ESC/I protocol. The latter protocol is supported > by the SANE 'epkowa' backend, part of Image Scan!, and some other > SANE backends. However, only the 'epkowa' backend provides the > hooks needed to use this plugin. That means, the ESC/I protocol is supported by several SANE backends. I believe at present that list is epson epson2 epkowa (third party) utsushi (third party) The epsonds backend supports ESC/I-2, which is also supported by the utsushi backend, and not even close to ESC/I except for its name. BTW, there are two ESC/I related network protocols, one of which is implemented (partially) by the epson2 and epsonds backends. The utsushi backend uses a non-free interpreter via inter-process communication (IPC) to support network devices and I seem to remember that the epkowa backend also supports network devices but this may use a dlopen() approach rather than IPC. >> Have you ever tried the epson2 backend? > > I do not think it works. It doesn't. It does not have any logic to dlopen() the interpreters and to be honest, I don't think it should cater to non-free extensions. > The scanner itself needs binary firmware to start. The firmware file is really just a blob that the vendor didn't bother to put on the device. Instead the "driver" does, again and again and again, every time you power on the device. There are of course good reasons to do so, like being able to fix bugs in the firmware, but that blob is still non-free software. Personally, I think it'd be nice, on Linux systems at least, to have a udev trigger the download of firmware files to the device. That'd save a bit of time, but if the firmware has not yet been downloaded, the "driver" should do so as a fallback. > My first try after buying the scanner is to use it as is with the > default sane-backends-iscan from Mageia Linux. It did not work. Here's guessing that package did not include the non-free interpreter (and rightly so). OK, that was probably more than you ever wanted to know about the various EPSON scanner supporting backends ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
