Jump to content
Corsair Community

Unexpected G-key delay


c-attack

Recommended Posts

I am having trouble with odd and unpredictable delays when using my G-keys on a K95 Platinum as well as the sniper button on the M65 Pro. In iCUE these keys are assigned a simple key bind to letter or symbol keys [];' that would be otherwise hard to use. The sniper button is reprogrammed to the C key in iCUE. I have been using these assignments for years in this specific game.

 

The delay is not consistent and can be very long, upwards of 10-15 seconds. All other key and mouse inputs work during this time. Striking the actual bound key (C [ ] ; ', etc. will provide instant action, even during the delay with the original action occurring later. I thought it might be related to the game linked profile dropping out at times and I assigned these to my default profile as well. That also allowed me to test in notebook, word, browsers, etc. In those places on the desktop, I have not been able to reproduce the delays. Nevertheless, this is absolutely repeatable within the game and arrived with iCUE.

Link to comment
Share on other sites

what game? CS:GO? think you said you play that a while back when i was inquiring about the Glaive.

 

If I have the game you mean, I can test when I get home (wont be till late EST) to see if my mileage varies but I have iCue and an older k95 regular and the m65 Rgb non pro I think.

 

These are software remaps not macro hardware binds i take it. Since you have platinum, I assume the software could be ruled in or out if you saved a hardware remap to the g set on the keyboard? I dont know for sure.

Link to comment
Share on other sites

Guild Wars 2 is the game in question, although I suspect that part is not relevant to the issue and I can probably make it happen in other games. Maybe I will play a little keyboard Origins later.

 

However, you got me thinking about the hardware profiles. I know I can't bind the sniper button without CUE active, but I had not moved to test the board without Link running. Sure enough when I opened my HW1-3 profiles for the K95P, their lighting was all scrambled with a weird mix of stuff - almost like the prior saved profiles and default mixed together. I had all these weird key binds on the M65 PRO and the a few weird ones on the board. I suspect this happened in the iCUE conversion of the CUE 2 profiles. I cleaned them up and launched. For a little while, I thought I had resolved it, but then sure enough it came back around. It is not consistent and the delay ranges from 0 seconds to as many as 15+.

 

I then quit iCue and played with the saved G key mapping. About 1.5 hours and no issues. Not a surprise and I was pretty sure this was CUE related. With CUE back up and running, there were a few minor delays after that.

 

It is set up with the in-game keybinding set to standard keys ([];'.z c). These always work when activated. Those keys are then bound the more convenient left hand side G1-G6. When the G-key is not responding and I thwack it a few times, I can always look down and press the directly bound key (e.g., "C") and the action is immediate. Then maybe 10 seconds later the original G key stroke will activate, usually with comic effect.

Link to comment
Share on other sites

...Then maybe 10 seconds later the original G key stroke will activate, usually with comic effect.

such meme. I'll try binding throwables to my G1 key for the sake of example and try it a few times in FarCry 5 now just bc i was going to play a bit anyways. I don't think I am going to have this issue, but will report back.

 

EDIT: So I did a straight forward Key remap of G1 on the k95 non platinum and made it C for crouch.

 

Did not have any issues. Was playing on the k63 lapboard most of the time, but popped over occasionally to the desk to ensure it was still working without any delay.

 

out of curiosity did the G keys have any other settings in the key remap like simulate hold or toggle or retain original key output? You're a sophisticated user but I figured Id ask for the sake of diagnosis to rule out the mundane.

Edited by hastegag
update
Link to comment
Share on other sites

I don't know... unexpected results tonight. I loaded up Mass Effect Andromeda. Old profile with spammable G-key binds to letters. No issues at all. Right before it, I had the described issues in GW2 with the G-keys and again right after. Even stranger is I lost mouse 4 & 5 buttons once or twice. That kind of blows the theory I had in my mind for a direct software influence. Switched to my white M65 Pro and the same thing.

 

I will again with a brand new clean profile and then altering the bind keys to new buttons.

Link to comment
Share on other sites

After a weekend of testing, not much has changed. When CUE is open, the G-keys and mouse buttons are prone to erratic delays ranging from 0 to 10-15 seconds. Closing iCUE solves the issue. I took off the M65 Pro and put an old Logitech G502 on, with its management software running. 2 days of keybinding delays, but the functions bound to the Logi mouse work perfectly. And again, I have been using these same binds for years. I suppose the only thing left to do is roll back to CUE 2.23 and Link and see if the glitches travel, suggesting a profile glitch. However, the newly created profile in iCue has the same issues and the G-key binds saved to the keyboard were direct Library copies from the existing profile. Those do work flawlessly with not running. The variable delay and inconsistency makes me wonder if this is some sort of CUE processing delay, rather an actual binding or recall issue.
Link to comment
Share on other sites

I put the M65 Pro back on last night and was immediately greeted with bags of lag. After a profile delete and reinstall of iCUE, I thought I had this really tightened down the last few days. With the M65 on, the sniper button bind to dodge really highlights the often fatal delay, now from less than a second to as long as 10. Again, I can reach down and smack the C-key at any point during the delay and receive instant response, with the original action to follow later. Same on both M65 Pro mice.

 

I backed up the iCue profiles, uninstalled, and went back to Link 4.9.5 and CUE 2.24.48 BETA. Resurrected my old profile for the game. Completely back to normal with instantaneous response. In fact, I had become accustomed to some very small delay all the time in iCUE and it went unnoticed. Back on CUE 2.24 the G key responses are very precise and I have a lot more control than I remembered.

 

Not really sure what's going on here. There does not seem to be a rash of other reports of this. It was not readily apparent in some other games, although this is the only one where I am G key bind dependent. Regardless, I have been using the sniper key bind in this game as long as there has been a M65 with that button, going back years, 3 M65s, and to CUE 1. I have never experienced this before. As this is not limited to the keyboard and affects the mouse as well, it seems like some sort of processing delay. Closing CUE resolves this completely, but the at the expense of the M65 Pro losing the sniper button utility. Feels weird now to be back on Link and CUE, although I do like seeing my simple min max values again.

Link to comment
Share on other sites

...bags of lag...the expense of the M65 Pro losing the sniper button

 

I am sorry to hear the struggle but bags of lag is hilarious.

 

I see that without CUE running the sniper button does not seem to put out a 'default' recognizable mouse button behavior.

 

I do not have a pro m65 but does it let you save macro effect to your sniper button? If so you could wrap that in the meantime maybe in ahk or binded to whatever key you saved to the memory, assuming that works.

 

Also, I had posted about the SDK not starting sometimes when I would boot the PC. In additional testing/experience, it seems that I have 90+% success with the SDK running in icue when I do one of two things, not sure which helps more, but I suspect it is item 2: i.) unplug my wireless usb for the k63 and wireless usb for logitech mouse for my lapboard and ii) do not move any input device or type any character of any kind until well after I am certain every app has loaded in windows 10 (give it a good 45 - 65 seconds or more AFTER login).

 

Don't know why specifically, but I seem to have better mileage that way and the SDK almost always runs, I suspect it finishes polling and handshaking all the devices and doing back end stagehand trickery.

 

On earlier CUE 2's, the waiting after login and before any input would sometimes help ensure my mouse would be functional on that boot...so like there were times in earlier cues where i would use the mouse too quickly and it would like ... turn off. While that sounds like a physical issue maybe even a power surge or short, FWIW, waiting a second fixed it almost every time.

 

The excessive wait at the beginning may not be related for you, but I would say if you happen to go back to icue before its next update, it might be worth a shot.

Link to comment
Share on other sites

hey I am no dev, but there do seem to be a tremendous amount of UI related errors in the second to last log.

 

Perhaps something erroring out is holding up the thread before it does the sniper button action etc.

 

"2018-04-13T17:05:23 W qrc:/qml/ui/assignment/AssignmentView.qml:322:27: Unable to assign [undefined] to bool" was in there a bunch as was

 

18-04-13T17:04:35 W qrc:/qml/delegate/ImplicitAssignmentViewDelegate.qml: Object destroyed during incubation

 

as was

2018-04-13T17:09:18 W qrc:/qml/ui/assignment/DynamicGeometryNodeChannelDelegate.qml:21: TypeError: Cannot read property 'x' of undefined

 

All of which as I saw were back to back with no appreciable delta in timestamp.

Do you have a node pro? Maybe (not sure if possible) but maybe you could take that out of the equation and see if your results are the same?

Link to comment
Share on other sites

  • 2 weeks later...

This issue continues on 3.2.87. Again, it is very clear cut. I have been playing for weeks on Link 4.5 & 4.7 + CUE 2.24.50. No issues. Very direct response. Now on iCUE again, huge delays from the G-keys and sniper button. The really strange part is the mouse normal side buttons were also affected tonight in some of the really bad lag times. Quit iCue and use the K95P saved profile and the delays are all gone. Instant response. Loaded up iCUE again, back to lag. Created a brand new profile and new key binds for it. No difference. Again, hitting the source key [ ] ; ' ., always creates instant action.

 

Ran the last hour with DPC Latency checker in the background. No change when iCUE is open vs closed and no unusual spikes. All in all pretty low given the amount of programs running plus the game. Guild Wars 2 utilizes a background process called Coherent UI. (https://coherent-labs.com/). Not sure if this is somehow related, but it seems odd there are no other complaints about this issue. I am on a fairly common Z370 platform.

Link to comment
Share on other sites

coherent labs might be a culprit is it easy to test without it running? I still think your logs revealed some UI related delays...are you DPI scaling or can you tell us if multiple displays are plugged in?

 

anything that might hang up their QT framework like something polling fonts? CC application manager running in background? Maybe kill that and see what happens?

Link to comment
Share on other sites

No DPI scaling. Monitor in native 3440x1440. Single GPU. Nothing polling fonts that I am aware of.

 

I latched onto the Coherent idea because I am not sure why this is a non-issue with Link, but a game ruining experience on iCUE. It also seems to be limited to this game. Obviously others are using iCUE and using G keys without ill effects. I am also unable to repeat the delay in notebook or word or outside the game. I don't think I can test without Coherent running. It would crash the game for sure.

Link to comment
Share on other sites

Interesting development. For the first time in quite a while, I used Precision XOC instead of Afterburner for GPU clocks. No lag. Didn't really make sense, so I have been going back and forth the whole weekend between the two. Afterburner + iCUE + GW2 = the issue. So, perhaps you are right about the UI related issue. My Riva SS settings are on the default, which are fairly non-invasive. I also don't understand how this could affect G-key and sniper functions only. The only way that could work is if iCUE is prevented from executing something when I hit the trigger. I took the CUE space window out, which seemed like a probable suspect. It made no difference. Well, at least I have a workaround for now without removing iCUE.
Link to comment
Share on other sites

Glad you have a workaround that type of stuff can be really annoying. I’m not even sure what that other software you mentioned does (I think ribs is ocing?) but given the simple fact of the log file had many writes to it within a second (& I wouldn’t recommend this is a matter of course) but it might be interesting for giggles to test without logging enabled?

 

Even if it was just a minor error and the icue software was waiting for the log to complete its write stream I could see how that could hold it up if that aspect was single threaded

Link to comment
Share on other sites

Do you have OSD enabled? I wonder if the OSD settings may be conflicting with Riva?

 

No Corsair OSD. Yes, on the Riva OSD (v. 7.1). I am no longer using CUE Space and back to the old fashioned dashboard. No other monitoring going on. I don't really understand the Riva settings well enough to guess how they interact. (Application Detection - Low, Stealth off, Custom D3D off, OSD on, OSD rendering mode - Raster 3D+, OSD Coordinate space - viewport).

 

I need to get some more time with other games and the G-keys to rule in or out the GW2 engine, coherent, etc.

 

EDIT: Missed the MSI 4.5 update last week. Installing now. Rats. Worked really well for hours. Then later that night it went back to normal. This is a weird condition.

Edited by c-attack
Link to comment
Share on other sites

  • 3 weeks later...
Well, not too much to update. This issue continues on iCUE + MSI Afterburner + Guild Wars 2. The problem goes away if I use EVGA precision and it is not readily apparent in other games. It must be some kind of connection between the three. Additionally, the problem is greatly enhanced (or ameliorated) by the position of the iCUE app window. When iCUE is open on the desktop (main panel or dashboard), the delays are pronounced and obvious. Closing the window to the tray (not minimizing) reduces the issue massively, but perhaps not quite to the point of non-existence. It is not as simple as open=lag or closed=none and it feels like there are varying amounts, even when small. The theory that this may be related to visual elements within the applications may be correct. I also went back to Link 4.9.7 this week and I have logged about 8 hours with Link + MSI + GW2 with no occurrences.
Link to comment
Share on other sites

  • 3 weeks later...

Trial # I've lost track. I reinstalled iCUE 3.2.97 yesterday and the lag is worse than ever. However, the interesting part is this no longer just affects the sniper button and G-keys. It is now happening on the M65 Pro side buttons as well. Those are recognized by the game and actions assigned directly in the game. CUE should have no affect on this. That suggests to me something is interfering with the signals along the USB lines. Again, direct key input never seems to be affected (for non-G keys). I also played quite a bit of Mass Effect Andromeda today with the G keys and sniper and there were zero issues (aside from the persistent crash at the end). So again, it seems like some combination of MSI Afterburner, Guild Wars 2, and iCUE is causing the delays.

 

*Interesting that I am also having full screen to exit errors in Mass Effect, but only when using MSI + iCUE. Could it be RTSS or that at the core of all this?

Edited by c-attack
Link to comment
Share on other sites

  • 2 weeks later...
Well, time to close this one off I suppose. After the other mouse buttons became affected, there was reason to believe this might not be as simple as a program glitch and there some heavy latency issues underneath. Fresh install of Win 10 and the above problem is gone. Performance is a little crisper across the board and it seems there was definitely some OS level interruptions. However, that does not entirely explain why every other program was able to function under the perceptible tolerance level, while this combination of Guild Wars 2 + MSI After burner + iCUE caused such tremendous 10-15 second delays. Removing any one of those three elements removed the problem, at least to the naked eye. Something in the way iCUE and Afterburner/RTSS interact was magnifying the problem to an extraordinary degree. Hopefully, this does not show up again in other places. Edited by c-attack
Link to comment
Share on other sites

Thanks for keeping us updated! I’ve been having a different, very fixable yet nuisance issue on one of two machines and I’m leaning towards it being related to the age of the os install because as far as I can tell it is the only substinative difference between the systems

 

Might go for a clean reinstall if/when I get the mp300 in light of above

Link to comment
Share on other sites

×
×
  • Create New...