It’s worth noting that Key_LeftParen is #define’d as LSHIFT(Key_9) (likewise a few other symbols), and is therefore a special case. There is no such thing as Key_Ampersand, for example.
2 Likes
Subliminal message: pull requests to add that - and others - would be accepted.
3 Likes
I’ll get around to it eventually.
Right now, I’m more concerned about the fact that even the combination of ShapeShifter and TopsyTurvy seems like it won’t get me the keymap that I want.
Why is that? What do you want that you think won’t be feasible?
Even in the worst case, there is the option of writing new code to add features you want. So far I’ve added one of my most-wanted features and fixed a thing which was bugging me, and algernon and jesse fixed another few things for me which required deeper understanding of the code. Given the small nature of the code and its nice organized structure, it’s relatively easy to dive into. The parts I’ve looked at have been refreshingly sane.
I want to configure my keyboard so that pressing a key without modifiers will send one keycode (let’s call it alpha), and pressing the same key with shift held down will produce another keycode (beta). In general, alpha and beta might be modified by a (virtual) shift. This would allow me to completely decouple the symbols and numbers that share keys on a standard keyboard for historical reasons, but which have no particular logical association, and recombine them in a way that makes much more sense.
In particular, I want one key that produces ( when typed unmodified, but { when typed with shift held. I also want a | (unmodified) / 9 (shifted) key. This cannot be done even with a combination of TopsyTurvy (good for reversing the shift of a key, but not remapping just the shifted keycode) and ShapeShifter (change the shifted keycode, but shift is always applied to that keycode). And even if it can be made to work, the resulting sketch will be quite convoluted.
If, on the other hand, I implemented it as a layer, I can do that remapping…but then I can’t use a mouse to do a shift-click or shift-drag (or all the keys in that layer must have shift applied, which defeats the purpose).
I have looked at the Kaleidoscope code. I could, with an investment of many (probably frustrating) hours of my time, figure out how to make the plugin that I want, and get it to work, but I have no desire to do so, and no interest in learning all about Arduino coding in order to accomplish that. I just want a keyboard that I can configure in a way that I actually find logical – unlike every other keyboard I have ever seen. If nobody else wants it, it makes a hell of a lot more sense for me to pay @algernon to do it in a tiny fraction of the time it would take me, and that’s what I might do in the end.
Right now the Keyboardio Model 01 with Kaleidoscope comes closest, but it still doesn’t allow a type of remapping that looks like it should be quite simple, but is actually rather tricky, for no other reason than it’s the way mechanical typewriters were set up well over 100 years ago. Frankly, I find it shocking that computer keyboards still work this way, and that nobody seems to have developed a keyboard firmware that allows the decoupling of shifted symbols from their arbitrarily-associated keys.
And now it’s time for me to stop ranting about the ridiculously stupid way modern computer keyboards work…
1 Like
Oh, um, sorry, no harm meant. I’m new here, but I saw that your forum account has been around a while, and that you have an active account on github with stars on some keyboardio projects… and assumed you were already involved with this sort of thing.
About remapping in nontraditional ways, it might be easiest at an OS level instead of a keyboard firmware level. I’m not sure how it works in Windows or OSX, but in Linux and other X11-based systems the xmodmap program works well for this. Instead of using cheap reverse-shift hacks to work around the problems in traditional layouts, it may be easier to eliminate those problems at the source.
That is, assuming that your OS has a way to do it, and that you have that level of control over the computers you use. But, as pointed out already, I shouldn’t assume.
1 Like
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.
- 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
- 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