How can I arrange my Ergodox in a non-US layout?

[Vorak]

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.

Code: Select all

# 9 0
\ # 2 '
/

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:

Code: Select all

~ ( )
| ~ " @
/

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?

[davkol]

I'm a bit confused.

See the USB HID specification.

The numrow 2 key sends scan code 3 on the lowest level. This is interpreted by the OS, depending on your software layout. Combos with Shift are a matter of software as well. Scan code 3 is interpreted as 2 in US/UK QWERTY or ě in Czech QWERTZ. Combination of scan codes 3 and 42 (usually the Shift modifier) is interpreted as @ in US QWERTY, 2 in Czech QWERTZ and " in UK QWERTY (because the UK layout is partially influenced by the bit-paired keyboard layout).

The Ben's firmware available from Massdrop lets you configure keys to "macros": combinations of what is usually recognized as Shift and numrow/punctuation keys. An example can be seen in my recent ErgoDox layout, its L1. Note that the keys in that editor actually represent key codes, but corresponding US QWERTY assignments are shown. The combination of L1 toggle and the key marked as '" actually sends only the code 40, and L1 toggle with the key marked as " sends 42 press, 40 press, 42 release, 40 release. It's interepreted as ' and " respectively in US QWERTY, but it would be translated to ' and @ respectively in UK QWERTY… or ů and " in CZ QWERTZ. Okay, now I'm kinda repeating myself.

If you don't need non-ASCII stuff, you can always set the software layout to US QWERTY and configure layers with such Shifted keys to your liking (without the actual use of the Shift key). As soon as you start to mess with various different software layouts, things get a bit tricky quickly.

I've read somewhere, that some ErgoDox firmware can send Unicode instead of scan codes (note that this isn't normal keyboard behavior and it may cause problems on some systems), the TMK firmware supports dual role modifiers and it might be possible to implement dead/sticky keys in firmware as well. However, this is all kinda advanced stuff and requires tweaking.

[Kurk]

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.

[Vorak]

Okay. That clears things up a bit.

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

[davkol]

Yeah, none of the extras (except F13-F24) work for me, but it could be some system issue (e.g. they may send too high scan codes that are't recognized), but I haven't checked the source yet and it's only an old version (i.e. stuff might have been already fixed in upstream).

[Vorak]

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.