Soarer's Equivalent for Mice?

[tridain]

Have there been any attempts at something equivalent to a Soarer's converter for mice? In particular, I'm thinking of something that would allow programming of the functions of one of those many-buttoned mice without resort to the always-awful, always-resource hungry software. It'd be nice if I could take a mouse and move it to a new machine and know the buttons would work as I wanted them to even though I hadn't installed (or couldn't install, like on my work computer) the programming software. I'm aware of third party software alternatives, as I'm using Karabiner to redefine the buttons on my Mac's mouse in lieu of the SteelSeries whatever-it-was-called software, but that wouldn't help me elsewhere (e.g., my work PC or a retro PC running an old OS).

Is there anything like that out there? Or am I just crazy for wanting such a thing?

Quick edit to make clear I have in mind something external to the mouse--i.e., you plug the mouse into the converter and the converter into the computer--as opposed to opening up the mouse and replacing its internals.

[Muirium]

To answer your question: no. Never heard of such a thing. But mice aren’t really our thing here, so it’s not impossible someone out there has done it.

To explore a little: what explicit functions are you after? Remapping buttons *to* what, precisely?

[Findecanor]

Hasu's TMK firmware and the fork QMK have support for PS/2 mouse input. Those were made for keyboards with a PS/2 trackpoint or trackball module attached, but people have also built mice that use QMK.

There is also a USB-to-USB converter in the TMK firmware collection. It supports only keyboards using the HID Keyboard "Boot" protocol.
Hasu has stated that a programmer could use it as a starting point for making a mouse-to-mouse converter, but that it would have to be hard-coded for only one mouse model.

I think I know what he is referring to: Most mice use a variation of the USB Mouse "Boot" protocol, but with the otherwise unused bits in the protocol used for additional buttons. Those bits would be specific for every mouse model, with the mapping specified in a "Report descriptor". You would have to hard-code the bit mapping because there is no report descriptor parser in TMK, (writing such a parser would be complex... and I suspect a ATmega32u4 microcontroller doesn't have enough memory)

[tridain]

I think I know what he is referring to: Most mice use a variation of the USB Mouse "Boot" protocol, but with the otherwise unused bits in the protocol used for additional buttons. Those bits would be specific for every mouse model, with the mapping specified in a "Report descriptor". You would have to hard-code the bit mapping because there is no report descriptor parser in TMK, (writing such a parser would be complex... and I suspect a ATmega32u4 microcontroller doesn't have enough memory)

This is exactly what I had in mind: a converter to allow mapping of the extra buttons on USB mice to be useful without having the need to install the mouse's custom software--e.g., a thumb button maps to be a double click of the left mouse button. The software that comes with mice to do this sort of programming is almost uniformly awful. It also regularly drops compatibility along the way, in that both older mice become unsupported and older operating systems do as well. (This is particularly true on the Mac, with the constant churn of MacOS revisions and compatibility changes.)

It seems silly that the USB HID protocols don't have standardized support for extra buttons. In principle, a converter like I'm envisioning seems like it should be something relatively simple and have a lot less buttons to worry about than a keyboard converter. Apparently not so in practice.

[Findecanor]

The USB HID protocol does have support many buttons, as long as they are described in the report descriptor. The idea was that any USB HID device should be very simple but that the protocol be very flexible about the device's capabilities. Each device could have its own report format that could mean just about anything and the descriptor being just raw data stored in Flash. Then the host was intended to be a proper computer that could handle the complexity of parsing the descriptor and using it to interpret the report packets from the device.

The "Boot" protocols are alternative protocols intended only for using a mouse and keyboard in BIOS, because a BIOS wasn't supposed to be as complex as a fully-fledged desktop OS. The BIOS would tell the device on startup that it is a BIOS and get the hard-coded paket format. Hasu's USB-to-USB converted does the same thing, because it is on a small microcontroller.

But in reality, mice and keyboards often use the same protocols for boot and normal OS host anyway, because that is even less complex. The Boot Mouse protocol has a few unused bits and bytes that a BIOS would just ignore.

[davkol]

recently posted on Reddit: Remapping mouse buttons/axes in hardware, proof of concept (USB passthrough HID remapper)

[tridain]

recently posted on Reddit: Remapping mouse buttons/axes in hardware, proof of concept (USB passthrough HID remapper)

Thanks for posting these links. Other than an apparent love of trackballs, the creator of this and I are on the same page. If I'm crazy for wanting such a thing, at least I'm not the only one.

[Rayndalf]

viewtopic.php?f=7&t=24619&p=474561&hilit=Alps#p474561
TMK/QMK has the code for serial micebas well as PS/2.