deskthority

Hi,
I just spent some time trying to customize my ergodox but I'm having some trouble when my OS (Windows 7) is set to English - United Kingdom. In the Ergodox configurator if I sent a key as 2/@ it obviously produces 2"" instead.

I thought I could plug and play into different machines and not have to worry about the layout setting of the OS. This was a big attraction for me (my machine at work will be locked to that layout).

I wanted a dedicated layer for special characters. So I could e.g. just pinky a toggle key and press a key for tilde without leaving my home row.

Something like this: https://i.imgur.com/VZs6TiW.png.
The bottom row are extended num-pad entries which don't work.

When I actually type on that layout I get the following result though. I noticed in someone else's layout that their toggle key changes to a layer where the same key is a shift key. I thought this might let you press a single key to toggle a different layer and without releasing the toggle key then press another key to get the shifted version of that key...but it doesn't work for me. (Sorry if that's not worded well.) The alternative is toggling and then shifting separately... but that is not more elegant than doing things the old way.

Plus, there's still the confusion of the configurator giving the wrong symbol. For instance when shifting in this layer I get: Instead of an @ I get a ", instead of a " I get @, in one menu that says pipes gives pipes, in another menu the pipes option gives hashes. I'm not faulting the configurator... it's just not designed to be used for this.

If the single-key-toggle/shift solution worked it would also mean that I'd have two layers for special characters; one for those that have to be shift-selected and one for those that don't. That's a fairly illogical way to arrange a keyboard.

If the Ergodox could reproduce extended numpad symbols everything would AOK but it cannot...and I don't know if a firmware change would make this possible. Does anyone?

I noticed a lot of international users here ... so I'm hoping you have some input. How did you work around it?

derp

Ah, davkol beat me to it. Well, here's my take:

You probably realized by now that your operating system's keyboard driver is crucial for generating characters. Here's in a nutshell how it works: The keyboard sends scan codes to your computer, and the keyboard driver looks up which scan code will translate to which character or modifier. And does so
For example, imagine your keyboard sends USB scancode 35(hex) while left shift is pressed (E1). With an US keyboard driver installed you will get ~, with a German driver installed you will get ˚, and with a UK driver you'll get ¬.

Now, the ergodox programming software assumes that the US keyboard driver will be used. For other languages, you'll have to reverse-translate your layout. Be sure to check out Misc->KEY_nonUS_Backslash_Pipe and KEY_nonUS_Pound_Tilde.

Take home message: there is no driver-independent keyboard.*
*Of course it would be possible to design one but that thing would probably not be compatible to any other keyboard. And it would need its own driver.

Okay. That clears things up a bit.

But surely the extended numpad characters '@' etc should just show up.

derp

I asked on the Ergodox-firmware github about adding extended numpad characters. In the keyboards.h it has a table with supposedly supported/unsupported keys: https://github.com/benblazak/ergodox-fi ... keyboard.h.

The actual keyboard.h in the partial-rewrite is (or looks to be? been a while since I touched it) the same as in the master branch. The comments regarding supported platforms are directly from the USB HID Keyboard spec IIRC — and they’re not precisely accurate, but I found that lot of the things that aren’t marked as supported really aren’t (though, I think some of them are), so I didn’t put most of them in the lib/layout/keys.h file at all, so as to avoid people (including myself) designing a layout around them, and then having to make a lot of annoying revisions because half (or probably more of) the keys they were really excited about didn’t work. Wish I could do something about it, but short of writing new keyboard drivers for the major OSs (which, actually, might be a worthwhile project someday) I’m not sure there’s much that could be done.

If you wanted to try the extended keypad codes, to see if they work for you, just add them to keys.h in your branch (or even, preferably, just in your layout file) using the same ‘KEYS_DEFAULT’ macro used in keys.h. I don’t expect most of the “unsupported" keypad keys to work, but if it’s worth a try, I wish you luck .

edit: What he's suggested is actually done by the MD configurator... it doesn't work. It's the OS drivers.