TapHoldManager VS AutoHotInterception

> I have swapped Caps Lock and Escape on my Linux personal laptop and I have grown used to it.

I'd also suggest "home row modifier keys" (or "home row mods").

The idea is to have the key behave the same when tapped, but differently if held. (e.g. https://github.com/evilC/TapHoldManager implements this for AHK)

With home row modifiers, Shift/Ctrl/Win/Alt are put underneath fdsa (and jkl;). -- This reduces the need to use pinky fingers for these keys, & the fingers get to remain on home row more.

Are you running Windows? If so here's the relevant bits of my script. Also worth a look - https://github.com/evilC/TapHoldManager

The thing is, to make up for the small number of keys available, I want to use EvilC's TapHoldManager library to achieve this. I have spent the past few days increasing my knowledge of this library.

Like the good u/G1ZM03K said, TapHoldManager is the way to go as is a battle tested method (5+ years and hundreds of users). It also plays nice with AutoHotInterception which is a handler for a keyboard kernel driver.

Check out the TapHoldManager ( AHK Boards / GitHub ) library by /u/evilC_UK

Have a look at this, it's quite robust and surely will have what you need https://github.com/evilC/TapHoldManager

Since you mentioned VR, I suppose you could try TapHoldManager which will allow you to double/triple/long press (any # of taps really) your KB buttons. I didn't suggest it earlier since you I assumed you would be putting stickers on your macro KB.

For this you are honestly best off using this library https://github.com/evilC/TapHoldManager as it works flawlessly and provides extra flexibility

You can achieve that with Autohotkey and AutoHotInterception, which allows you to capture keypresses at a driver level from a specific input-device. I used that for turning a bluetooth numpad into a little macro pad.

I've had some good experiences with using Luamacros to intercept a second keyboard and forward the keypresses to autohotkey like this: https://miquelvir.medium.com/secondkeyboard-1c39e52e023b

Apparently there is also this: https://github.com/evilC/AutoHotInterception

AutoHotInterception might be a workaround for this. The docs cover how to do everything.

This may be what you're looking for: https://github.com/evilC/AutoHotInterception

I believe this is what you're looking for. Sorry, I haven't tried it yet.

I haven't used it yet, but I found AutoHotInterception which uses an "interception" driver to get you hotkeys with a lower level of keyboard interception - this will likely work for Dosbox, though it might be a bit excessive. I'll play around with it tomorrow and see how it works.

I would suggest using an alternative shortcut as CTRL+ALT+DEL is not something you generally want to mess with - but this library https://github.com/evilC/AutoHotInterception may help you achieve your goals, it is capable of blocking the input of ctrl+alt+del...

AHK can't differentiate between keyboards by itself. You need to use AutoHotInterception to find out which keyboard sent the data.

I used AutoHotInterception for making a cheap little bluetooth numpad into a macropad.