rolls for the same shifted and unshifted symbol do not work

[0x4d0x4b]

Firmware 11.1.1 | Agent 4.2.0

Given that shifted and unshited characters typically belonging to the same physical key are defined on the mod layer

then a roll of those keys to produce += sequence does not work and produces only the first character +.
This is also true in opposite direction where =+ would be expected but only = is produced.
There has to be a release of the first key before the second key press for that to work.

Rolls of characters not belonging to the same key on typical layout like -= or *= etc are working fine when defined and executed in similar way.

[kareltucek]

Well, indeed.

However it is expected and by specification quite correct, so I am not sure if we should be introducing an artificial release of the scancode. (UHK sends scancodes, not characters)

On your side you can fix it by creating a macro - that would just tap the key and release immediately.

[kareltucek]

Although, given the already existing logic for extra modifier reports (for a shift+a, we send first a [shift] report, and just then [shift,a] report), we could also add a "negative key mask" that would globally disable a specific scancode during that one report.

Although I don't know how to implement this globally (so that it works for macros too) without it costing some 150 extra bytes of memory.

@mondalaci opinion?

[mondalaci]

This is such a niche use case that I wouldn't increase complexity and resource consumption; rather, I would suggest using macros.

[0x4d0x4b]

Thanks for clarifying, I can use macro for this.
However, it might not be such a niche and that might pop up again for some international layouts.
I gave more software dev oriented example and on a mod layer, but the same is true if user has a base layer with easy accessible language specific characters ł which is RAlt(Gr)+L for my language and then attempts to roll łl during fast typing.

[kareltucek]

I believe that most users don't split characters available by one key to multiple keys, although it definitely is a valid usecase.

As for this to be a rare issue/usecase, I believe that you are the first one to raise this in the last 8 years, so yes, it is a rare occurrence (independently of whether the usecase is valid and independently of whether and how it should be supported).

[0x4d0x4b]

Hopefully that's not because I am the only one, but because UHK is gaining popularity and user base is growing so the firmware have bigger exposure.

Anyway, I just wanted you to be aware of the issue as combinations can be multiplied like some shortcuts involving the same key launched in quick roll involving a Tab or arrow keys etc.

[mondalaci]

We appreciate your report! Do you need help with macros to implement the desired behavior?

[0x4d0x4b]

I should be fine. I just need to identify all possible combinations that can be affected like sequences from a symbol and numbers layer

• typing (900) would affect me twice at the beginning and and of parentheses
• typing some hex colors starting with #3
• same with >.< or >,< or /?
  That's a lot of keys and macro bloat I suppose. Is there some clever way to handle all the cases with a single macro?

[kareltucek]

Nothing suitable at the moment I am afraid, but we have improving "generic macro" support on our todolist. Unfortunately, we have other priorities at the moment though.

You can check https://forum.ultimatehackingkeyboard.com/t/parametrizable-smart-macros-brainstorm-for-future-specification/1338/4 and maybe share some ideas on how to do that exactly.

That's a lot of keys and macro bloat I suppose.

Well, this is a blocker indeed. I think we should support some way to make this usecase easier to handle. It is a reasonable usecase after all. (Although the note about priorities unfortunately still holds.)

[kareltucek]

There is the activateKeyPostponed command. I think you might be able to use it with the prepend parameter for this usecase. It allows you to queue an actual key (not scancode) activation for execution, and allows you to select different layer.

However, it is a hacky solution that I am not at all happy about.

[0x4d0x4b]

Unfortunately, we have other priorities at the moment though.

Understood, thanks.
For now I think I will try to release keys quicker for problematic sequences and avoid pollution in my config macro space.
Hopefully, some systemic solution to the issue will come with some future releases.

[kareltucek]

@mondalaci let's leave this open please