Closed RArbore closed 3 years ago
For those who would want to implement that: I reversed engineered this part of another SinoWealth-based mouse (G-Wolves Hati) protocol here. Though it seems it has some differences. It needs a different report ID for writing config, and also this: In configuration data for Glorious mice there seem to be bytes for changing lift off distance, but on my mouse they are always 0xFF, and to change LOD you have to write a special command, which changes angle snapping option at the same time.
I'd be really thankful if I could get USB dumps of interacting with official software of Glorious mice.
I would love to contribute, how do I submit USB dumps?
Hello, Thanks for the quick reply. I only have the mouse connected to my laptop but the software still detects more devices which I can't remove. Hope that will be fine.
Please tell me if I did something wrong :) (I renamed the ModelODump.pcap file to ModelODump.txt so I can send it here.) f18a0e88-c30c-11d0-8815-00a0c906bed8.txt ModelODump.txt
No worries, I'm happy to help as much as I can.
The thing with the debounce timer is that while it does reduce click latency (because Sinowealth are using the wrong debouncing algorithm for this application) I never bothered to implement it here, since even 8 ms will sometimes produce double clicks, and 4 ms double clicks on my sample pretty much every other time. So in my eyes this setting is kinda useless. But maybe I have a sample with bad switches.
I captured the data for my RE'ing using API Monitor on the USB HID API endpoints HidD_SetFeature and HidD_GetFeature (iirc, I'm having trouble finding my notes for this project right now). The advantage is that it's highly selective, you don't need to connect the mouse to a dedicated USB root hub to avoid capturing all sorts of USB traffic, and it doesn't need a capture driver. The disadvantage is that API Monitor is sometimes a little buggy and the program you're trying to monitor will start into some kind of zombie state.
The reason I initially opened this issue is because setting a lower de-bounce timer creates double clicks. I used to play a lot of Minecraft, and in competitive games your clicks per second was important. The solution I used when I first started using Linux was to set the de-bounce time in a Windows VM with the Model O mouse passed through directly to the VM. However, it may be nice to have a 100% Linux solution for doing this.
Oh, interesting side effect. Is the choice of bad debouncing deliberate in the end to allow this behavior? I'm assuming that no macros are used here because that'd be considered cheating (while the hardware having an "oopsie double-click" is not)?
All correct - the lowest de-bounce setting (I think 4ms in the Windows software) means that if you click the mouse with a certain "bounce" (it's hard to describe, but there's a certain way you click with your finger), it will double click. It's widely accepted that double clicks aren't cheating but macros are.
I have the wired model O which goes down to 4ms debounce time but the wireless one goes to 1ms. You need to press the mouse button in such a way that makes the mouse double click or maybe triple click sometimes.
I was wondering if this software could set the de-bounce timer of the Model D/O? If not, do you plan on implementing this?