ALT not registering or being released while held down
Just bought a CODE V3 104-Key Mechanical Keyboard - Zealio 67g, and while I primarily use it for typing (programming), I'm also a casual gamer; which comes with some more unique and unusual key combinations.
It seems occasionally... pressing ALT (or having ALT held down) in combination with pressing another key (in my case mostly S) will either not register that ALT as been pressed or release the ALT being held down (forcing me to release and repress the key).
I have upgraded to the latest firmware 1.20 but the issue still persists. I only have USB 3.2 Gen 1 and Gen 2 ports on my motherboard (so no USB 2.0 to try). The keyboard is currently plugged into a USB 3.2 Gen 1 port on the rear panel.
I would say this situation randomly occurs 5-6 times an hour while playing an FPS called Hunt Showdown (never occurred with my old DAS Keyboard though), I have not tested any other games. Attempts to manually reproduce the issue generally fail, it all feels very random.
Has anyone else ever encountered anything like this before? Could this be a polling rate issue? Are there an logging utilities I can use to catch this as it occurs?
Here is some information about my system:
Motherboard: ASUS ROG Crosshair VIII Dark Hero (X570)
BIOS: Version 3401 (2021/03/20)
CPU: AMD 5950X
OS: Windows 10 Professional 64bit (21H1) - Fully Updated
Drivers: All up to date from ASUS and AMD
Keyboard DIPS: All set to OFF
Keyboard Firmware: 1.20
-
John Horvath I haven't heard any issues like this before, is it both ALT keys or just one? If it's just one it could be a switch issue, if both are giving you this problem then most likely is not a switch issue.
There is an app you can find called 'switch hitter' which may help you identify an issues - there are numerous keylogger apps you can use if you want to record what is being typed.
If you email us I can send you a new firmware that is not yet released to try.
Thank you.
-
So a couple updates...
I tested the keyboard on a separate machine with USB 3.0 ports and encountered the same issue.
I also received the "WASD Firmware 2.40.exe" after e-mailing, and updated successfully, but it did not resolve the issue.
I do not know if the other ALT key is affected, as I have only had this happen while gaming, and LEFT-ALT is the key I use for moving forward. This could be a combination, or sequence of keys, that causes it, as I use the left hand side CTRL, ALT, SHIFT, Z, X and S for movement; and mainly I notice this when attempting to run (S) forward (ALT).
I installed Switch Hitter, but it doesn't appear to log in the background. So I'm going to look around for something that can log while I game to catch it in the act and try and isolate a pattern and maybe even figure out how to reproduce it consistently.
P.S. Should I revert to the 1.20 firmware?
-
Well, I couldn't find a trustworthy "free" background keylogger, but...
I did some extensive testing with the keyboard this weekend (with the help of my son's computer), and the issue continued to arise.
I tested the following Operating Systems:
- Windows 7 Professional - 64bit
- Windows 10 Professional - 64bit
I tested the following keyboard Firmwares:
- From Factory (Unknown. manual states 0.14, Win10 only)
- 1.20 (Win7 & Win10)
- 2.40 (Win7 & Win10)
I tested on the following USB types:
- USB 2.0 (Win7 only)
- USB 3.0 (Win7 & Win10)
- USB 3.2 (Win10 only)
I tested the following games (on both Win7 & Win10):
- Far Cry 3: Blood Dragon - CryEngine
- Hunt: Showdown - CryEngine
- WarHammer: Verminitide II - AutoDesk StingRay
- Wolfenstein: The Old Blood - id Tech 5
- Remnant: From the Ashes - Ureal Engine 4
In all cases it seemed that pressing ALT followed by S quickly was the trigger scenario, and would in-effect not register the ALT key despite it being fully depressed and held down. Other keys would continue to register fine while ALT continued to be held. It was not consistently reproducible, but within 15min of playing any of the games I could get the issue to occur.
I have to assume this is some sort of defect as this issue does not arise with any other keyboard I tested, for reference I tested the following:
- dasKeyboard 4 Pro
- dasKeyboard Model S Pro
- IBM KB-8923
- Acer SK-9610
-
David could this be a specific issue with the Zealios switches?
My dasKeyboards all use Cherry MX Browns, but I really love the feel of the Zealio (and I've been wanting a CODE keyboard forever).
I'm considering exchanging the keyboard I have, but I'm split on whether to get another Zealio (and hope it was a minor defect) or just get another switch type. I mean if I get another Zealio and the same issue arises, then I would most likely exchange it again (maybe for a Cherry MX Clear). But if I still encounter the issue, then there would seem to be a bigger issue at play (which may be correctible through firmware), but that's a lot of back and forth and extra money. And if it turns out to be a firmware issue, that I'd really want my final purchase to be a Zealio.
Any suggestions?
-
John Horvath That is a lot of testing, I commend you. I can't imagine it is a switch specific issue - but if you'd like to try a different keyboard or even another Zealio board I would be happy swap it out for you. Please just email me and I can set up a replacement for you.
It's odd that it was not reproducible even after seeing the issue occur. At any time did you reset the keyboard? Especially after flashing the firmware?
It might be worth another test after resetting the board if you haven't tried it. Either way please let me know and I can help you out.
Thank you
-
So I received my replacement keyboard today... unfortunately though, it has the same problem. I even tried rolling back to the FW_016_MOD.exe firmware mentioned in this post with hopes it might fix the issue, but alas it did not.
Since I still haven't found a trustworthy "free" background keylogger, I might just grab an open source GitHub project and roll my own; so I can do a little capture analysis to try an identify any sort of pattern associated with these occurrences.
-
John Horvath I'm sorry that the replacement did not fix your issue, please try our older V2.5 firmware located here; https://support.wasdkeyboards.com/hc/en-us/articles/360018518874-Keyboard-Firmware-Updates
If this does not fix your issue please let me know.
Would you like to try a different switch type? I noticed the replacement we sent you was another Zealio.
Thank you.
-
David,
Just a quick update, I have not yet tried the V2.5 firmware (will do that tonight), I actually grabbed a CODE V3 104 (Cherry MX Clear) off Amazon to side-by-side test with and it had the same exact issue (already started the return process on that one), holding onto the Zelios for now.
I did write-up a windows key state logger using a low level pass with GetAsyncKeyState and was able to generate some logs. Below are some extracts from around when the issue occurred:
Version 1.0 - Polling current input state every 5ms and only logging on a change in state (Note this uses Microsoft Virtual Key Code names, so LMenu is Left ALT, this also includes mouse button state), I have added some annotations for clarity. I'm also working on a Version 2.0 that will more finely grained indicate state changes with press and release indicators (when I get that done I'll post it to GitHub).
Zelios_Win7_USB30
2021-07-31 19:23:48:5867 C+LMenu
2021-07-31 19:23:49:0367 XButton1+C+LMenu
2021-07-31 19:23:49:0467 XButton1+LMenu
2021-07-31 19:23:49:1797 XButton1+X+LMenu
2021-07-31 19:23:49:1907 X+LMenu
-------------------------------------------------------------------------------
2021-07-31 19:23:49:7188 LMenu
2021-07-31 19:23:50:0358 S <--<< This should be S+LMenu (LMenu Still Down) Time Diff 00:00:00:3170
-------------------------------------------------------------------------------
2021-07-31 19:23:59:7003 S+LControlKey (LMenu Still Down)
2021-07-31 19:24:01:2814 S (LMenu Still Down)
2021-07-31 19:24:01:9155 C+S (LMenu Still Down)
2021-07-31 19:24:03:4455 S (LMenu Still Down)
2021-07-31 19:24:03:8296 S+X (LMenu Still Down)
2021-07-31 19:24:05:6137 S (LMenu Still Down)
2021-07-31 19:24:07:9608 EscapeZelios_Win7_USB30
2021-07-31 20:07:52:7869 C
2021-07-31 20:07:53:3180 C+LMenu
-------------------------------------------------------------------------------
2021-07-31 20:07:53:3880 LMenu
2021-07-31 20:07:53:8320 S <--<< This should be S+LMenu (LMenu Still Down) Time Diff 00:00:00:4440
-------------------------------------------------------------------------------
2021-07-31 20:08:04:3696 C+S (LMenu Still Down)
2021-07-31 20:08:05:1876 S (LMenu Still Down)
2021-07-31 20:08:05:7017 S+X (LMenu Still Down)
2021-07-31 20:08:06:3887 S (LMenu Still Down)
2021-07-31 20:08:07:3648 S+LControlKey (LMenu Still Down)
2021-07-31 20:08:08:3008 S (LMenu Still Down)
2021-07-31 20:08:10:3419 S (LMenu Up)
2021-07-31 20:08:14:9842 S+LMenu (LMenu Down)
2021-07-31 20:08:16:4683 S (LMenu Up)
2021-07-31 20:08:17:0933 EscapeZelios_Win7_USB30
2021-07-31 20:33:43:9317 C
2021-07-31 20:33:44:1297 C+LMenu
-------------------------------------------------------------------------------
2021-07-31 20:33:44:2857 LMenu
2021-07-31 20:33:44:6257 S <--<< This should be S+LMenu (LMenu Still Down) Time Diff 00:00:00:3400
-------------------------------------------------------------------------------
2021-07-31 20:33:52:6662 M+S (LMenu Still Down)
2021-07-31 20:33:53:2122 M+N+S (LMenu Still Down)
2021-07-31 20:33:53:7642 B+M+N+S (LMenu Still Down)
2021-07-31 20:33:55:6913 M+N+S (LMenu Still Down)
2021-07-31 20:33:55:6963 S (LMenu Still Down)
2021-07-31 20:33:56:4244 S+X (LMenu Still Down)
2021-07-31 20:33:56:8054 C+S+X (LMenu Still Down)
2021-07-31 20:33:59:7646 C+S (LMenu Still Down)
2021-07-31 20:33:59:7696 S (LMenu Still Down)
2021-07-31 20:34:01:9197 S (LMenu Still Down)
2021-07-31 20:34:03:9008 A (LMenu Still Down)
2021-07-31 20:34:09:4951 LControlKey (LMenu Still Down)
2021-07-31 20:34:14:1934 A (LMenu Up)
2021-07-31 20:34:21:5228 A+LMenu (LMenu Down)
2021-07-31 20:34:25:7880 EscapeSo it definitely seems that pressing S quickly after Left ALT will sometimes cause Left ALT to stop being registered (despite being continually physically held down). I did have this occur once while not using S and will try to capture that with my Version 2.0.
-
So I just flashed the V2.5 firmware, and unfortunately the issue persists.
I updated my program and hosted it on GitHub, you can find the source here: https://github.com/Xorcist77/Stateus
Here is my latest log:
↓ indicates the initial press of a key
| indicates a now held down key
↑ indicates a key release
Stateus v1.0.0 - Started: Monitoring 174 possible scan codes... (PollRate = 5ms)
.
.
.
2021-08-03 22:00:59:2979 X| RButton↓
2021-08-03 22:01:00:0326 X| RButton| LMenu↓
2021-08-03 22:01:03:0483 X| RButton↑ LMenu|
2021-08-03 22:01:03:1274 X↑ LMenu|
-------------------------------------------------------------------------------
2021-08-03 22:01:03:2225 LMenu↑ <--<< This should be LMenu| (LMenu Still Down)
2021-08-03 22:01:03:3987 S↓ <--<< This should be S↓ LMenu| (LMenu Still Down)
-------------------------------------------------------------------------------
2021-08-03 22:01:03:7811 S| X↓ (LMenu Still Down)
2021-08-03 22:01:03:7971 S| X↑ (LMenu Still Down)
2021-08-03 22:01:08:1088 S| LControlKey↓ (LMenu Still Down)
2021-08-03 22:01:09:2115 S| LControlKey↑ (LMenu Still Down)
2021-08-03 22:01:10:1389 S| X↓ (LMenu Still Down)
2021-08-03 22:01:11:1459 S| X↑ (LMenu Still Down)
2021-08-03 22:01:11:6095 S| C↓ (LMenu Still Down)
2021-08-03 22:01:12:7762 S| C↑ (LMenu Still Down)
2021-08-03 22:01:14:9330 S| Z↓ (LMenu Still Down)
2021-08-03 22:01:15:1231 S| Z↑ (LMenu Still Down)
2021-08-03 22:01:16:4188 S| LShiftKey↓ (LMenu Still Down)
2021-08-03 22:01:16:4988 S| LShiftKey↑ (LMenu Still Down)
[LMenu physically released at this point, but no change was recorded, Windows still thinks it's not being pressed]
2021-08-03 22:01:23:8054 S| LMenu↓
2021-08-03 22:01:25:6238 S↑ LMenu↑
2021-08-03 22:01:26:2137 Escape↓
2021-08-03 22:01:26:2617 Escape↑
.
.
.Could CPU load or other input devices potentially cause something like this (USB Crosstalk maybe)? I can regularly reproduce this while gaming, during which a lot is going on (including high DPI mouse movements), but have had little success trying to reproduce this sitting at the Windows desktop (where my mouse it almost never moving, though I did try while moving my mouse and it didn't change anything).
-
Okay I'm no expert, but I don't think my USB crosstalk theory is a potential factor, as I just moved the keyboard to my front panel USB which is on a completely different header on the motherboard and I was still able to reproduce the issue, here is the log from that session just for reference:
Stateus v1.0.0 - Started: Monitoring 174 possible scan codes... (PollRate = 5ms)
.
.
.
2021-08-03 22:43:35:0482 RButton| X| LMenu↓
2021-08-03 22:43:36:1001 RButton| X| LMenu↑
2021-08-03 22:43:37:3597 RButton| X| LMenu↓
2021-08-03 22:43:37:9672 RButton| X| LMenu↑
2021-08-03 22:43:38:3516 RButton↑ X|
2021-08-03 22:43:38:3669 X↑ LMenu↓
-------------------------------------------------------------------------------
2021-08-03 22:43:38:4623 LMenu↑ <--<< This should be LMenu| (LMenu Still Down)
2021-08-03 22:43:38:6374 S↓ <--<< This should be S↓ LMenu| (LMenu Still Down)
-------------------------------------------------------------------------------
2021-08-03 22:43:42:3276 S| X↓ (LMenu Still Down)
2021-08-03 22:43:43:3185 S| X↑ (LMenu Still Down)
2021-08-03 22:43:44:1142 S| C↓ (LMenu Still Down)
2021-08-03 22:43:45:3433 S| C↑ (LMenu Still Down)
2021-08-03 22:43:48:1886 S| LControlKey↓ (LMenu Still Down)
2021-08-03 22:43:49:2256 S| LControlKey↑ (LMenu Still Down)
2021-08-03 22:43:50:5005 S| LShiftKey↓ (LMenu Still Down)
2021-08-03 22:43:50:6116 S| LShiftKey↑ (LMenu Still Down)
2021-08-03 22:43:58:6522 S| Z↓ (LMenu Still Down)
2021-08-03 22:43:58:8107 S| Z↑ (LMenu Still Down)
2021-08-03 22:44:01:9901 S↑ (LMenu Still Down)
[LMenu physically released at this point, but no change was recorded, Windows still thinks it's not being pressed]
2021-08-03 22:44:13:1050 LMenu↓
2021-08-03 22:44:14:3165 LMenu↑
2021-08-03 22:44:15:3541 Escape↓
2021-08-03 22:44:15:4022 Escape↑ -
John Horvath That's really great, thank you for trying all of this - this is very odd to me that you're seeing this on the older V2.5 firmware as well, it's strange because we've been using this firmware for a very long time now (since 2013) and this is the first time I'm hearing of any errors like this from a customer.
My devs are asking if you can try this on the V3 V2.6 firmware (although I don't believe personally that it will make any difference). I will email you the latest firmware.
Thank you!
-
Tonight I flashed the V2.6 firmware and ran some more tests. Unfortunately I'm still able to reproduce the issue.
Unrelated... but the V2.6 firmware seems to have inconsistent backlighting while typing. Every so often the keyboard will flash a bit brighter, and while typing this message I have noticed some missed key presses.
One thing I would like to ask is, is it possible that a slight release of the key could toggle the Zealios switch to a fully released state, even though it's essentially still held down. In the latest logs, I noticed I'm moving from a walking strafe to a running forward. In this scenario my middle finger is on the Left ALT with my index finger on X or C. When I go to run forward I move my thumb to Left ALT and my middle finger up to S. I'm definitely not releasing the key fully enough to get the tactile release bump, but there might be the slightest shift of the Left ALT up.
I would like to reiterate, that I have never had an issue with any of my other MX Brown mechanical keyboards, but they have a much slower polling rate (so maybe it was just nnnnnnnnnnnnnnnnnnnnne, um okay, so the n key just stuck, I'm thinking this 2.6 firmware might have other issues, but as I was saying, maybe this micro-release was just never caught on the slower keyboards?) . I'm going to flash back to the latest 1.20 firmware.
Here are the abbreviated logs from tonight (with annotations):
2021-08-05 22:18:25:0373 C↓
2021-08-05 22:18:25:0693 C↑
2021-08-05 22:18:27:0359 A↓
2021-08-05 22:18:28:7291 A↑
2021-08-05 22:18:29:1455 LMenu↓
2021-08-05 22:18:29:6890 LMenu↑
2021-08-05 22:18:30:4737 LMenu↓
2021-08-05 22:18:30:5828 LMenu| X↓
2021-08-05 22:18:30:8383 LMenu| X↑
2021-08-05 22:18:31:0135 LMenu| X↓
2021-08-05 22:18:32:2453 LMenu| X↑
-------------------------------------------------------------------------------
2021-08-05 22:18:32:3414 LMenu↑ <--<< This should be LMenu| (LMenu Still Down)
2021-08-05 22:18:32:5175 S↓ <--<< This should be S↓ LMenu| (LMenu Still Down)
-------------------------------------------------------------------------------
2021-08-05 22:18:33:8744 S| X↓ (LMenu Still Down)
2021-08-05 22:18:34:7201 S| X↑ (LMenu Still Down)
2021-08-05 22:18:37:5476 S| A↓ (LMenu Still Down)
2021-08-05 22:18:38:4244 S| A↑ (LMenu Still Down)
2021-08-05 22:18:39:2412 S↑ (LMenu Still Down)
2021-08-05 22:18:39:7848 A↓ (LMenu Still Down)
2021-08-05 22:18:40:3933 A| L↓ (LMenu Still Down)
2021-08-05 22:18:41:0339 A| L| T↓ (LMenu Still Down)
2021-08-05 22:18:45:1209 A↑ L↑ T↑ (LMenu Still Down)
[LMenu physically released at this point, but no change was recorded, Windows still thinks it's not being pressed]
2021-08-05 22:18:45:9976 LMenu↓
2021-08-05 22:18:46:3498 LMenu↑
2021-08-05 22:18:46:8142 Escape↓
2021-08-05 22:18:46:8463 Escape↑2021-08-05 22:42:34:4930 C| LMenu↓
2021-08-05 22:42:34:5090 C↑ LMenu|
2021-08-05 22:42:34:8934 LMenu↑ Space↓
2021-08-05 22:42:34:9734 Space↑
2021-08-05 22:42:35:0375 LMenu↓
2021-08-05 22:42:35:1646 LMenu| X↓
2021-08-05 22:42:35:3713 LMenu| X↑
2021-08-05 22:42:35:6249 LMenu| C↓
2021-08-05 22:42:36:9789 LMenu| C↑
-------------------------------------------------------------------------------
2021-08-05 22:42:37:1069 LMenu↑ <--<< This should be LMenu| (LMenu Still Down)
2021-08-05 22:42:37:3625 S↓ <--<< This should be S↓ LMenu| (LMenu Still Down)
-------------------------------------------------------------------------------
2021-08-05 22:42:42:7478 S↑ (LMenu Still Down)
2021-08-05 22:42:43:8515 A↓ (LMenu Still Down)
2021-08-05 22:42:45:0290 A| L↓ (LMenu Still Down)
2021-08-05 22:42:46:0495 A| L| T↓ (LMenu Still Down)
2021-08-05 22:42:52:1799 A| L| T↑ (LMenu Still Down)
2021-08-05 22:42:52:7723 A| L↑ (LMenu Still Down)
2021-08-05 22:42:53:4610 A↑ (LMenu Still Down)
[LMenu physically released at this point, but no change was recorded, Windows still thinks it's not being pressed]
2021-08-05 22:42:59:9172 LMenu↓
2021-08-05 22:43:01:4040 LMenu↑
2021-08-05 22:43:02:0438 Escape↓
2021-08-05 22:43:02:0758 Escape↑ -
Just as a follow up, I did some pressure sensitive testing today, trying to slowly release a fully depressed Left Alt and as soon as I saw it release on screen, push it down again to see if I could validate my theory of a micro-release (where the key is physically depressed but registering as released). I was unable to get that to happen though, so I feel this still has something to do with multiple keys being pressed/held in quick succession.
-
John Horvath I didn't suspect the V2.6 firmware would be any different but our developer wanted to know, so thank you for running that test!
As for the disconnect issue, this is an ongoing issue we are investigating, but I have seen it on the 1.20 so it's strange to me that you haven't seen this key repeat (which is the disconnection problem) before, as usually it is tied to some combination of hardware/firmware/software. Please let me know if you see this on the 1.20 at any time.
I'm more inclined to think this is a Zealio switch issue with your particular typing style, as they do feel quite different, and also I haven't heard of any other customers with this problem you're describing. I would like for you to try this on a clear or brown from us, would you like to try that out? I think it would draw a distinction.
Thank you so much for all of your thorough testing, I really appreciate it.
-
David
I actually purchased a CODE V3 104 (Cherry MX Clear) recently off Amazon just to do some side-by-side testing against the Zelio, and confirmed the issue also happened with that model as well (I have already returned it).
If you would be willing to send me a CODE V3 104 (Cherry MX Brown) gratis, I would gladly test it out and post the results. If the MX Brown does not exhibit the issue I would be inclined to keep it and and would return the Zelio for a partial refund. If the issue presented itself on the MX Brown I would just send it back and keep the Zelio (hoping for a future software fix).
Despite the issues I really like the design and feel of your keyboards. And the Zelio with firmware 1.20 has been solid so far during my programming sessions; only giving me issues during gaming sessions.
I plan to continue to update and improve my key state logger (and will shortly host a binary for people who don't want to compile it themselves). Hopefully some others might find it of use.
Thanks again.
-
John Horvath Oh ok great, thank you for trying out a different switch. I can definitely send you a brown, but if you're seeing this on more than one switch already, then I don't think it's the Zeals that are causing what you're seeing. I've already let our developers know and linked them to this thread, so hopefully they can have some better insight as to what might be causing this.
It's really up to you what you'd like to do regarding return for refund or partial refund, or trying the browns, please just send me an email and let me know and I can set up a return or whatnot.
That's great that you built this tool, please share it with other people as I'm sure there are more uses for it! Thank you.
-
David, At this point I'm hopeful a future firmware update can resolve the issues. I'll check back regularly for new firmware updates and test them accordingly and post my findings here. I'll also do some regular usage (i.e. non-gaming) with each update to see if any of the other issues arise (like the sticky keys, which I saw in an older firmware).
-
John Horvath I actually just got a new firmware last night from our dev, I will email you and you can test it out and let me know. They didn't go into the specifics of what they changed but there were a few things I brought up to them previous to this, so this may affect this issue but may not. I will email you now with it, thanks!
-
John Horvath Thank you for testing and I am very sorry to hear that. I will alert my devs again to see if they can figure this out.
I know you tested this with our V2.5 firmware on your V3, but I'd be curious if you could reproduce this on an actual V2 keyboard (that has different hardware than our V3) Could I send you one to test? Let me know if you'd like to try that out. Thank you.
-
John Horvath Ok great, actually my developer is asking for step by step to reproduce this, can you let me know how you run your app that you've made? Is this run in CMD prompt? I'd like to get them a way to test this so they can reproduce it on their end.
I was going to instruct them to run your logger, then just keep holding 'alt' and pressing 's' randomly?
Thanks!
-
Yes the logger is a Windows Console Application, it does not require an install, just download the release from:
https://github.com/Xorcist77/Stateus/releases/download/v1.2.0/Stateus_v1.2.0.zip
unzip and run it, it will begin logging to a time-stamped file in the same folder.
My "goto" test is to start the logger and then run Hunt Showdown and just play the game (but as I previously listed I got this to occur with a variety of games/engines). I normally get the issue to occur pretty quickly with my key setup, which is:
L-ALT = Move Forward
L-CTRL = Move Backwards
C = Strafe Right
X = Strafe Left
Z = Jump
SHIFT = Crouch
S = Sprint
In a majority of the cases (like 99% of them) the issue arose when first pressing/holding L-ALT followed by quickly pressing S, which appears to makes the keyboard signal a release of L-ALT, despite it still being physically held down.
I assume holding L-ALT and pressing S repeated might make it occur, but I have little luck reproducing this while sitting at the windows desktop (I have tried several times). Every instance I have recorded has been while gaming.
-
John Horvath My devs were wondering what game specifically this is happening in, and it made me wonder if this is happening in other games? I find it odd that this can't easily be reproduced just in windows desktop, in your testing were you able to get it to trigger at all or only in the game?
Would it be possible for you to take a video of it happening with the game and your tool to show them? Thank you!
-
David I did outline some of this in an earlier post here.
But to summarize, I tested 5 different games (4 of which have different engines) on two different operating systems (Win7 & Win10) across 3 different USB versions (2.0, 3.0, 3.2) with two different V3 switch types (Cherry MX Clear and the Zealio 67g). At the time I tested the from factory firmware, as well as flashed v1.20 and v.240.
I can definitely try to setup a webcam this weekend to capture both the screen and keyboard. While I don't have a second webcam, I might also be able to use my phone to get a top down view of the keyboard to better indicate my keypresses.
So far I can only reliably reproduce this issue while gaming, but I can continue to do some desktop testing as well.
Please sign in to leave a comment.
Comments
51 comments