[sane-devel] Add support for old OKI scanners

[MOON Sungjoon]

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 <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/20240711/1912c932/attachment.htm>