<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>OKI company contacted to me and they told me they will provide
the source code, but it might take some time because it's really
old machine.<br>
</p>
<div class="moz-cite-prefix">On 7/3/24 5:41 PM, MOON Sungjoon via
sane-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5d59fdda-feea-469b-bc40-61fc0fb0594a@seoulsaram.org">Hello,
안녕하세요!
<br>
<br>
<blockquote type="cite">Repackaging their backend would probably
be the easiest
<br>
</blockquote>
Yeah, it must be easiest. But it won't be work other archiecture
such as ARM and musl based system like alpine. But still it would
be good start.
<br>
<br>
I will make AUR package first because I use Arch with only
libsane-oki.so parts and other dependencies. People will be easily
port this package to other distro.
<br>
<br>
<blockquote type="cite">If their code is not licensed in a way
that is compatible with SANE, then a "clean room" methodology
might be OK
<br>
</blockquote>
I'm not sure one person can do the "clean room" methodology. Or
writing only documation of this library and someone might be able
to build a backend.
<br>
<br>
And plus I think their library is GPLv2 too. So it might be okay
to just reverse engineer. I will ask this to FSF.
<br>
<br>
Though, like you said just using Wireshark might be enough.
<br>
<br>
<blockquote type="cite">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).
<br>
</blockquote>
I think I will start with USB implementation. Good, thanks.
<br>
<br>
<blockquote type="cite">I would pick a recent backend such as my
brother_mfp one (here:
<a class="moz-txt-link-freetext" href="https://gitlab.com/sane-project/backends/-/merge_requests/751">https://gitlab.com/sane-project/backends/-/merge_requests/751</a>)
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.
<br>
</blockquote>
Thank you for the examples.
<br>
<br>
Thank you so much.
<br>
<br>
<br>
Best,
<br>
<br>
Sungjoon
<br>
<br>
<br>
<br>
On 7/3/24 7:12 AM, Ralph Little wrote:
<br>
<blockquote type="cite">Hi and 안녕하새요?,
<br>
<br>
On Tue, Jul 2, 2024 at 2:51 PM Sungjoon Moon
<a class="moz-txt-link-rfc2396E" href="mailto:sumoon@seoulsaram.org"><sumoon@seoulsaram.org></a> wrote:
<br>
<br>
Hi, Thank you for your reply
<br>
<br>
It's glad to know you have same model.
<br>
<br>
1. Do you think porting python2 to python3 would be useful?
I
<br>
think if driver exists we can just use sane without their
software.
<br>
<br>
<br>
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.
<br>
<br>
2. I will use ghidra to decompile library file and try to do
<br>
reverse engineering. Do you think it would be okay to be
merged
<br>
into upstream (legal issue).
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
3. I found some guides in official
<br>
documentation(<a class="moz-txt-link-freetext" href="http://www.sane-project.org/docs.html">http://www.sane-project.org/docs.html</a>), is
there any
<br>
resources you recommend?
<br>
<br>
<br>
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:
<a class="moz-txt-link-freetext" href="https://sane-project.gitlab.io/standard/1.01/">https://sane-project.gitlab.io/standard/1.01/</a>
<br>
<br>
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.
<br>
<br>
4. What backend codes would you recommend to read as an
example.
<br>
<br>
<br>
I would pick a recent backend such as my brother_mfp one (here:
<a class="moz-txt-link-freetext" href="https://gitlab.com/sane-project/backends/-/merge_requests/751">https://gitlab.com/sane-project/backends/-/merge_requests/751</a>)
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.
<br>
<br>
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.
<br>
<br>
Cheers,
<br>
Ralph
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>