russk

The way my desk is set up, I share the same keyboard/mouse and monitors between my personal computer and my work computer. I have iCue installed on my PC, but I don't want to install it on my work PC, since it's company supplied. I bought my mouse in February, 2020, and it was having the double-click issue by November. I took it apart and repaired the switch to fix it, but now the double-click issue has returned again. To avoid having to constantly repair the mouse, I know that in iCue they added a "debounce" configuration that will essentially ignore rapid double-clicks. What I'm not sure about is whether that setting requires iCue to be running, or if it gets stored in the mouse and would continue to work while connected to my work computer without iCue. Does anyone know this answer? I'm sure I could play around with it and try to test it out, but since the issue isn't easily reproducible (yet), I'm not sure that I'd be able to detect with certainty whether it works that way or not.

I attached a photo of iCue to show the "Devices" area and circled the icon with the three lines. If you're not seeing it, you may be on an older version. For taking apart the IronClaw, it really depends on your experience level. If you're not used to taking things apart, I would not attempt it. There's a mix of glue, screws, and clips that you have to deal with. There's also wire harnesses that you have to disconnect. I personally have the IronClaw wireless, and used this guide: [ame= ] [/ame] This gets you most of the way if you have the wireless, and then it's not too difficult to figure out how to take the bottom board off. The other note is I didn't fully remove the sliders on the bottom to get to those two screws, I just peeled them back slightly just enough to access the screws. If I have to do the repair multiple times, I'm considering using a hobby or utility knife to cut away that small section of each of those pads. There's an image guide for the wired version, but it doesn't have clear instructions: https://imgur.com/gallery/xtCosif Lastly, I used this video for how to fix the Omron switch: [ame= ] [/ame] Just be aware apparently there are two different kinds of Omron switch. Mine happened to match the one in the video and the repair process was the same. I would rate the repair more on the difficult side, since getting that foil piece you need to rebend back in seated correctly is not easy. It took me a few attempts. I'm not sure what I was doing wrong, or what I did differently when it worked, it just sat correctly on the third or forth attempt. I would say you should have a back up plan, so if you're not comfortable with soldering and the possibility of having to replace the entire switch if you can't get it back together, I would not attempt it. If you're at the point that you're considering buying a new mouse altogether, again, it can't hurt. However, if you're not confident then you may want to just consider in RMA if you're within warranty. I've just noticed a few threads where people get the RMA device back and it has the same issue, or the mouse wheel breaks shortly after. I'd take that info with a grain of salt, because I'm sure the users that get a successful RMA aren't going to be quick to post about it. Negative feedback tends to be more prevalent.

I just downloaded 3.36.125. I have a Ironclaw Wireless RGB, with mouse and dongle firmware 1.16.107 and 1.11.52 respectively. Both say they are the latest. I do not see the "Button Optimization" at all. For my keyboard, (K95 Platinum XT) there is a "Increase Key Switch Debounce Time" that allows me to set ms, but there is no such similar setting for the mouse. I also tried plugged the mouse in via USB to see if the setting would appear, but it still did not. Maybe this is a dev item that's in a future release and didn't get merged to 3.36.125? If we need to start using this, is it possible to add a tuning enhancement to the app, instead of having the user try arbitrary 'ms' settings in for the debounce setting? If it asks the user to do a series single clicks, it should be able to detect the timing for any bounced double clicks, then it can ask the user to do a series of double clicks as quickly as they can to see what the 'shortest' realistic delay is (it would have to account for the fact that there may be 3 or 4 clicks due to bouncing). It can then find a value, hopefully, between the bounce timing and the actual double click timing (maybe weighted more toward the bounce timing) to automatically set. I feel this would be a better user experience than trying arbitrary numbers and keep tuning until you no longer have bouncing issues, while also not introducing filtering of actual double clicks.

Attached are the logs from when the issue occurred yesterday, in case they are helpful. My K95 Platinum XT is plugged into a powered USB 3.0 hub. The USB cable for the keyboard is in a 3.0 port, and the USB cable for the pass through is in a 2.0 port. The dongle for my mouse is plugged into the pass through USB port on the back of the keyboard, so they are very close together. I use the 2.4Ghz mode. Shortly after the mouse "died" and I couldn't wake it, I did turn off the power to the hub and then back on to try to reset the keyboard and mouse dongle. So you may see a connection loss for both the keyboard and mouse somewhere in the logs. I also included a log from today (12/10) since the mouse and keyboard are both working without issue. This way there's something to compare against as a baseline. logs.zip

In my experience and research, the "double clicking" is not an issue with iCue, but is a hardware issue in the mouse (specifically the Omron switch). I wound up doing the repair myself, and its been holding up thus far. To me, it was the better option than getting an RMA and hoping I wasn't inheriting some other issue. Theoretically they could 'address' it with a firmware update, but I honestly don't know how many ms are between the clicks (if it would be easy to detect as a hardware fault rather than intentional). They could attempt to detect when it's bouncing and ignore the second click. However, there is risk there that it could inadvertently block legitimate double clicks from registering in some cases. When I took mine apart to fix it, I found the piece that I needed to reform is incredibly thin and flimsy. I don't doubt that simply dropping the mouse (or it 'surviving' shipping) could directly contribute to the failure. --- Aside from that, I also found that the mouse naming "(1) (1) (1)" is just a software issue in iCue. It's not that it's running multiple mice at once, it just periodically detects it as a new mouse and appends a (1) to it instead of overwriting the existing name. You'd think it'd move to (2), (3), etc.. Regardless, you can clean it up, and it's an oddly unintuitive process to do so. By default at the top area of the iCue window, you'll see "Devices" and it will show an image for each (keyboard, mouse, etc..). To the right-most end of the bar the word "Devices" is in, you'll see an icon that looks like three lines. Click this, and instead of showing the devices by icon, it will list them by name instead. Find the mouse you need to rename, and double click the name. Now you can edit the name of the mouse. After you make the change, you can click the icon of 4 boxes where the 3 lines used to be, and it will go back to the default view of showing them by icon.

Corsair Haurjie, After I paired it again, all of the hardware profiles were lost on the mouse itself. iCue had noted that there was an inconsistency between the hardware profiles stored on the mouse and in iCue. I was given the option to update iCue to match the mouse (which I didn't want to do) or to hit cancel and do nothing. I still had the profiles stored in iCue, so I had to activate each one again and them save them to the onboard storage individually to reprogram them. I'm not on the PC right now that had the issue, so I can't grab snippets from the log right now. There were a ton of errors when this happened. If memory serves, it started with an error about the dongle being in an "invalid state" and then there were issues with communications to the mouse timing out and invalid responses for getting the firmware version of the mouse. I'll provide the logs later, if it gives the team any benefit. For now, I'll keep an eye on it. This has only happened twice since I've had the mouse (almost a year), and the first time was very early on. If it stays that infrequent it's just enough to be annoying but not unacceptable (IMO).

Well, that was odd. I believe the issue first happened shortly after iCue launched, since the PC was booting up. To try to resolve it, I plugged the mouse into USB and tried to open iCue to bring it to front from the system tray, but when I clicked Bring to Front the iCue process just died without any error or warning. I restarted iCue and it listed two separate Ironclaw Wireless RGB mice in the devices. The mouse would work in USB, but as soon as I unplugged the cable it would stop working. The one Ironclaw device had a dongle firmware version listed, but no info on the mouse, the other was the opposite. Once I paired the device, they merged to one device and it seems to be working now. This may be the normal behavior when the dongle and mouse haven't been paired together. It's just very odd that the mouse suddenly just got amnesia and forgot all of its programming, and that the iCue process seemed to die at the same time. Hard to say which is the cause and effect.

I had just booted up my computer and everything was working fine. I was in the middle of moving the mouse and then the cursor stopped moving. I looked down and the mouse was completely dark, all the lights were off. I moved it around a bit to see if it would wake up, but it would not. I then clicked the mouse button and the DPI indicators on the left-hand side are just flashing white for about a minute and then they just turn off. Also, the RGB light is on the default rainbow cycle, like it has lost all of the internal hardware profiles that I had configured. It should have a "medium" charge, there were two orange lights on the side when I turned the PC on. I think I just need to resync the mouse to the base (hopefully) and repush the profiles. It's just odd to me that it would just lose all of its programming in the middle of being used. Has anyone else had this issue?

Just to close this one out, I did wind up taking the mouse apart and performed the fix for the Omron switch. The piece of metal that you have to bend inside the switch is incredibly thin and flimsy, maybe slightly stronger than a piece of foil. So, if you do the repair, be sure to be delicate and have the proper tools. The Omron switch itself isn't easy to pop open, I used a 1mm flat head screw driver to pop the tabs on each side. Anything bigger than that was too thick to get under the tabs. Now that it's finished, the mouse is working 100% without the phantom click issue. I'm glad I decided to go that route instead of going through RMA.

I had mine apart last night to fix an issue with one of the Omron switches. I decided to check out the mouse wheel while I was in there. I'm no expert, but it does seem like a bad design. When you press down on the mouse wheel to click the button, it's using that tiny piece of plastic in the encoder as the fulcrum. If you look at the pictures others have posted, you can see there's thicker plastic and a collar in between the very small end and the wheel itself. You would think that rests on something so that the thicker part could bear the load, but there's not anything that actually contacts that in the mouse. Whenever you press the mouse wheel, you're essentially splitting that load between the thick/long end that actually presses the button and the very thin end that's inside the encoder. I would think adding a separate fulcrum in that spot I mentioned would help, or use a different encoder that would allow for a thicker end of the plastic. Hopefully something Corsair can consider.

Thanks for the insight! I was aware of people having issues with the mouse wheel breaking as well, but knowing you had it happen from a refurb makes me even more hesitant to go through the RMA process. It seems there's a good chance I'd be trading one problem in for another. The repair and replacement of the internal switch seems to be within my skill set from the articles I've found, so I'm probably going to give it a go myself even thought it's under warranty. It's unfortunate, I really like this Keyboard and Mouse, and the iCue software. I hope that Corsair figures out how to avoid these hardware defects in future models.

I purchased my Ironclaw Wireless RGB mouse in February of this year, so it's less than a year old. About a week or so ago, I noticed when using it on my laptop (iCue not installed) that any time I was dragging an email to a folder in Outlook, once I'd drop it that folder would get opened. It was like once I let go of the mouse button, it was registering another click. There were also times when I would single click a button, and it would count as if I double clicked it. I thought it was some issue with the laptop, but now I realize it happens on my desktop as well, which does have iCue installed. I checked for firmware updates but iCue says the mouse and dongle are up to date. I also haven't changed the firmware recently. I see quite a few threads for this issue on this forum for other models of Corsair mice. It's pretty frustrating to spend $90 on a mouse and have this kind of issue this early. Does this model of mouse have the same hardware issue as the others? Has anyone used the RMA process with Corsair before? I'm assuming this is going to cost me money to ship, and I'll be without the mouse for some time (so additional cost to buy a mouse to hold me over). Do you get the same serial number back, repaired? Or do they send you some other refurb unit that may not be in decent shape?

Does anyone know how to fix what's shown in the attachment? (Either permanently or at least how to clean it up.) It seems in iCUE the name of my mouse keeps getting a (1) appended to it over time. You would think at least it would bump up to (2), (3), etc.. I only have the one mouse in iCUE. The only other mouse I use sometimes is an old Logitech M215 - with no RGB. I don't understand why iCUE keeps extending the name.

I didn't realize that I had a response to this thread. I didn't have any real progress with Corsair support. From what I've seen and heard from others as well, I'm pretty confident that the newest "XT" version of the keyboard just does not have a BIOS mode in it. Corsair support was adamant that it still does, but none of the various instructions they provided worked. Ultimately they ended up offering an RMA, but I didn't want to risk getting some refurb replacement for an otherwise perfectly new keyboard. In my case, I wound up "fixing" it by upgrading my system. I'm running on a Gigabyte x570 Aorus Master now. In other words, I no longer need to have a "BIOS mode." So, I asked them to just close the case. It was a very disappointing experience. It's clear that the support person I was speaking with didn't have access to the same keyboard model to test for himself, or he would've quickly realized it just doesn't work. That said, I'm overall still satisfied with Corsair's products in general.

I had an email response from Corsair technical support stating that the K95 Platinum XT does still have a BIOS mode, but you need to hold "F1 + Windows Lock" for 10 seconds instead of just 3. I've tried that but still have had no luck. I've tried for 30 seconds even, and still nothing. I've let them know it didn't work for me, and still waiting for a response. Just curious if anyone else with a "K95 Platinum XT" has had any success getting into BIOS mode? I have seen a few videos and blogs showing how to get various Corsair keyboards into this mode, but nothing specifically for "K95 Platinum XT." The closest I've seen was for K95 Platinum - but that method certainly is not working for me.