TaranVH
CTRL+ALT stuck on down position with intercept.exe
Hi there!
I have recently bought a multi-button mouse and I have been looking into how I could assign a function to each of those buttons. Since this mouse is a cheap model (not from any known brand), it is not a programmable mouse and acts exactly like a keyboard.
I found your video on LTT and that lead me here, where I found intercept. It works almost perfectly for my use case, so I am using only intercept.exe in the background.
I use a lot of keyboard shortcuts that include CTRL and ALT buttons (assigned to some other functions such as volume up, down, switching audio device, turning off monitors...etc.), and it seems that they "virtually" get locked on the down position when using intercept.exe.
I have tried several things such as editing keyremap.ini to place these back up twice, for example:
combo=1d,0,0|38,0,0|27,0,0|27,0,1|38,0,1|1d,0,1|38,0,1|1d,0,1
Instead of just:
combo=1d,0,0|38,0,0|27,0,0|27,0,1|38,0,1|1d,0,1
But it still seems to get stuck very often so that didn't work.
Until I find a better solution, I have assigned a button on my mouse specifically to put CTRL and ALT back in the up position:
[9_CTRLALT_UP] device=HID\VID_04D9&PID_FC4D&REV_0152&MI_01 trigger=a,0,0 combo=38,0,1|1d,0,1
Here is what my keyremap.ini looks like if you want to get a better idea: https://pastebin.com/KxBxZ21D
To this day it has been a great experience to have such a simple solution to create macros on keyboard buttons, but since this issue is starting to get annoying (having to press a button every time it happens) I decided to open an issue here.
Hope you could shed some light on this
Aside from that, much thanks for all your amazing work!
I call this the MODS error, as in "stuck MODifiers." I have no idea how to fix it. I get the same thing, even though I don't even use interception anymore. Though, I get it far less often than you do. One trick I've been using to to only have one iCue profile. No more auto switching to and from the premiere profile. I believe that if a profile switch is done before a macro finishes (which could include modifier UP events) they might not complete. But even that hasn't fully fixed the problem. So yeah. I have ATL CTRL and SHIFT up events at the end of a lot of my macros now in AHK, which does in fact help the problem a lot.
I saw you talked about the same problem on another thread, I believe I have found something that seems to work a little better after looking at some keyremap.ini examples on this github.
Instead of just one macro per button, I made 2 (button down, and button up). Now this is what my macros look like, for example with CTRL+ALT+M:
[1_volume_up_D] device=HID\VID_04D9&PID_FC4D&REV_0152&MI_01 trigger=2,0,0 combo=1d,0,0|38,0,0|27,0,0|27,0,1 [1_volume_up_U] device=HID\VID_04D9&PID_FC4D&REV_0152&MI_01 trigger=2,0,1 combo=1d,0,1|38,0,1
You can notice how the 'M' button up event is on the first trigger (down), because I found that it interfered often with putting CTRL and ALT back up when placed on the second trigger (up).
I haven't tested for more than 5 minutes yet but I think the problem is 'partially fixed'. I kept spamming my macros to see if it solved it, and it seems to be happening way less often than it did before.
Ah, very clever! Yes, I believe the STUCK MODIFIERS bug is caused by bad timing of the UP event. In your case, it was happening at the exact same time as the DOWN event, which was causing issues. In my case, I actually have a 10ms delay built into the key events sent from my Corsair K95 RGB keyboard, but the AHK scripts would begin doing their stuff at the same time. So a CTRL UP or SHIFT UP event would occur at some semi-random time while the AHK macro was going, which would mess it up. I'm now going to add 11 ms delays before all relevant functions.
On Wed, Apr 8, 2020 at 11:18 AM MasterBubbles [email protected] wrote:
I saw you talked about the same problem on another thread, I believe I have found something that seems to work a little better after looking at some keyremap.ini examples on this github.
Instead of just one macro per button, I made 2 (button down, and button up). Now this is what my macros look like, for example with CTRL+ALT+M:
[1_volume_up_D] device=HID\VID_04D9&PID_FC4D&REV_0152&MI_01 trigger=2,0,0 combo=1d,0,0|38,0,0|27,0,0|27,0,1 [1_volume_up_U] device=HID\VID_04D9&PID_FC4D&REV_0152&MI_01 trigger=2,0,1 combo=38,0,1|1d,0,1
This is a format with which it seems to stop occurring. You can notice how the 'M' button up event is on the first trigger (down), because I found that it interfered with putting CTRL and ALT back up when placed on the second trigger (up).
I haven't tested for more than 5 minutes yet but I think the problem is finally fixed. I kept spamming my macros to see if it solved it, and it seems like it did.
I'll be re-posting an update in 1 or 2 days to confirm whether the issue is really completely gone or not
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TaranVH/2nd-keyboard/issues/110#issuecomment-611113530, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD2MGX26TZMNPU7SF7EWZATRLS5XDANCNFSM4MDU2QFA .
Following up on this 2 years later. Using this method (that I have modified a little since then), I can confirm that I haven't seen any ghost key behavior and that it is completely fixed for me. I have decided to get the process automated for modifying the keyremap.ini and have created the following repository: End-Ghost-Keys