<div dir="ltr"><div dir="ltr"><div>Hi and 안녕하새요?,</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2024 at 2:51 PM Sungjoon Moon <<a href="mailto:sumoon@seoulsaram.org">sumoon@seoulsaram.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">Hi, Thank you for your reply</div><div dir="ltr"><br></div><div dir="ltr">It's glad to know you have same model.</div><div dir="ltr"><br></div><div dir="ltr">1. Do you think porting python2 to python3 would be useful? I think if driver exists we can just use sane without their software.</div></div></blockquote><div><br></div><div>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></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">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).</div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">3. I found some guides in official documentation(<a href="http://www.sane-project.org/docs.html" target="_blank">http://www.sane-project.org/docs.html</a>), is there any resources you recommend?</div></div></blockquote><div><br></div><div>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 href="https://sane-project.gitlab.io/standard/1.01/">https://sane-project.gitlab.io/standard/1.01/</a></div><div><br></div><div>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></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">4. What backend codes would you recommend to read as an example.</div><br></div></blockquote><div><br></div><div>I would pick a recent backend such as my brother_mfp one (here: <a 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.</div><div><br></div><div>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></div><div><br></div><div>Cheers,</div><div>Ralph<br></div></div></div>