No matter how they're remapped, Win+L always locks Windows, and then emits configured remapping

[riotrah]

Not using interception driver (yet).

Say I've implemented capslock+L = right arrow, and then win+capslock+L therefore = win+right arrow. When I press that latter combo:

0. (bearing in mind win+right arrow should = move active window to the right of screen)
1. Windows will lock
2. But after I log back in, the active window is now indeed moved to the right
3. Sometimes if my computer is slow enough, I'll see the movement before the lock

Would interception driver help with this?
Any ideas?

[riotrah]

Apologies for the issue noise @jtroo, it appears I missed the bottom part of your comment from this discussion where you'd explained some relevant details and suggested interception.

If you'd like, I could close this, keep it open with my findings for future searchers or move it to an answered discussion.

[GrewHair]

@riotrah, FWIW, you can just disable the locking feature altogether in Windows, and then Win+L will work as expected. Check here.

I use it all the time because in i3-inspired window managers Super+L means "focus the window to the right", and I can't live without that.

When I really need to lock the screen, I just edit the registry as described in the link to enable locking again, and then hit Win+L.

You can probably script it, although I haven't tried.

[gerhard-h]

my experience is as follows (pysical Winkey is not mapped i.e. mapped to lmet)

Hitting pysical Winkey + pysical L-key always triggers Lockscreen
but
Hitting any key mapped as Winkey + pysical L-key never triggers Lockscreen

P.S. strange enough for G-key the rule is different:
Any Winkey (mapped or pysical) + pysical G-key triggers XBox Game Bar

[jtroo]

Yea there's unfortunately not much kanata can do on Windows about this issue, when using the default LLHOOK mechanism. Feel free to close the issue if the existing suggestions are satisfactory, or if you have any other questions, you're welcome to ask 🙂