> But I was able to get some info, by adding 'kbargs=-k' to the cmdline.txt.
That stops the kernel usb daemon from starting the mouse driver automatically, so you have the opportunity to start it by hand with 'usb/kb -d'. Once you've started that, it seizes control of the usb endpoint so the subsequent 'usb/kb' commands tell you "no unhandled devices". The "setting first config" and "setting boot protocol" messages indicate that the attempt to set the mouse into HID report mode fails, so the driver falls back to boot protocol which every device with CSP 3.1.2 should support. Either your mouse has a different notion of boot protocol from what the driver's author expected, or the raspberry pi's somewhat problematic USB hardware is losing some input characters and causing the protocol to get out of sync. In my contrib area there is now a usb-kb program. If you try that in place of usb/kb, with argument '-ddd' for lots of debugging, it should tell you exactly which command failed in the attempt to set HID report protocol, and will also dump the raw data read from the mouse in boot protocol.
