Remapping keys?

Sorry about my annoyance earlier; your assumption wasn’t unreasonable. I am a programmer, after all (though I’m not sure I’d really describe my account on github as “active”). My only contributions to the firmware thus far have been UX ideas, though; the code itself remains quite opaque to me, since the bits that I’ve tried looking at are largely comment-free and I don’t have a great desire to figure out the structure on my own without documentation.

I was mostly trying to make the point that not everyone who wants a configurable keyboard and uses one a lot is a programmer, and that comments like, “Just write a little code” tend to be very off-putting to those people, and get heard as “Give up; you’ll never get what you want”. I, myself, am so bloody-minded that I’ll get what I want whether it’s a colossal waste of my time or not, but I’d much rather not do it that way.

To the specific point: yes, xmodmap and the like would work fine, but I don’t intend to use this keyboard on just one machine (or even just one operating system), and I want it to work the way I expect regardless of how the host is configured, so the keymap has got to be on the keyboard itself. Furthermore, the existing TopsyTurvy plugin has all of the same “cheap reverse-shift hack” problems that the more general solution I’m proposing has, but considerably less configurability. (Also, how is using xmodmap not just another “cheap reverse-shift hack”?) And by doing it on the keyboard, I am “eliminating those problems at the source” – the keyboard is the source of the input, not the OS.

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’

… maybe try this:
xmodmap -e ‘keycode 18 = parenleft bracketleft’

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.

1 Like

…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.

2 Likes

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.

1 Like

Yes. Yes it will. And maybe it’ll happen in my lifetime, but I’m not holding my breath…

3 posts were split to a new topic: A standard and testing infrastructure for function-level documentation of Kaleidoscope

@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:

┏━━━┓  ┏━━━┓  
┃ { ┃  ┃ } ┃ 
┃ ( ┃  ┃ ) ┃ 
┗━━━┛  ┗━━━┛  
┏━━━┓  ┏━━━┓ 
┃ 9 ┃  ┃ ? ┃ 
┃ | ┃  ┃ " ┃ 
┗━━━┛  ┗━━━┛
4 Likes

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.

  1. The first step is getting the Arduino tools installed.

For MacOS: Install Arduino support on a Mac · keyboardio/Kaleidoscope Wiki · GitHub
For Windows 10: Install Arduino support on Windows · keyboardio/Kaleidoscope Wiki · GitHub
For Linux: Install Arduino support on Linux · keyboardio/Kaleidoscope Wiki · GitHub

  1. Change the keymap. The example turns ‘Prog’ into ‘Esc’, but the idea is the same.
2 Likes

Okay, a bit more work than the Erogodox but I see how it works, I don’t see the Model 01 there though in Examples. I love the feel of this keyboard.

1 Like

Okay, I think I see. I have a bit more to do here.

if we typo or get something wrong, will we brick our kbm01? or will the flash not take and keep the current configuration?

1 Like

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.

As you’re working through it, keep an eye on places where you feel like we could improve the documentation or automate some of the steps for you.

I know we still have a lot of work to do to make this a simple, friendly experience. We are, however, committed to doing that work.

2 Likes

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:

$Space::
SendInput, {Backspace}
return

$Backspace::
SendInput, {Space}
return
1 Like

Of course.I never thought of that. I’ve used that before. I figured out how to do it.I hadn’t loaded the firmware into Arduino. I will just take a bit of figuring out what I want where.

I keep getting a message that the keyboard can’t connect to the programmer and there’s no driver. Did I miss something?

@Gaye, what OS and version are you on? (I’m going to bet Windows 7 or Window 8, as those are the two that are giving me and @rumpel driver headaches this week)

Ha, it’s Windows 7. I’ve made a fair bit of progress and I found some drivers in Arduino, but it’s still not working. This is interesting. Never hurts to learn something new.

1 Like

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 :wink:

[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]

1 Like