Mice quality and linux support
For a long time i used cheap wired logitech or microsoft mice and that was ok-ish. But from time to time one needs to buy a new mouse for a new computer, because the old is so dirty its disgusting or the really rare that it stopped working 100% reliable. So for some forgotten reason i bought a new one and my mistake here is that i trusted the amazon ratings (never do that). So i got a “noname == tecknet” mouse, it was cheap had more buttons than the cheap logitech one. It even was the “Amazon choice” for wired mouse. How it got that rating, i can not comprehend. The problem with this mouse is it simply does not work reliable. You turn the scroll wheel one way and it sometimes registers that and sometimes registers the opposite direction.
So as that thing was just annoying, i picked a new mouse again and using my brain slightly more this time, i concluded that any gaming mouse must be reliable as gamers dont like loosing from lost or misread buttons. So i choose based on specs and price a corsair gaming katar pro xt. Nice mouse nice hardware. linux support well, kind of. It works fine out of the box if you like your computer looking like a Christmas tree.
Switching off that LED
My first thought was of course that there must be a tool on linux to turn this off. I failed to find it though.
So the next was screwdriver / soldering iron but that was really not feeling right.
So i spend several hours implementing enough support in ckb_next to adjust the LED for this mouse. This would have been quite trivial with a windows box running the official driver and listening to it but i didnt had a windows machine, so randomly reading and writing things to the mouse was the way to go. This was especially fun as the mouse remembers its settings when disconnected. So if you successfully set something you have an incentive to undo that if you want it working as before. I didnt destroy the mouse no, basically blindfolded stabbing it with random writes allowed me to identify a few more fields of what seems called the bragi protocol. So the protocol header now lists the fields for the hardware DPI values for the 3 modes and also the corresponding colors. the mask of enabled DPI modes, a DPI index (which the hardware does not seem to bound check at least not the way id expect). And the LED brightness for both software and hardware modes. I very interestingly did not find how the LED color itself is set or how the hardware mode animation is controlled. So there are unknown things left to be found. But for my purpose what i wanted (turing the LED off) i found all i wanted.
Code is here, pull request is also send, so it may or may not end in the official ckb-next