Not really an issue
Closed this issue · 7 comments
Hi. I also worked on the Model O and other "clone" mice like them. My goal was mostly RGB but even then there were issues with detection and my really borked detection in OpenRGB. How did you deal with the multiple usage pages that are 0xFF00 ? I don't know Rust really but I know a bit of C. Thanks.
Sorry, I'm not sure what you mean
When you enumerate the device via hidapi it shows 0xFF00 three times. How do you filter out which one is the one that accepts the 520 packet?
Ah, right, that's a Windows (and probably macOS) thing. On Linux, they are merged into one. The way to differentiate them is to look at the values of usage and usage_page in the device info struct. https://github.com/signal11/hidapi/blob/master/hidapi/hidapi.h#L65-L70
To be clear: this is not implemented in this project at this point, i.e. it won't work under windows
Yeah that is already what I do on Windows and the others. My problem is that it doesn't merge the three into one and I need to search for the usage and usage_page combo that accepts the 520 packet. Currently only Windows works as I copied the function from the original software and implemented it. Hidapi doesn't seem to have that function. Windows does it correctly weirdly enough. Linux and probably MacOS select the wrong combo at random and sending the 520 packet to the wrong combo locks up the mouse or worse, corrupts the settings.
To my understanding, the split on Windows is not particularly meaningful, the underlying communication mechanism is the same for all feature reports. The peripheral differentiates them based on the value of the first byte, which contains the number of the feature report.
On Windows, virtual devices (i.e. OS devices, not USB devices) are created for each feature report, instead of a single device per USB Interface (as on Linux) and it is necessary to open the corresponding one to communicate using feature reports.
To my understanding, the split on Windows is not particularly meaningful, the underlying communication mechanism is the same for all feature reports. The peripheral differentiates them based on the value of the first byte, which contains the number of the feature report.
Usually yes. Most devices follow that. This one is special and doesn't do that. Claiming the first 0xFF00 usage page is usually the one that accepts the length of 520 and claiming the next one with 0xFF00 is the one that accepts the packet of length 6 (random). This has caused lots of messy code.
I tried reading a bit of the code and saw you claim the whole interface which is what I used to do. While it works on Linux and MacOS it doesn't work on Windows without installing another driver for that device which renders the stock software useless until you reinstall the stock driver.
I'll let you know if I try running it under Windows at some point, I only had a prototype running which if I remember correctly relied on the ordering. Can't help you at this point, sorry.