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.
On 7/3/24 5:41 PM, MOON Sungjoon via sane-devel wrote:
Hello, 안녕하세요!
Repackaging their backend would probably be the easiest
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.
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.
If their code is not licensed in a way that is compatible with SANE,
then a "clean room" methodology might be OK
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.
And plus I think their library is GPLv2 too. So it might be okay to
just reverse engineer. I will ask this to FSF.
Though, like you said just using Wireshark might be enough.
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).
I think I will start with USB implementation. Good, thanks.
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.
Thank you for the examples.
Thank you so much.
Best,
Sungjoon
On 7/3/24 7:12 AM, Ralph Little wrote:
Hi and 안녕하새요?,
On Tue, Jul 2, 2024 at 2:51 PM Sungjoon Moon <sum...@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
