inconvenient delay when drag scrolling.

[itsnoteasy]

inconvenient delay when drag scrolling.

[jfedor2]

Can you export your configuration to JSON and post it here?

[itsnoteasy]

inconvenient_delay.json
here you go.

[jfedor2]

I don't have a Slimblade, but in my tests I'd say the layer activation delay matches what you have set for the tap-hold threshold (400ms).

[itsnoteasy]

ah that makes sense. forgive me if i have asked about this issue before, which i suspect it wasn't my intention to be repetitive. this should be added to a frequently asked question page.
I think that in theory it should be possible to create a faster layer dedicated to scroll wheel events, because they would not be triggered accidentally due to requiring a specific ball motion in conjunction with the button press.
This would be similar to the concept of speculative execution in a modern 64 bit cpu.
hid-remapper would enter a layer in parallel with the button tap, perhaps on an extra unused core.
I will think about it when i am less tired.

[itsnoteasy]

I managed to fix the issue. I created an extra duplicate layer for drag scrolling, with the only change being that it has the tap flag set, whereas the original drag scroll layer was set to hold. This avoids double scroll events and the lag.
hid-remapper-nodelay.json

[jfedor2]

Have your tried a simple "left button -> Layer X" mapping, no tap, no hold?

[itsnoteasy]

seems to work fine with your suggestion, though i had to add a v scroll to v scroll mapping on layer 1 to make it less confusing when the wheel didn't work.
I think in older versions, doing this would tend to break the button function. you had to use separate tap and hold to be usable.