[sane-devel] Add support for old OKI scanners

Ralph Little skelband at gmail.com
Tue Jul 2 23:12:54 BST 2024


Hi and 안녕하새요?,

On Tue, Jul 2, 2024 at 2:51 PM Sungjoon Moon <sumoon at seoulsaram.org> wrote:

> Hi, Thank you for your reply
>
> It's glad to know you have same model.
>
> 1. Do you think porting python2 to python3 would be useful? I think if
> driver exists we can just use sane without their software.
>

Repackaging their backend would probably be the easiest, low effort option.
When I used their backend on an early Linux Mint distro, I found it to be
very reliable, one of the better closed-source drivers that I have
encountered. What let it down was the python stuff used to package it up
and install it. Not entirely their fault mind: Python is a bit of a moving
target at the moment.


> 2. I will use ghidra to decompile library file and try to do reverse
> engineering. Do you think it would be okay to be merged into upstream
> (legal issue).
>

If their code is not licensed in a way that is compatible with SANE, then a
"clean room" methodology might be OK, that is study of the code to
determine the protocol details, then reimplemented from scratch might be
OK, but I'm not a lawyer, so take my opinion with a pinch of salt.

In a different subproject for Brother MFP machines, I just observed
wireshark traces to figure out how to talk to those machines so currently,
there is no contamination with Brother's own code. That situation has
gotten a little more complicated with the recent discovery of a GPL version
of one of their early drivers that is free for all to look at and use. I
won't be using their code, but there is a lot of information that I can get
from the code to radically improve my backend.


> 3. I found some guides in official documentation(
> http://www.sane-project.org/docs.html), is there any resources you
> recommend?
>

That is tricky. AFAIK, there isn't a very good guide for starting a new
backend. Most people take an existing one, rip out the unneeded guts, and
start adding what is needed. I would certainly have a good look at the API
and protocol docs for SANE here though since you need a good idea of the
process flow between the backend and frontend:
https://sane-project.gitlab.io/standard/1.01/

If you take an existing backend, it would be best to start with one that
implements the comms protocol that you are going to use (e.g. USB or
network). The escl one would be a good network sample. It's not a simple
process, but I found that once the basic framework has been set up and
working, moving forward is a lot simpler and straightforward. There is a
little bit of a learning curve to providing the right process that the
frontend is expecting.


> 4. What backend codes would you recommend to read as an example.
>
>
I would pick a recent backend such as my brother_mfp one (here:
https://gitlab.com/sane-project/backends/-/merge_requests/751) or the
canon_lide_70 (which I used for the basis of my own) or the escl backend
which has Thierry actively maintaining. My brother one only implements USB
at the moment, but escl is primarily network based, so it really depends on
where you want to start.

One way to get going to to have a look at a data stream, perhaps with
Wireshark, to see how complex it is. If it is very intuitive and
straightforward, you might not need to do much analysis at all.
Multi-function machine protocols tend to be a lot more high-level which
makes them easier to talk to than a lot of the devices that are based on
scanner-on-a-chip designs, which can be very, very involved.

Cheers,
Ralph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20240702/98df0895/attachment-0001.htm>


More information about the sane-devel mailing list