That's what i did. It's worked super well. Finding a keyboard i liked that worked with that was the hardest part. As it is my keyboard's brand (Keychron) had support in QMK, but the model did not. I had to hack a bit to get there, but in the end it worked.
Sad thing is that was two years ago and i've forgotten how to flash it lol.
I can't wait until something like Rust's QMK (i think RMK?) starts to work on more boards. My board having complex modes but the ease of it being written in Rust (because i love Rust) would be a dream for me.
If i could i'd write those type of Rust-QMK for both my Keyboard and Mouse. It really feels great
This looks like it might work on my ordinary Dell Latitude laptop, which certainly doesn't support QMK for its internal keyboard as much as I wish it did!
Yes it does but a lot more. I've personally switched to using only Keymapper even though my keyboard runs on QMK. There's a lot of features but the killer one for me is the context awareness. You can have different mappings based on the application, device or OS.
I was a Windows user since like windows 3.0. With ISO German Keyboards. I never had to retrain my muscle memory to anything else, until I decided its time to buy a Macbook about 1.5 years ago.
Since then I'm struggling with Karabiner to get the key mappings right.
And its not just command -> control to map cmd+c to ctrl+c for copy etc.
It's also weird things like the ^ or the <> not being mapped on the right part of the keyboard. This is especially apparent (sometimes?) when I use an external keyboard (e.g. the sharkoon purewriter, but not limited to). It's a really weird issue, because on the internal mac keyboard its mapped correctly, while on the external one its not. Then I go into karabiner, select the external keyboard and remap _just for the external keyboard_ the few keys are not mapped correctly. And then weeks go by, it works, and suddenly the keyboard keys are correct without the mapping and the remapping now is the problem, so I delete them.
It's not bothering enough to write an issue on karabiner. Heck, I'm even convinced its not even a karabiner issue, its something else. But I'm not deep enough into the mac system to understand where I should even look, if its even possible.
If someone is using houmain to remap keys, can you maybe share a config that would map MacOS keys back Windows for someone who has a deep ingrained windows-style muscle memory? I just briefly looked through the docs, not sure if I missed it, but can houmain just remap keys for certain keyboards, but leave others unmapped?
That’s funny - fellow German here, also using macOS with ISO DE keyboards and running into the exact same issue with Karabiner elements. Sometimes keyboard work out of the box, sometimes I need to swap < and ^, sometimes the keys are swapped on the internal keyboard even though I’ve only applied the key swaps for specific devices.
So far I haven’t really cared enough to figure out what the problem is and just remap whatever’s wrong in Karabiner directly, but I would also like to know how to fix that.
"cross-platform" is interesting. I've been using Keyboard Maestro on MacOS (highly recommended, it does a lot of useful stuff) and this, in combination with UHK keyboards (https://ultimatehackingkeyboard.com) and their switchable keymaps, has been working well for me so far. But, getting something like Keyboard Maestro on Linux would be quite useful indeed.
Cool. I run Windows, MacOS, and Linux on a regular basis. Been looking for ways to use F-keys 13 through 24 to enable useful functionality. Maybe keymapper can help.
Based on a quick skim of Kanata's documentation, it does not appear to be context aware, e.g. have different mappings based on the application or device. This is of course a matter of preference, but I find Keymapper's configuration format more straightforward. It doesn't try to mimic QMK & friends. Rather than layers it has contexts. The concepts are similar but unlike layers, you can multiple context active at a time. Keymapper is really flexible. Pretty much your imagination and willingness to tweak stuff is the limit.
I have a question that’s somewhat unrelated but also related. Has anyone already figured out how to remap windows (and Linux) keyboard macros for brackets (i.e. {}[]) on DE ISO keyboards to behave like they do in macOS?
Everytime I develop on Linux or windows it drives me crazy that my muscle memory can’t figure out which keys to press
It would be helpful to explain which behavior you seek. Not everyone has MacOS, and even less have MacOS with DE ISO-layout, in case this layout is doing something more special than the normal ISO-layout.
On macOS, brackets are achieved by using Alt+5 and Alt+6, curly braces are achieved using Alt+7 and Alt+8. On windows curly braces are sat around the brackets, so for curly braces you’d use AltGr+7 and AltGr+0 and brackets would be AltGr+8 and AltGr+9.
There’s similar discrepancies for pipe, backslash and others, all of which are confusing to muscle memory when jumping between OSes.
I’m aware I could just use something like a windows alternative for Karabiner elements to manually remap each macro(?), but maybe somewhere out there knows of something that just remaps everything to how it is on a specific other OS.
Interception is LGPL[1], the issue is that Windows requires drivers to be signed and code signing certs aren't cheap. That's also why interception has not updated in years to fix the bug where it only supports 10 devices to be connected each boot (each reconnects count as a separate device)[2].
The library is LGPL for non commercial purposes. A contradiction. Drivers and installers are called binary assets. Access to all source code is provided with a commercial license.[1]
Oh right, I keep forgetting that. The LGPL part is just the library that lets apps talk to the driver.
I still think the main thing Interception has going for it is code signing. I once wrote a keyboard filter driver for personal use, but due to signing requirements I never felt it was worth the trouble & cost trying to use it past the computer I developed it on (and then later moved to firmware based solutions like QMK).
The LGPL license applies to the code that they do provide. It's kinda misleading but you have the option to pay and get the code, or not pay and only get what you see. Seems fair enough.
The contradiction is not the library is LGPL and the driver and installer are proprietary. The contradiction is LGPL does not allow a non commercial restriction.
It's a pity there isn't a software tool like this that can add random delays between key presses. It would be useful to prevent the kind of fingerprinting Deepseek does.
I researched such a tool yesterday but couldn't find one, so I created one using xte, but it's not really seamless.
I wonder if this will finally give a solid, cross-platform way to make the Caps Lock key work as it should: press for escape, hold for control.
May I suggest the absolutely awesome Extend Layer [0] instead?
Arrow keys, advanced cursor movement and modifiers chording, and more, without leaving the home row!
[0] https://dreymar.colemak.org/layers-extend.html
the easiest cross platform way is to use qmk and flash some firmware on the keyboard itself to map that. tons of software tools for this now
That's what i did. It's worked super well. Finding a keyboard i liked that worked with that was the hardest part. As it is my keyboard's brand (Keychron) had support in QMK, but the model did not. I had to hack a bit to get there, but in the end it worked.
Sad thing is that was two years ago and i've forgotten how to flash it lol.
I can't wait until something like Rust's QMK (i think RMK?) starts to work on more boards. My board having complex modes but the ease of it being written in Rust (because i love Rust) would be a dream for me.
If i could i'd write those type of Rust-QMK for both my Keyboard and Mouse. It really feels great
This looks like it might work on my ordinary Dell Latitude laptop, which certainly doesn't support QMK for its internal keyboard as much as I wish it did!
While that's true, QMK isn't context aware. You can't have application or OS specific mappings for instance.
Edit: typo fix
Yes it does but a lot more. I've personally switched to using only Keymapper even though my keyboard runs on QMK. There's a lot of features but the killer one for me is the context awareness. You can have different mappings based on the application, device or OS.
it would help to know what your tried. kanata?
So I got this really weird thing on MacOS ...
I was a Windows user since like windows 3.0. With ISO German Keyboards. I never had to retrain my muscle memory to anything else, until I decided its time to buy a Macbook about 1.5 years ago.
Since then I'm struggling with Karabiner to get the key mappings right.
And its not just command -> control to map cmd+c to ctrl+c for copy etc.
It's also weird things like the ^ or the <> not being mapped on the right part of the keyboard. This is especially apparent (sometimes?) when I use an external keyboard (e.g. the sharkoon purewriter, but not limited to). It's a really weird issue, because on the internal mac keyboard its mapped correctly, while on the external one its not. Then I go into karabiner, select the external keyboard and remap _just for the external keyboard_ the few keys are not mapped correctly. And then weeks go by, it works, and suddenly the keyboard keys are correct without the mapping and the remapping now is the problem, so I delete them.
It's not bothering enough to write an issue on karabiner. Heck, I'm even convinced its not even a karabiner issue, its something else. But I'm not deep enough into the mac system to understand where I should even look, if its even possible.
If someone is using houmain to remap keys, can you maybe share a config that would map MacOS keys back Windows for someone who has a deep ingrained windows-style muscle memory? I just briefly looked through the docs, not sure if I missed it, but can houmain just remap keys for certain keyboards, but leave others unmapped?
That’s funny - fellow German here, also using macOS with ISO DE keyboards and running into the exact same issue with Karabiner elements. Sometimes keyboard work out of the box, sometimes I need to swap < and ^, sometimes the keys are swapped on the internal keyboard even though I’ve only applied the key swaps for specific devices.
So far I haven’t really cared enough to figure out what the problem is and just remap whatever’s wrong in Karabiner directly, but I would also like to know how to fix that.
And I thought I have the only bad apple...
. . .
sry, I see myself out.
"cross-platform" is interesting. I've been using Keyboard Maestro on MacOS (highly recommended, it does a lot of useful stuff) and this, in combination with UHK keyboards (https://ultimatehackingkeyboard.com) and their switchable keymaps, has been working well for me so far. But, getting something like Keyboard Maestro on Linux would be quite useful indeed.
Cool. I run Windows, MacOS, and Linux on a regular basis. Been looking for ways to use F-keys 13 through 24 to enable useful functionality. Maybe keymapper can help.
Any comparison with https://github.com/jtroo/kanata ?
Based on a quick skim of Kanata's documentation, it does not appear to be context aware, e.g. have different mappings based on the application or device. This is of course a matter of preference, but I find Keymapper's configuration format more straightforward. It doesn't try to mimic QMK & friends. Rather than layers it has contexts. The concepts are similar but unlike layers, you can multiple context active at a time. Keymapper is really flexible. Pretty much your imagination and willingness to tweak stuff is the limit.
I have a question that’s somewhat unrelated but also related. Has anyone already figured out how to remap windows (and Linux) keyboard macros for brackets (i.e. {}[]) on DE ISO keyboards to behave like they do in macOS? Everytime I develop on Linux or windows it drives me crazy that my muscle memory can’t figure out which keys to press
It would be helpful to explain which behavior you seek. Not everyone has MacOS, and even less have MacOS with DE ISO-layout, in case this layout is doing something more special than the normal ISO-layout.
Good point, sorry.
On macOS, brackets are achieved by using Alt+5 and Alt+6, curly braces are achieved using Alt+7 and Alt+8. On windows curly braces are sat around the brackets, so for curly braces you’d use AltGr+7 and AltGr+0 and brackets would be AltGr+8 and AltGr+9. There’s similar discrepancies for pipe, backslash and others, all of which are confusing to muscle memory when jumping between OSes.
I’m aware I could just use something like a windows alternative for Karabiner elements to manually remap each macro(?), but maybe somewhere out there knows of something that just remaps everything to how it is on a specific other OS.
Does anyone know why the interception (closed source) driver is the only way to differentiate between keyboards.
I understand that Windows normally hides that information. My question is: What does interception do that someone else can't reinvent?
Interception is LGPL[1], the issue is that Windows requires drivers to be signed and code signing certs aren't cheap. That's also why interception has not updated in years to fix the bug where it only supports 10 devices to be connected each boot (each reconnects count as a separate device)[2].
[1]: https://github.com/oblitum/Interception/blob/master/licenses...
[2]: https://github.com/oblitum/Interception/issues/193
> Interception is LGPL
The library is LGPL for non commercial purposes. A contradiction. Drivers and installers are called binary assets. Access to all source code is provided with a commercial license.[1]
[1] https://github.com/oblitum/Interception/blob/master/README.m...
Oh right, I keep forgetting that. The LGPL part is just the library that lets apps talk to the driver.
I still think the main thing Interception has going for it is code signing. I once wrote a keyboard filter driver for personal use, but due to signing requirements I never felt it was worth the trouble & cost trying to use it past the computer I developed it on (and then later moved to firmware based solutions like QMK).
The LGPL license applies to the code that they do provide. It's kinda misleading but you have the option to pay and get the code, or not pay and only get what you see. Seems fair enough.
The contradiction is not the library is LGPL and the driver and installer are proprietary. The contradiction is LGPL does not allow a non commercial restriction.
I really dislike people calling it a bug because the developer put it in there intentionally as a limitation.
Theoretically, can't people make their own self signed certificates (I assume Windows allows that for development)
You can enable test mode[1] which lets you use any certificate, but outside of test mode you need an EV code signing cert[2].
[1]: https://learn.microsoft.com/en-us/windows-hardware/drivers/i...
[2]: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
How to "easily" use a second keybiard as a macro board ? Win Linux mac maybe ?
Easily
Easy to install, easy to use: https://github.com/sezanzeb/input-remapper
I just edit my Kinesis text file
But can it adapt the mappings based on the app you're using? I've switched over to using Keymapper from QMK due to this and convenience.
I can't imagine how this could possibly be used for amusement purposes
It's a pity there isn't a software tool like this that can add random delays between key presses. It would be useful to prevent the kind of fingerprinting Deepseek does.
I researched such a tool yesterday but couldn't find one, so I created one using xte, but it's not really seamless.