And with the new firmware, i have a good news.
The infamous trackpad "GlidePoint" is working. There is a weird things on the logs, by the way : the line "M:found: reg3:6C01" is repeating, with incrementation.
To support hot-plugging the converter checks mouse and keyboard per 1sec, but this is not useful for dumb devices. I think the converter can stop this once dumb device is found. I'll fix.
I have try too with the optical ADB/Mouse, and the mouse is not working... but i have the same things on the logs.
And i have tried on a "real" Mac : the mouse seems to go to adress 10 (and not 3). Is this normal ? (i join a capture)
I didn't know ADB Parser tool, it looks great for debug!
Yes, it is what expected according to OSX source code. I think classic OS9 does same thing probably.
1. OSX checks address 3 if it finds a mouse move the mosue to empty address(F in this case).
2. The mouse is configured there(after moved) if driver is avaialble.
3. OSX check address 3 again.
If it doesn't find mouse anymore, the last mouse is moved back to address 3.
if it find another mouse it is moved to next empty address(probably E). and go to 2.
Keyboards are also handled in same way.
https://github.com/apple-oss-distributions/IOADBFamily/blob/IOADBFamily-6/IOADBBus/IOADBController.cpp#L278One mouse is located at 3 and another at F in the result.
This can happen when you have physically two mouses or a complex mouse like Kensignton.
Mouse at 3 has hadler ID:32 and this indicates that you had Kensington mouse?.
And the last one is my new mouse, an Elecom branded mouse, with the same switch than the Elecom trackball. And the same problem : a "fail" in the logs.
The Elecom mouse fails at second moving for some reason.
This is similar to NeXT mouse issue.
I'll have to revisit this issue later.