Hi, On Wed, Nov 23, 2022 at 10:18 AM Giovanni Cappellotto <[email protected]> wrote:
> You’re right, I was using avision. > > Thanks for the suggestion, I guess I could try that. > > Last time I was hacking the avision backed, I remember the source code had > a lot of additional complexity because it was supporting tens of different > scanners. Supposedly some changes for supporting a particular scanner broke > the support for Minolta Dimage. > > I’m wondering if you have docs or other resources I can use to reverse > engineer the scanner protocol from the logs I can collect from the original > windows driver. > I believe that there are some Avision protocol docs around but IIRC they are held by folks under NDA so probably no help there. From what I have been able to gather, Avision themselves did have a hand in the making the avision backend, but I doubt that they would be interested in helping out there now. > > For instance I think I identified 3 different endpoints looking at the > sniffer logs, but I’m not sure their meaning. 0x01 seems some kind of > command endpoint, 0x83 receives and sends a lot of information, 0x82 > receives and responds with zeroes and seems like an endpoint used to > complete a command. > > Maybe I can share the full log I collected and get help to recreate a > backend specific for Minolta Dimage? > > Sure, generate a diag log and send it to us. We might be able to figure out what is going on. I would certainly look at the forking issue and try the fix that was suggested in the link I provided. From what I gather, process forking is like kryptonite to libusb. Threading is a better option. Cheers, Ralph
