The keyboard sends scancodes, key number 27 down and key number 52 up, not actual glyphs. Then the OS converts those scancodes into logical events. OSes have an archaic concept that 9 and ( are related in the same way that j and J are related, and that archaic assumption interferes with configurations which want ( and [ as the default and shifted events for a given scancode.
The source of the complication is the OS’s scancode translation maps, so why not change the broken map instead of working around it?
Instead of this…
xmodmap -e ‘keycode 18 = 9 parenleft’
Changing it in a keyboard’s firmware can work too, assuming the OS’s map remains predictable, but that’s a bit like putting a painting over a hole in the wall instead of fixing the wall. Sometimes it’s the best option available, or sometimes there might be holes in several walls and it’d be tedious to fix them all. But if given a choice, it’s usually simpler and more robust to fix the wall.
It’s awesome that this keyboard accommodates extensive workarounds, lying to the OS about key press/release events in order to trick it into generating different glyphs than it normally would. It gets complicated and fragile pretty quickly though, in ways which aren’t generally a problem when the solution is implemented at a software level instead of a hardware level.
…and that works fine, as long as you only ever use one computer, with one OS, and no virtual machines. But if you use the same keyboard with multiple machines, different OS’s, and setup up new ones occasionally, it’s a ridiculous burden to have to configure the input software over and over.
What’s really stupid is that the OS still reads scancodes from the keyboard(s), instead of the keyboard simply sending characters to the OS. It only works that way for historical reasons, and has resulted in the godawful mess that we have to deal with today. The real fix isn’t messing around with xmodmap, et al — it’s making a new, simpler standard of communication between the keyboard and the OS that isn’t saddled by the limitations of ancient hardware.
As I understand it, that’s actually part of what @algernon is volunteering on with the QMK and InputClub folks on the hid-io project. I’m hopeful that it turns out useful, but getting something that will work well across multiple platforms and for apps that listen for key events is going to take a ton of work.
@merlin - I’m hoping to do something exactly like what you describe. And like you, I could try and dust of my C knowledge (which I’ve done nothing with for far too many years), learn Arduino programming, and learn about key codes and the like, and maybe get something working in a few months time… or I could ask (and sponsor) a Subject Matter Expert like @algernon to do the work. I’d be happy to join you, and any others that would like to join us, in sponsoring a plugin, say via algernon’s Patreon page, that would allow “legacy-shifted characters” (let’s call them) on a non-shifted key/level, and a different character (legacy-shifted or not) on the shifted layer of that key. Basically, to visualize the ideas you’ve discussed, things like this:
You make that sound easy but what is tweaking and reflashing? I learned how to reprogram my Ergodox, so I’m sure I can manage this once i figure it out but i need a left space key. I just need to know where to start I guess
IMPORTANT: The promise I’ve made to backers is that if the GUI tools aren’t available and you can’t figure out how to remap using the current stuff, I will be your ‘coding concierge’ - You tell me what you want and I’ll make the changes, build the firmware and walk you through getting it onto your keyboard, up to and including screen-sharing if you need it.
It ought not to be something complex you need to figure out. And that’s entirely my fault. @jenigma has been doing heroic work writing docs to make this less opaque.
The first step is getting the Arduino tools installed.
If the firmware does not compile, it won’t flash, and you’ll keep your previous one. If it does compile, but for some odd reason it crashes, you still didn’t brick your keyboard, as you can always re-flash the factory firmware. See this explanation, and the rest of the thread for details.
If you can’t flash your keyboard for whatever reason (for the moment), but absolutely need that space on the left side, you can do it like me and use AutoHotkey (a super useful software for triggering actions when shortcuts are pressed, or “reprogram” the behavior of keys etc.).
I switched the backspace key with space using this script (run autohotkey, right click the tray icon in your windows taskbar (if you use windows, that is), and click “edit this script” and put this in:
The specific issue here is that Windows 7 needs per-device USB driver “.inf” file mappings. In our case, that means mapping USB Vendor ID 0x1209, Product ID 0x2300 and Vendor ID 0x1209, Product ID 0x2301 to the built-in WinUSB driver. I sent @rumpel my first pass at that the other night, but he said it was still no-go for him.
The Arduino Drivers should be correct, except for the VID/PID used as a key to identify the device. I’m going to try again tonight and will post them on the forum if I get anything workable.
Windows 8 has the same issue, but with the added wrinkle that all the drivers need to be digitally signed.
Windows 10…just works fine without installing a special driver, since the Windows team finally decided to automatically load the serial port driver for serial devices.
This stuff is all new for me. I’ve never dealt with Windows device drivers before. Learning something new is hurting a little bit, but it’ll be good for me in the end
[admin: I am going to move this part of the thread talking about windows device drivers over to the thread on that topic in a little while, just to keep everything easy for folks to find]