[sane-devel] Add support for old OKI scanners

[MOON Sungjoon]

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 <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