Shift Modifiers Don't Work for Some Functions

Up to this point, these key combinations in the software have not worked. We should have hidden these key combinations from the UI as these combinations have not worked in the past. We will add these key combinations to the requested features list.

I'm also having problems getting a capital D with the shift modifier. The problem is intermittent regardless of which key I use to select the layer with the modified keys. Any known issues like that?

Since what I'm trying to do is being classified as a requested feature, while I think it is a good idea regardless, my preference would be to have the modifier key hold shift simultaneously vs programming every key and button to be shift modified. Now that I type that, I think maybe it changes nothing in the request. Like if the shift modifier worked for function keys, maybe I could have assigned it to Function Green instead of every button on the Green layer...

My base layer doesn't have a forward slash, and the only forward slash on my Green layer is shift modified to behave as a question mark. There are no shift keys on the green layer. I locked the green layer on and was able to get this output:

D?D?D?D?D?D/D?D?D?D?D?D?D?

It appears the intermittent failure of the shift modifiers isn't specific to the D key after all. How do we troubleshoot this?

I continue to see this, and it continues to seem random, so I thought I should bump this thread. For instance, today, when I was typing "FOSS" while holding the shift modifier down, I got "FOsS" instead, and I was holding the modifier key with my left hand on the left device while all three of those letters are on the right device and were typed with my right hand. The hands shouldn't be incredibly relevant since I've already established that this occurs even with the layer locked in, but they demonstrate that it is unlikely that I lifted off of the key due to a stretch or something. FWIW, I seem to encounter this behavior when typing passwords more than anything else, and I'm not typically typing them quickly on this new device and layout yet. I thought I should point that out because both of the examples I've posted could make it look like this specifically occurs with rapid typing. Incidentally, I've also seen it occur while holding the modifier key and a single letter, but in that case, it happened after several repeats and then for several repeats. Put another way, in that instance, the output was something like "DDDDDDDDDDDdddddddd".

I should imagine this will turn out to be a firmware bug, but is there a published procedure for troubleshooting this type of behavior?

Dustin, we've been discussing this and there are pros/cons for each way we deal with it. The core problem is that the computer doesn't have a capital D or actual ? keys. We have to simulate the modifier keys being pressed and released. If we make it release the modifier (shift) instantly for each key after the capital letter is sent, it would probably fix the problem you are mentioning but would also cause other problems. We're still thinking the best solution.

In my mind, holding shift is holding shift, so a shift modifier should apply the same way (with shift not being released at all so long as any key/button with a shift modifier is still pressed), and in that scenario, because it's modifying the action of a key, I should imagine it would apply shift briefly before the key's primary action and not release shift until after also releasing the key's primary action. However, I'd be interested in understanding the cons to this method. Without knowing what they are, I could only suggest that it might make sense to tackle it "both ways" so that users can choose whether shift is being held or briefly pressed.

In case it helps as context for my opinion here or any explanation about the pros/cons of the methods available to you, an anecdote: Once upon a time, I had a Fingerworks TouchStream, and holding a CTRL gesture on one hand while repeatedly using arrow keys and the space bar (or mouse movement and clicks) to select items with the other would lead to the CTRL press being dropped after a number of actions measurable in tens (way more than 10, way less than 100), but I should imagine that behavior would arguably be a firmware bug.

One of the undesired behaviors would be that if you hold down a capitalized A, we have to hold Shift and press "a". If you press another key that is not capitalized (such as a lower case b) while "A" is still held down, it will also be capitalized as B. So, we could fix one problem, but it just creates another since the OS doesn't natively understand capital/lower case letters.

Yes, probably the best compromise is to allow a setting for modifier keys that immediately release the modifiers after the letter is sent. So it would send Shift+a for a capital A, then release both immediately after. Our previous versions of KeyMouse allowed this. We'll bring it back.

Just to be sure we're on the same page, most of my issues involve modifiers not applying at all (due to the fact that they aren't set up in firmware yet) or not applying consistently (as in #2617 and #2650), so while that change may help other people in other scenarios, it doesn't resolve my issue, which is that my "shift layer" output isn't consistent. I don't have any keys or buttons on my "shift" layer that I don't want to be shifted when I'm holding the function key for that layer, so the con you mentioned doesn't apply to my scenario, but it's easy to understand how someone else could want to configure in such a way that it would. That having been said, something like an "unshift" modifier might be a good solution for that, but that could also lead to some interesting intricacies.

Just for the record, it has come to my attention that the shift modifiers appear to have a significantly greater (50% or more) failure rate when typing in a Server 2019 Hyper-V VM window loaded on a Remote Desktop connection. I wanted to bring this up in case it could be helpful in testing or investigation.

@Dustin That's strange. We had this issue on previous KeyMouse 100 series devices when we had the option for key combinations that would send instantly...for example sending an @ symbol would do Shift down, 2 down, 2 up, shift up within a few milliseconds. The current 300 series devices hold the keys down as long as you are holding them down so I would not expect it to have this issue, but I wonder if it's sending/releasing the shift down & 2 down too closely to each other for the terminal to recognize. I tested on Remote Desktop and it was working good for me.

If you can capture this on video either with screen recording software or phone, and email to us, it will be very helpful. We use TechSmith Capture for simple capture of screen video or screenshots and it can upload to a URL for easy emailing.

I'm not sure exactly what you want me to record, any typing done while recording on screen doesn't really show what keys are being pressed, and the issue is intermittent in all cases. I don't mind trying to capture video or debug info, but I'd need more precise instructions to be sure what I capture will be useful.

Incidentally, I did just manage to reproduce the issue with the D key fairly consistently while locked on the layer where D is shift modified, though, so maybe try this?

Create a shift modified D key, press and hold, quickly release, press Enter, and press and hold D again. Here's the output when I do that:

DDDDDDDDDDDDDD
DDDDDDDDDDDDDDD
Dddddddddddddddd
Ddddddddddddd
Dddddddddddddddd
Dddddddddddddddd
Dddddddddddddddd
Dddddddddddddd
DDDDDDDDDDDDDD

As you can see, it doesn't happen every time, but it should surely be reproducible. To reiterate, this happens with all keys, but it seems to happen more often with D for me (that may simply have to do with how often I type my own name).

I have e-mailed the support address with a link to a video of some of this.
In the video, you may notice I get a 9 instead of a ( in one case. That is a completely separate layer, but still a shift-modified key.

While recording the video, I believe I figured out what is causing some of my issues, and I'm afraid it could have to do with the silent red switches I selected when ordering. I chose these for the lower operating force, but I believe they also have less travel before activation. For this reason, I suspect I am hitting a new key prior to release of the previous one being detected (for instance, in the example above, I believe I was intermittently hitting D before fully releasing Enter, so the release of Enter was triggering the release of Shift even though D is shift modified). One instance not shown in the video that is different, but may have the same root cause is that I often get $# when trying to type $3, but $4 always works fine. In this case, a shift modified 4 is under my index finger with a 3 under my middle finger, but the not-shift-modified 4 requires use of the same index finger. I suspect that the 3 is triggering before the shift-modified 4 release is detected, and that obviously can't happen with the 4.

I think this helps me understand the key modifier conundrum better, but it seems solvable. For instance:

Regarding my shift-modified layer, if the layer key was holding shift, no other key would need to be modified (so it would also work for mouse clicks). That would only solve half of the problem, though, because I also want to be able to shift-lock, so I'm not sure how I'd pull that off unless layer modification was an option so shift would always be held while in the layer or a macro could be triggered to hold shift until another macro was triggered to release it (that would be less ideal than layer modification, but either one could be a rabbit hole).

Regarding the $# vs $3 issue (which is only an example and certainly happens with other key combinations such as %3, #4, and +4), it might be possible to very briefly delay sending the keystroke for a non-modified key when it occurs after a modified key. This could be similar to a debounce in practice, or it could include some logic to see if the prior key is being released or not.

In case it is helpful when deciphering some of the key sequences discussed, I am also attaching my current layout to this post. FWIW, the "RMod" note on it refers to a key that doesn't exist due to the layer limit in place at the time when I created the layout (IOW, now I remember what the additional layer I wanted was for).

Dustin, thank you very much for the video and the detailed reports. It helps a ton. We'll see what we can come up with for solutions.