Author Topic: Truly-Ergonomic’s keycodes remapping  (Read 123921 times)

0 Members and 2 Guests are viewing this topic.

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Truly-Ergonomic’s keycodes remapping
« on: Sun, 06 January 2013, 11:32:28 »
Thanks to the recent opportunity to update the firmware of the Truly-Ergonomic keyboard, we can now begin to make personal remappings.  ;D

In the 209 firmware, I noticed that there is two tables of internal keycodes. These two tables are visible, for example, at the end of the TrulyErgonomic_209_v2.121127.hex file.
Keycodes from address 05AE to address 063D are used when DIP swith #2 is ON (Windows / Linux).
Keycodes from address 063E to address 06CD are used when DIP swith #2 is OFF (Mac OS).

I tried to change some Keycodes (Backspace to home raw (instead of Tab), Enter up (instead of Backspace), CTRL in the middle (instead of Enter), and some others) and it works fine:p Great ! (I only needed a simple formula in OpenOffice.org-Calc to recalculate the checksum-byte of each changed firmware’s HEX file lines…)

11306-0

This can make us to quietly wait for the arrival of the Truly-Ergonomic’s programing software…
« Last Edit: Sun, 13 January 2013, 19:07:06 by addwyn »

Offline Burz

  • Posts: 248
  • maybe get a blister on yo' little finger...
Re: Truly-Ergonomic’s keycodes remapping
« Reply #1 on: Mon, 07 January 2013, 11:08:36 »
Good find!

What is the formula to do the checksum? And how do you tell which codes correspond to which keys-- Is it based on a standard that you can link to?
Matias Mini QuietPro  \\ Dell AT101W - Black ALPS  \\ SIIG MiniTouch x2 White XM - Monterey  \\ Colemak layout.

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #2 on: Mon, 07 January 2013, 12:35:04 »
Here is the OpenOffice.org-Calc file that calculate the line’s checksum

* TrulyErgonomic_209_Keycodes.ods (15.38 kB - downloaded 866 times.)

The codes are standard HID Keycodes (plus some "internal private" keycodes as, for exemple, the DF code which correspond to the [Fn] key that is used internally by the firmware but is never transmitted to the host ):
http://fr.scribd.com/doc/46294537/USB-HID-Translation-Code
Update:
The document with the HID keycodes can be downloaded from microsoft directly (no need for scribd pro account). http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf

The relevant numbers are in the third column, named HID USage ID.

For exemple, if you want the Right-Ctrl to become a Return key, you search for the Right-Ctrl and Return keycode in the HID doc (these codes are E4 and 28). Then your search for the E4 code in the Truly-Ergonomic keycodes (keycodes have white background in my OpenOffice.org file) and you put '28' instead of the original 'E4' code. The new checksum is then calculated for the modified line. When all your changes are done, you copy-paste the complete lines (with the new checksum) in the Truly-Ergonomic HEX file, over the original lines. Then, you can update the Truly-Ergonomic firmware using your personal HEX file…  ;)

Be very carefull to NOT change any other line of the firmware HEX file BUT ONLY the 18 lines of keycodes !!!
And DO NOT change the nine first characters of each keycodes’line !



(Please, be indulgent with my poor English)
« Last Edit: Sat, 16 March 2013, 21:04:21 by addwyn »

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #3 on: Tue, 08 January 2013, 12:01:35 »
You are my Hero.

Thank you for doing something I was too lazy to do! :)

Off to try out the new goodness to permanently remap some keys.

P.T.

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #4 on: Tue, 08 January 2013, 12:56:10 »
Well ****.
I was trying to get the lower left and right international keys to work as control keys.
First attempt failed, but everything else worked.
Second attempt bricked the keyboard.
Shows up as unknown device and the firmware tool does nothing.

Any suggestions before I try to get this thing RMAed with TE?

Update:
Wow. Did a diff on the original firmware. Managed to delete 10 random lines from the file. Yay accidental VIM key mash apparently.
« Last Edit: Tue, 08 January 2013, 13:04:43 by Tracer »

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #5 on: Tue, 08 January 2013, 16:39:01 »
Well ****.
I was trying to get the lower left and right international keys to work as control keys.
First attempt failed, but everything else worked.
Second attempt bricked the keyboard.
Shows up as unknown device and the firmware tool does nothing.

Any suggestions before I try to get this thing RMAed with TE?

Update:
Wow. Did a diff on the original firmware. Managed to delete 10 random lines from the file. Yay accidental VIM key mash apparently.

Were you able to get the firmware to reflash to the bricked TECK?
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #6 on: Tue, 08 January 2013, 17:20:34 »
I was at work so I didn't want to waste any more time.

I'm at home now. I've downloaded the SDK from Megawin.
The controller in this keyboard is a MG84FL54BD.
http://www.megawin.com.tw/megawin_EN/ProductShow.asp?ID=175

Took the keyboard apart to find this out. Sadly, no SPI interface leads and it's a surface mount chip so lifting the serial IO is beyond my skill. Going to see what I can do with the SDK.

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #7 on: Tue, 08 January 2013, 17:22:43 »
I wonder if it's worth taking the effort to try to remap all the keys into a Dvorak layout. I'm not seeing an obvious pattern with a quick glance at the hex file and the USB HID chart.
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #8 on: Tue, 08 January 2013, 17:47:32 »
It's time consuming but not that hard.
My error was just brain fart stupid.

I've confirmed that both SPI and basic serial interfaces are not wired into anything. This most likely means that I need someone with surface mount soldering gear to wire in a 2 wire interface so I can re-program this thing.

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #9 on: Tue, 08 January 2013, 18:45:52 »
Second attempt bricked the keyboard.

:-(


Any suggestions before I try to get this thing RMAed with TE?

I  saw in the Megawin SDK doc that if the chip is Reset (RST-pin high) while the power is NOT interrupted, then it may restart in ISP mode (In System Programming) if the default Megawin ISP program is used in the chip's ISP memory. There is a (little) chance that Truly-Ergonomic used the default ISP program... MAY BE, it could be the way to by-pass the erroneous firmware and to be able to reflash a correct Firmware. I don't know....

« Last Edit: Thu, 10 January 2013, 11:16:45 by addwyn »

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #10 on: Tue, 08 January 2013, 19:12:10 »
:-(

I  saw in the Megawin SDK doc that if the chip is Reset (RST-pin high) while the power is NOT interrupted, then it may restart in ISP mode (In System Programming) if the default Megawin ISP program is used in the chip's ISP memory. There is a (little) chance that Truly-Ergonomic used the default ISP program... MAY BE, it could be the way to by-pass the erroneous firmware and to be able to reflash a correct Firmware. I don't know....

Actually there is a very good chance. Their DFU programming software is the same as the one supplied in the SDK ,except with their logo slapped onto it. I'll try this out now.
Thanks.

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #11 on: Tue, 08 January 2013, 19:26:40 »
:-(

I  saw in the Megawin SDK doc that if the chip is Reset (RST-pin high) while the power is NOT interrupted, then it may restart in ISP mode (In System Programming) if the default Megawin ISP program is used in the chip's ISP memory. There is a (little) chance that Truly-Ergonomic used the default ISP program... MAY BE, it could be the way to by-pass the erroneous firmware and to be able to reflash a correct Firmware. I don't know....

Yup. Shorting pin 1 (3.3v) with 36 reset the device as an SPI device. Stock firmware update tool worked. THANK YOU!

Also. My ability to read technical documentation is apparently poor as this was rather clear in the docs.

I owe you beer.
« Last Edit: Tue, 08 January 2013, 19:29:34 by Tracer »

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #12 on: Tue, 08 January 2013, 19:31:41 »
So now that I've resurrected my keyboard, on to re-programming this thing.
So I'm assuming that the bottom left and right international keys are 87 and 88. The thing is, those codes show up twice in the firmware.

Any ideas?


Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #13 on: Tue, 08 January 2013, 19:41:22 »
For anyone interested, this is what the IC Controller looks like. Also, filthy keyboard.

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #14 on: Tue, 08 January 2013, 20:06:35 »
Wow! You managed to inter-connect pins of such a microscopic thing !!!! Very good job  :cool:

I have no idea why there is two 87 and 88 codes in the Windows/Linux keycodes...
I suppose that the lower right and left buttons correspond to the keycode's positions that already have Ctrl codes (E0 E4) at the same position in the MacOS keycodes (because TE doc say that extrem left and right lower keys are Ctrl keys when DIP switch #2 is Off).

(is my poor English understandable ?)

« Last Edit: Wed, 09 January 2013, 03:48:09 by addwyn »

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #15 on: Wed, 09 January 2013, 07:23:27 »
Wow! You managed to inter-connect pins of such a microscopic thing !!!! Very good job  :cool:

Pine 1 and 36 are at the end of the package so they aren't that hard to short. But yes, :cool: for sure.

I have no idea why there is two 87 and 88 codes in the Windows/Linux keycodes...
I suppose that the lower right and left buttons correspond to the keycode's positions that already have Ctrl codes (E0 E4) at the same position in the MacOS keycodes (because TE doc say that extrem left and right lower keys are Ctrl keys when DIP switch #2 is Off).

Will play around with this later. I ran out of steam last night. Not going to try this again at work either!

(is my poor English understandable ?)

No problem at all.

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #16 on: Wed, 09 January 2013, 08:00:32 »
Shorting pin 1 (3.3v) with 36 reset the device as an SPI device.

This shows too that it would not have been difficult for TE to integrate a Reset push-button that would have done the same short, without requiring the opening of the housing. ;-)

« Last Edit: Thu, 10 January 2013, 11:17:07 by addwyn »

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #17 on: Wed, 09 January 2013, 08:42:42 »
Or provided the most basic leads for a two wire interface which is standard on a lot of electronics with firmware. Almost every router I've ever used has a two wire interface just beneath one of the ethernet jacks so you can salvage a bad flash.

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #18 on: Wed, 09 January 2013, 08:47:34 »
Here is the firmware file I ended up with: * TrulyErgonomic_209_mod.hex (18.25 kB - downloaded 629 times.)
Left Shift -> Tab
Right Shift -> Enter
Left Control -> Left Shift
Right Control -> Right Shift
Left International -> Left Control
Right International -> Right Control

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #19 on: Wed, 09 January 2013, 09:13:47 »
Left Shift -> Tab
Right Shift -> Enter
Left Control -> Left Shift
Right Control -> Right Shift
Left International -> Left Control
Right International -> Right Control

Did you make these changes in the Windows/Linux AND MacOS keycodes groups ?


Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #20 on: Wed, 09 January 2013, 09:17:57 »
Just Windows/Linux. Did not touch Mac.

Offline Gerk

  • Posts: 448
Re: Truly-Ergonomic’s keycodes remapping
« Reply #21 on: Thu, 10 January 2013, 07:59:59 »
So in other words ... TE just took the basic firmware provided and slapped their logo into it.  Why am I not surprised.
Rosewill RK-9000RE (reds) | Das Keyboard Model S Professional Silent (browns) | Leopold TKL (browns) | F21-7D "Mechanical Keyboard" (Blue Alps) | Filco Majestouch TKL (blues) | Goldtouch V2 x 2 | Matias Ergo Pro x 2 | Kinesis Freestyle Pro (browns) | Kinesis Freestyle Edge (reds)

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #22 on: Thu, 10 January 2013, 11:54:19 »
So in other words ... TE just took the basic firmware provided and slapped their logo into it.  Why am I not surprised.

Not at all.
TE took the basic firmware remapping software and just slapped their logo on it.
The firmware itself is mostly custom. The SDK provides a default firmware, but that is for basic IO. The chip inside the board is a generic programmable IC. The HID implementation is all theirs, hence why the problems with the keyboard.

I've been talking to others more knowledgeable about HID implementations on #geekhack and will be taking a crack at my own implementation for firmware now that I know where to go. No promises on where I'll get and how fast I'll get there.

Also, sell me your keyboard already :)

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #23 on: Sat, 02 February 2013, 13:51:47 »
Has anyone tried similar changes in the keycodes of a model 207 Truly Ergonomic keyboard ? Did it work fine too ?

Offline Azteca

  • Posts: 29
Re: Truly-Ergonomic’s keycodes remapping
« Reply #24 on: Sat, 02 February 2013, 19:13:49 »
For anyone interested, this is what the IC Controller looks like.

Yup. Shorting pin 1 (3.3v) with 36 reset the device as an SPI device. Stock firmware update tool worked.


Wonder if you can show in your image which are pin1 and pin36 as all corners look alike :cool:

For how long you have to short these? (less than 1 sec or around 5 secs). I presume the keyboard has to be plugged while shorting?

Last, are terminals without clear paint or need to sand (scratch) to make contact.

Tks  :D

Offline oneproduct

  • Posts: 859
  • Location: Montreal, Canada
  • @Ubisoft
Re: Truly-Ergonomic’s keycodes remapping
« Reply #25 on: Sat, 02 February 2013, 21:07:56 »
I just did this with a 104 model and it worked perfectly. Since I never intend to use it with a Mac, I set the first set of 9 lines to Colemak layout and the second set of 9 lines to QWERTY layout. By flipping DIP switch #2 I can go between the two layouts now. :)
Layout: Colemak
Fastest typing speed: 131 WPM on typeracer, 136 WPM on 10fastfingers.
Daily driver: Filco Tenkeyless MX Brown with ergonomically weighted, lubed springs.
Ergo keyboards: Truly Ergonomic, Kinesis Advantage, Ergodox

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #26 on: Sun, 03 February 2013, 09:25:24 »
Wonder if you can show in your image which are pin1 and pin36 as all corners look alike

Pin 1 and pin 36 are the upper pins of each side of the chip when the round angle mark is at the top left.
12882-0

For how long you have to short these? (less than 1 sec or around 5 secs). I presume the keyboard has to be plugged while shorting?
Much less than a millisecond is sufficient.
Yes. Keyboard Has to be plugged (powered) while shorting.

All of this is only necessary if your keyboard is bricked ! Otherwise, simply toggle OFF the DIP switch #5 to allows firmware to be reprogrammed…

« Last Edit: Sun, 03 February 2013, 11:24:33 by addwyn »

Offline tekkendama

  • Posts: 4
Re: Truly-Ergonomic’s keycodes remapping
« Reply #27 on: Thu, 07 February 2013, 20:10:37 »
hi, guys, amazing work.

if my capslock key acts a delete key can I do something to turn it back into a capslock key?  I think that's what Tracer is doing with the chips but I am not sure.

And what about the AppsKey? Is that the 5D on the last row of Windows/Linux keycodes?

Thanks a lot for any response. All of this is like ancient hyrulian to me but it's starting to make sense. Davkol mentioned Arduino in another thread and I've been looking that up and suddenly chips don't seem that scary anymore.

Offline SubGothius

  • Posts: 79
  • Location: Tucson, AZ USA
    • HTDoctor.com
Re: Truly-Ergonomic’s keycodes remapping
« Reply #28 on: Mon, 11 February 2013, 21:57:00 »
Huzzah! I just remapped my TECK 207 firmware! :cool: Thanks so much for this guide and the checksum spreadsheet, addwyn.

FWIW, I moved the {[ and ]} keys to the opposite (left) end of their row, put '" and \| at the right end where [{ ]} used to be, and moved /? down where '" used to be. This puts /? and \| in their standard QWERTY locations, and '" is now only one key away (one row up) from standard. I also swapped Tab and Backspace, so now Backspace is adjacent to Delete (where I kept expecting it to be), and I expect this will help reduce inadvertent Tab strikes as well. I've attached my modified .hex file here in case anyone with a model 207 wants to try this remap.

* TrulyErgonomic_207-remap_v2.121127.hex (18.25 kB - downloaded 679 times.)
"In theory there's no difference between theory and practice, but in practice there is." -Jan L.A. van de Snepscheut

Offline ☠☠☠

  • Posts: 5
    • Neo Layout - German Ergonomic Keyboard Layout
Re: Truly-Ergonomic’s keycodes remapping
« Reply #29 on: Wed, 13 February 2013, 17:23:43 »
Thank you very much.

By the way: The document with the HID keycodes can be downloaded from microsoft directly (no need for scribd pro account). http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf

The relevant numbers are in the third column, named HID Usage ID.


Or if you want to have it even easier, just execute this command in a linux terminal:

Code: [Select]
su -c "while true; do od --read-bytes=144 --width=144 -x /dev/input/event3 | awk 'NF > 1 { print \$12 }'; done"

This will print the USB HID ID number of every key pressed. See http://superuser.com/questions/550858/how-to-get-usb-hid-id-of-keyboard-keys/552026 for a detailed explanation.
« Last Edit: Sun, 17 February 2013, 12:59:29 by ☠☠☠ »

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #30 on: Thu, 14 February 2013, 09:29:50 »
So... I finally decided to try flashing the new firmware update to my 109 and experimenting with hacking the hex files. I'm extremely happy with the results. It didn't take long to figure out which keys went where, and I was pleased to note that things like the left spacebar were easily remappable. Thanks, guys!  :cool:

Hardware remapping massively increases the value of the TECK in my eyes, as I can finally take my keyboard around and just plug it in to any workstation with no fuss. (After using it for a year with a non-standard key configuration, the default mappings are unacceptable.) As an added bonus, reassigning keys in hardware solved a problem I was having with certain games ignoring scancode maps in the Windows registry.


I'm curious to know where the NumLock layer lives. There's a section of the main keymap that looks like it should deal with that, but editing it doesn't seem to do anything.


One interesting (and rather annoying) feature that I discovered is that the behaviour of the Fn layer is partially based on the key assignments rather than the physical keys, at least with respect to the keys to the left and right of Fn. On my 109, those are Windows and PrintScreen, for instance. Changing the mapping of either key prevents them from being used to access their function layer (CapsLock and NumLock respectively). However, installing a new Windows or PrintScreen key elsewhere will mean that Fn-(new key) accesses CapsLock or NumLock. That doesn't seem to be the case for the function row Fn layer, though. Comparing the 109 and 209 versions offers hints as to which portions of the firmware might control some of this behaviour, but they're pretty deep in the executable segments. I wouldn't want to risk fiddling with that without taking a lot more time to figure out the disassembled code...

Offline ☠☠☠

  • Posts: 5
    • Neo Layout - German Ergonomic Keyboard Layout
Re: Truly-Ergonomic’s keycodes remapping
« Reply #31 on: Thu, 14 February 2013, 16:09:13 »
I have done it! Finally my Truly Keyboard works like it should. And finally the keys are always the same (the modifiers), no matter which user is using the computer. That makes it a lot of easier. I did quite a lot of changes. Some cyclic changes, modifiers to my preferred positions and some specifics for the keyboard layout I am using (Neo 2).

Is somebody already writting a web gui which creates a hex file to download? Not that I need it, but it would be easier for others. Nobody wants to wait for the company any more.
« Last Edit: Thu, 14 February 2013, 16:25:29 by ☠☠☠ »

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #32 on: Thu, 14 February 2013, 19:32:22 »
I'm curious to know where the NumLock layer lives.

I located the position of numpad management (Keycodes conversion when Num-Lock is ON) in the TrulyErgonomic_209_v2.121127.hex file.
This is not a table but a piece of code ! For each key involved in the numpad, there is a keycode allowing to identify the initial key and, a little further, the keycode that is to be returned for this key when Num-Lock is ON…
This piece of code is located between address 084B and 08EC (I saw that’s the same in the TrulyErgonomic_207_v2.121127.hex file. I have not looked into the other firmware files) :

13451-0

For exemple, if you changed the layout of your TE keyboard to COLEMAK, the Keypad-1 should be on the [N] key (instead of the [J] key). Therefore you sould override the [J]’s keycode (red framed "0D") by the [N]’s keycode ("11"). As a result, your TE keyboard will send a [Keypad 1] to the host when the [N] key is typed while Num-Lock is ON (and not when the [J] key is typed)

Be very careful ! As this is a piece of code, DO NOT modify ANY OTHER VALUE except the keycodes (I framed by red or green in this picture) and the lines' checksum bytes (the two digits at the end of each line) !
« Last Edit: Sat, 16 February 2013, 09:44:51 by addwyn »

Offline ☠☠☠

  • Posts: 5
    • Neo Layout - German Ergonomic Keyboard Layout
Re: Truly-Ergonomic’s keycodes remapping
« Reply #33 on: Fri, 15 February 2013, 01:54:37 »
I'm curious to know where the NumLock layer lives.
Be very careful ! As this is a piece of code, DO NOT modify ANY OTHER VALUE except the keycodes (I framed by red or green in this picture) and the lines' checksum bytes (the two digits at the end of each line) !

Thank you addwyn. That makes the keyboard even better, because I can remap the numpad like it is in the Neo2 layout.

Am I right if I assume that I have to calculate the checksum in the same way as for the keyremapping in your spreadsheet?

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #34 on: Fri, 15 February 2013, 08:20:39 »
Am I right if I assume that I have to calculate the checksum in the same way as for the keyremapping in your spreadsheet?
Yes ! You are absolutely right assuming that.


Here is my OpenOffice.org Calc file updated to suit the Num-Lock layer :
* TrulyErgonomic_209_Keypad.ods (18.31 kB - downloaded 550 times.)


I hope this will help to achieve nice designed TE keyboard's personal hardware remapings...
« Last Edit: Fri, 15 February 2013, 09:12:47 by addwyn »

Offline ☠☠☠

  • Posts: 5
    • Neo Layout - German Ergonomic Keyboard Layout
Re: Truly-Ergonomic’s keycodes remapping
« Reply #35 on: Fri, 15 February 2013, 15:46:30 »
Thank you for that again. Merci beaucoup!
May I ask you
  • how you identified the positions of the keycodes in the hex file?
  • And where did you find the algorithm for the checksum? Is this a standard documented for the Megawin chips?

I am asking this, because I want to also edit the keycodes of the Fn keys.

And I want to, as I have had it before with a Xmodmap file, add XF86Forward and XF86Backward to the to lower right keys of the keyboard, as all the Thinkpad keyboards have it. But as USB HID ID number this is (WWW Forward) \x0225 and (WWW Back) \x0224 which is to big to fit in the 16 bit space for one key.

Ok, now I’ll adjust my Fn-keypad layout with your spreadsheet.

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #36 on: Fri, 15 February 2013, 20:13:45 »
Hmm... been rummaging through the firmware a bit more...

Besides the main keymap tables that we know about, I've been able to find three other data tables.

One is right at the beginning of the hex file and lives in x10CC-x1159 (109) or x10DC-x1169 (209). It's identical in both versions, and mostly seems to contain data used by functions responsible for the USB I/O.

The second one lives at x1627-x165F (109) or x1637-x166F (209) and is used by the external interrupt handler to manage port I/O. Don't touch it.

The last one lives at x0CC5-x0D9E (109 version) or x0CD5-x0DAE (209 version), and is slightly different between models. Among other things, it contains the HID codes for the Fn-(F key) layer.

Here's the relevant section from the 209 firmware:


:100CD50005010906A101050719E029E71500250108
:100CE50075019508810295017508810195057501C4
:100CF50005081901290591029501750391019506CC
:100D05007508150025DF0507190029DF8100090091
:100D150095407508B100C0050C0901A101850115B3
:100D2500012510750895010AAE010A23020A8A01F8
:100D35000A21020A94010A92010A830109B609CD22
:100D450009B509E209EA09E909B809B70A9601816D
:100D550060C005010980A101850215012503750201
:100D65009501098209810983816075068103C0099E
:100D7500023B00020100A014090400000103010167
:100D85000009211101000122470007058103080020
:100D95000A090401000103000000092111010001F5
:0A0DA5002258000705820308002011


0223 (Fn-F1) is Home Page
018A (Fn-F2) is Mail
0221 (Fn-F3) is Search
0194 (Fn-F4) is My Computer
0192 (Fn-F5) is Calculator.
0183 (Fn-F6) is Media Select
B6 (Fn-F7) is Media Previous
CD (Fn-F8) is Media Play/Pause
E2 (Fn-F9) is Media Next
EA (Fn-F10) is Volume Down
A9 (Fn-F11) is Volume Up
B8 (Fn-F12) is Media Eject

Note that these are all HID Usage Page 0C codes, not the Page 07 codes that the normal keyboard keys use. I'd only recommend substitutions with other media HID keycodes of similar size.

0195 (network browser) and 01AE (keyboard layout) are formatted to look like they might do something, but any keys that might be associated with these are hard coded to do something else in the main function in the main function. Interestingly, the Calculator entry is also included with the 109 firmware even though Fn-F5 is hard coded to act as Insert.

Fn-Escape and the keys to the left, right, and below the Fn key are hard coded in a big, sprawling function (which starts at x007e in all versions of the firmware), as are the Fn-5 and Fn-6 combinations and a bunch of DIP switch related stuff. You guys already found the function that handles the NumLock layer (which starts at x07AF in my 109 firmware and 0x07EB in the 209 one).

I've thus far been unable to figure out which functions are responsible for that F key function layer. There are several that access those data  blocks, but with my rather limited experience in programming such devices, their behaviour is not as obvious as the other keymapping routines in the firmware.

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #37 on: Sun, 17 February 2013, 13:08:57 »
Thank you for that again. Merci beaucoup!
May I ask you
  • how you identified the positions of the keycodes in the hex file?
  • And where did you find the algorithm for the checksum? Is this a standard documented for the Megawin chips?

I am asking this, because I want to also edit the keycodes of the Fn keys.

The hex files are a standard format. The Megawin CPU in the TECK is basically just an 8051 processor with some extra stuff like USB support built in. Most 8051 IDEs will have tools to disassemble and analyze the hex files.

Then it's just a matter of figuring out where the data lives, since disassemblers have no practical way of telling the difference between code and data. Sometimes it's obvious. For instance, the data block right at the top of the hex files is mostly plaintext device information. (You can read "Truly Ergonomic Computer Keyboard" and other USB device info there.) Comparing the firmwares of two models with known differences is a good starting point for where to look.


Anyways... after a few days of trying to make sense of the firmware, I decided to be a little more adventurous. For my first baby steps into hacking the code, I set up my keyboard to toggle between the Windows and Mac code pages based on Scroll Lock instead of the DIP switch. My TECK now has two full layers complete with a convenient LED to tell me which one I'm using. It's just a few bytes changed, but my keyboard is now so much more awesome than before!  :cool:

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #38 on: Sun, 17 February 2013, 13:47:21 »

[/quote]

Anyways... after a few days of trying to make sense of the firmware, I decided to be a little more adventurous. For my first baby steps into hacking the code, I set up my keyboard to toggle between the Windows and Mac code pages based on Scroll Lock instead of the DIP switch. My TECK now has two full layers complete with a convenient LED to tell me which one I'm using. It's just a few bytes changed, but my keyboard is now so much more awesome than before!  :cool:

[/quote]

 :cool: Could you tell us how you did it?

I am asking because I’m looking for a possibility to add at least one (better two) switchable additional Layers to the keyboard, so I’d be independent of any drivers. I am running a german Neo-derivate Layout,  I need three layers at least. So what you did there sounds really interesting.

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #39 on: Sun, 17 February 2013, 15:39:43 »

Hmm... I guess this is simple enough to do with a hex file hack...

My hex files no longer resemble the originals since everything's in a different order now. But if you really really want to play with it...

There are two places where the firmware decides which layout to use.

In the 109 firmware, this occurs at locations x07DF and x0901.
In the 209 firmware, it occurs at locations x081B and x0C2D.

The instruction in question reads 30 E9 07, which is an 8051 opcode for "Jump 7 bytes if the Port 4.1 (DIP Switch #2) bit is clear". The string only occurs at the two points in question, so you can simply search for it rather than hunting for the address.

Because the Caps/Num/Scroll locks are implemented with a pin controlling their LEDs, it's actually a fairly simple matter of changing the bit you're checking.

As far as I can tell, the DIP switch pins on the TECK live at:

EA = Port 4.2 = DIP Switch #1
E9 = Port 4.1 = DIP Switch #2
B2 = Port 3.2 = DIP Switch #3
B1 = Port 3.1 = DIP Switch #4

The LED pins on the TECK live at:

B5 = Port 3.5 = Num Lock
B6 = Port 3.6 = Caps Lock
B7 = Port 3.7 = Scroll Lock

I recommend using Scroll Lock, as that won't mess up anything else. (Seriously... who uses Scroll Lock for anything these days?) As noted earlier in this thread, the NumLock keypad is hard coded into the key processing function, and disabling that would require significantly more surgery on the code.

Note that the bits in question are high when the lock in question is toggled off and low when it's on. (It's the reverse case for the DIP switches; a bit set to 1 means "on" as expected.) Also note that the "off" position of the DIP switch defaults to the Mac keyboard layout. If you want the Windows layout to be the default, change the jump instruction from 30 (JNB) to 20 (JB).

So my version reads 20 B7 07 (Jump 7 bytes if Scroll Lock is off).

Obviously, you'd have to redo checksums and stuff as usual.


I would also recommend adding Scroll Lock (47 hex) to a conveniently accessible button on both layouts, as by default it's only available via Fn-(top middle key).


Adding a third layer for NumLock is a non-trivial change that requires completely rewriting several of the key processing functions. It actually doesn't look like it would be super difficult to do, but at that point it's way beyond simple hex file hacking. Unfortunately, implementing temporary modifier access to a layer (e.g. with the Fn key or perhaps some other private internal keycode for a layer modifier) would probably be a lot of work, as it requires changing major aspects of how the keyboard operates.


WARNING: Modifying the executable portions of your firmware is a potentially brickable offence! Hack the code at your own risk!


Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #40 on: Sun, 17 February 2013, 17:21:25 »
Hmm... I guess this is simple enough to do with a hex file hack...

I recommend using Scroll Lock, as that won't mess up anything else. (Seriously... who uses Scroll Lock for anything these days?) As noted earlier in this thread, the NumLock keypad is hard coded into the key processing function, and disabling that would require significantly more surgery on the code.

Note that the bits in question are high when the lock in question is toggled off and low when it's on. (It's the reverse case for the DIP switches; a bit set to 1 means "on" as expected.) Also note that the "off" position of the DIP switch defaults to the Mac keyboard layout. If you want the Windows layout to be the default, change the jump instruction from 30 (JNB) to 20 (JB).

So my version reads 20 B7 07 (Jump 7 bytes if Scroll Lock is off).

Does this mean I have to change both occurences of this piece of code or do I have to decide which one to change? or must I keep it in one layer in the original form (30 B9 07) and the other to jump back as (20 B7 07)? I guess the latter is the case. I think I got it.

I would also recommend adding Scroll Lock (47 hex) to a conveniently accessible button on both layouts, as by default it's only available via Fn-(top middle key).

I had just that in mind anyways, as in my actual Layout (with a driver) reserves an accessible key for that purpose.

Adding a third layer for NumLock is a non-trivial change that requires completely rewriting several of the key processing functions. It actually doesn't look like it would be super difficult to do, but at that point it's way beyond simple hex file hacking. Unfortunately, implementing temporary modifier access to a layer (e.g. with the Fn key or perhaps some other private internal keycode for a layer modifier) would probably be a lot of work, as it requires changing major aspects of how the keyboard operates.


That’s a clever proposal, thanks for hinting it out! I already figured that hacking the NumLock Layer wouldn’t be a too good idea.
What I want to do is having an extra layer for all special characters ?![]... as I am used to have it now. Since German has als this extra Umlaut characters this fills comfortably one layer of the TECK, so I need an easy accessible extra layer. Speeds up typing.
Your detailed answer encourages to really try it. Thanks a stack. :)

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #41 on: Sun, 17 February 2013, 18:40:09 »
Hmm... I guess this is simple enough to do with a hex file hack...

I recommend using Scroll Lock, as that won't mess up anything else. (Seriously... who uses Scroll Lock for anything these days?) As noted earlier in this thread, the NumLock keypad is hard coded into the key processing function, and disabling that would require significantly more surgery on the code.

Note that the bits in question are high when the lock in question is toggled off and low when it's on. (It's the reverse case for the DIP switches; a bit set to 1 means "on" as expected.) Also note that the "off" position of the DIP switch defaults to the Mac keyboard layout. If you want the Windows layout to be the default, change the jump instruction from 30 (JNB) to 20 (JB).

So my version reads 20 B7 07 (Jump 7 bytes if Scroll Lock is off).

Does this mean I have to change both occurences of this piece of code or do I have to decide which one to change? or must I keep it in one layer in the original form (30 B9 07) and the other to jump back as (20 B7 07)? I guess the latter is the case. I think I got it.



Oh no...

In case I wasn't clear, you have to change both occurances to the same thing. (One is in a preprocessor function that sets up special internal keycodes for the Fn-F key layer, the other is the main keymap processor that adds keypresses to the output buffer.) Behaviour might be unpredictable if you only change one.


Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #42 on: Mon, 18 February 2013, 04:04:47 »


Oh no...

In case I wasn't clear, you have to change both occurances to the same thing. (One is in a preprocessor function that sets up special internal keycodes for the Fn-F key layer, the other is the main keymap processor that adds keypresses to the output buffer.) Behaviour might be unpredictable if you only change one.

Thanks a lot, I will take it from there!

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #43 on: Tue, 19 February 2013, 13:00:17 »
Now if someone can help me fix why this keyboard doesn't always show on boot. I thought it was a Windows 8 issue but it looks like it's not. Every 3rd or 4th boot my BIOS warns "No Keyboard detected"

Offline Azteca

  • Posts: 29
Re: Truly-Ergonomic’s keycodes remapping
« Reply #44 on: Wed, 20 February 2013, 04:27:28 »
Any chance someone can do a DVORAK layout for both the TECK 209 and 207? (DVORAK in firmware ;D )

Or to take SubGothius with Tab and Backspace in original positions, so when the computer is set to DVORAK, the keys are where we expect them to be:
FWIW, I moved the {[ and ]} keys to the opposite (left) end of their row, put '" and \| at the right end where [{ ]} used to be, and moved /? down where '" used to be. This puts /? and \| in their standard QWERTY locations, and '" is now only one key away (one row up) from standard. I also swapped Tab and Backspace, so now Backspace is adjacent to Delete (where I kept expecting it to be), and I expect this will help reduce inadvertent Tab strikes as well. I've attached my modified .hex file here in case anyone with a model 207 wants to try this remap.
(Attachment Link)

Cheers.

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #45 on: Wed, 20 February 2013, 05:31:28 »
Now if someone can help me fix why this keyboard doesn't always show on boot. I thought it was a Windows 8 issue but it looks like it's not. Every 3rd or 4th boot my BIOS warns "No Keyboard detected"

Have you checked out what TE got to say about that issue under:
http://www.trulyergonomic.com/store/index.php?route=product/category&path=79_90#Wake_Up
last point: Additionally about Bios fast boot option?  maybe it applies to your machine?

Offline Erdedy

  • Posts: 1
Re: Truly-Ergonomic’s keycodes remapping
« Reply #46 on: Wed, 20 February 2013, 12:57:56 »
Does anyone know what the HID code for the key [¨´] is?   It's the one on near the top left just below Esc.

Offline Azteca

  • Posts: 29
Re: Truly-Ergonomic’s keycodes remapping
« Reply #47 on: Wed, 20 February 2013, 13:16:43 »
Does anyone know what the HID code for the key [¨´] is?   It's the one on near the top left just below Esc.

Go to Support » Installation & Quick Start Guide » DIP Switches
http://www.trulyergonomic.com/store/index.php?route=product/category&path=79_80#DIP

DIP switch #4   Behavior of the [´ ¨] key located Top-Left:
    For Model 207 (not intended for JIS layout):
      ON   Europe-2 (07.64:0x56). Extra 105th key found on standard keyboards with 105 keys (ISO).
      OFF    Additional ↹ Tab key for US layout. The standard US layout (ANSI) only requires 104 keys, it doesn't use this 105th key; this option provides a secondary ↹ Tab key.
    For Model 209 (intended for JIS layout):
      ON    Europe-2 (07.64:0x56). Extra 105th key found on standard keyboards with 105 keys (ISO).
      OFF   International-3 (07.89:0x7D) for JIS layout.

:cool:

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #48 on: Wed, 20 February 2013, 15:57:47 »
Does anyone know what the HID code for the key [¨´] is?   It's the one on near the top left just below Esc.
This key is the keycode 64 ("Europe-2") in the TE's Windows/Linux and MacOS keycodes groups (in the first line of each keycodes groups).
« Last Edit: Wed, 20 February 2013, 16:03:21 by addwyn »

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #49 on: Wed, 20 February 2013, 19:16:40 »
So... I've become a bit more daring with regards to hacking my keyboard. Ultimately, I'd like to rewrite large chunks of the keymap handling system to be able to support multiple layers with modifiers.

I had a few successes with early experiments. Some of them soft bricked the keyboard to the point that none of the keys worked, but the USB handling remained intact, so reflashing the firmware fixed everything.

Eventually, I got a little bit too ambitious and decided to try moving the original data tables so I wouldn't have to worry about constantly editing their addresses. I guess I missed some references, because that instabricked the keyboard.

I was expecting to be able to just unscrew everything, open it up, short the CPU to reset in ISP mode, and be back on my way. Yeah... not so easy, it turns out.

Both sides of the case seem to be bolted together in the middle (which is unfortunately close to where the CPU is). I couldn't figure out how to release them. In the end, I had to more or less break the top off to get at the chip and reset it.

For those of you who've managed to get the case open... is there some trick to doing it? I'd rather not damage the poor keyboard any more than necessary...

Offline Azteca

  • Posts: 29
Re: Truly-Ergonomic’s keycodes remapping
« Reply #50 on: Thu, 21 February 2013, 02:45:14 »
For those of you who've managed to get the case open... is there some trick to doing it? I'd rather not damage the poor keyboard any more than necessary...

I got the following from TE after I needed to open mine:

------------------------------------------------------------------

How to open the Truly Ergonomic Keyboard

Please be aware that if you open the keyboard, you will dismiss all guarantees.

1.   First remove the 9 screws that hold the palmrest, and then remove the palmrest.

2.   Then remove the top 2 screws and the 4 additional screws that were hidden by the palmrest.

3.   There are 2 additional screws under the back label – located on each of the top corners. Press the label on each corner with your thumbs or fingers to feel where the screw cavity is located, and then use a screwdriver or cutter to split through the label. http://www.trulyergonomic.com/store/image/data/Truly_Ergonomic-underside_all_screws.jpg

4.   After all screws are out, you need to 'horizontally-twist' the top-body against the bottom-body as there are 6 'hooks' that hold these two parts together; 4 hooks on the backside where the cable is located, and 1 hook on each side.

------------------------------------------------------------------

 :)

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #51 on: Thu, 21 February 2013, 05:50:54 »
Ultimately, I'd like to rewrite large chunks of the keymap handling system to be able to support multiple layers with modifiers.
Hi Tezkat,
I’m highly interested in your findings & and I hold all my thumbs for your final success!

Thanks to your experiments I have a working version with two layers now, one with qwert as base to work with my usual driver within my usual setup and another one by ScrollLock Switch and LED on with my personal basic Layout directly mapped to work on other computers without drivers. That’s what I call a big step forward !!! :cool:

But still not satisfying. some programmable layers with modifiers would be really cool, but it would also include to map keys according to their Shift or AltGr states, that would be perfect.

A long way to go still I guess, good luck, and don’t kill your Teck prematurely! ;)


Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #52 on: Thu, 21 February 2013, 11:06:44 »
Have you checked out what TE got to say about that issue under:
http://www.trulyergonomic.com/store/index.php?route=product/category&path=79_90#Wake_Up
last point: Additionally about Bios fast boot option?  maybe it applies to your machine?

Hah, so it is a race condition. The keyboard hasn't booted fast enough for the BIOS to pick it up. Turning off fast boot is a NON option as this increases the boot time by a LOT.

Offline Tracer

  • Posts: 113
  • Location: Toronto, Canada
Re: Truly-Ergonomic’s keycodes remapping
« Reply #53 on: Thu, 21 February 2013, 11:08:41 »
Both sides of the case seem to be bolted together in the middle (which is unfortunately close to where the CPU is). I couldn't figure out how to release them. In the end, I had to more or less break the top off to get at the chip and reset it.

For those of you who've managed to get the case open... is there some trick to doing it? I'd rather not damage the poor keyboard any more than necessary...

Two of the screws holding the keyboard together are underneath the sticker. Feel with your finger until you find them.

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #54 on: Thu, 21 February 2013, 11:22:09 »
Ah... thanks so much. I figured it would be something like that, but the back sticker didn't look like it was removable. I guess it isn't actually supposed to be.

Anyways... I've ordered a second TECK so that I'll be free to use my old, now slightly beat up and very no longer under warranty keyboard as a development guinea pig. I did say earlier that the lack of programmability was the only thing really holding me back from buying more. I guess they delivered on that after all... just not the way they intended.  ;)

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #55 on: Fri, 22 February 2013, 03:17:05 »
But still not satisfying. some programmable layers with modifiers would be really cool, but it would also include to map keys according to their Shift or AltGr states, that would be perfect.
I'm afraid this is not the responsibility of the keyboard.

Indeed, in the HID protocol, the keyboard transmits only the status of the modifiers'keys and the codes of the pressed keys. With HID, the keyboard does not transmit ASCII characters. The combination of a key with an ASCII character is purely the responsibility of the OS (this is why, during its installation, the OS ask for the country / layout of the keyboard).
By looking at the list of the HID keycodes, it is clear that, for example, there is no different codes for '?' or '/' but only one code for both combined (code 0x38 for the [/?] key). So, the keyboard's fimware can not separate them !

One solution would be to make the firmware to interpret itself the status of the modifiers and then to simulate a Alt sequence like, for example: [Alt] pressed + [Numpad 6] pressed + [Numpad 6] released + [Numpad 3] pressed + [Numpad 3] released + [Alt] released,  to make the OS interpret a '?' ASCII character... But this is another matter !
« Last Edit: Fri, 22 February 2013, 03:48:54 by addwyn »

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #56 on: Fri, 22 February 2013, 04:10:56 »
But still not satisfying. some programmable layers with modifiers would be really cool, but it would also include to map keys according to their Shift or AltGr states, that would be perfect.
I'm afraid this is not the responsibility of the keyboard.

Indeed, in the HID protocol, the keyboard transmits only the status of the modifiers'keys and the codes of the pressed keys. With HID, the keyboard does not transmit ASCII characters. The combination of a key with an ASCII character is purely the responsibility of the OS (this is why, during its installation, the OS ask for the country / layout of the keyboard).
By looking at the list of the HID keycodes, it is clear that, for example, there is no different codes for '?' or '/' but only one code for both combined (code 0x38 for the [/?] key). So, the keyboard's fimware can not separate them !

One solution would be to make the firmware to interpret itself the status of the modifiers and then to simulate a Alt sequence like, for example: [Alt] pressed + [Numpad 6] pressed + [Numpad 6] released + [Numpad 3] pressed + [Numpad 3] released + [Alt] released,  to make the OS interpret a '?' ASCII character... But this is another matter !

Exactly, you say it. But that would be what I'd call true programmability.
In fact it is what the Ergodox-group and others have achieved for the Teensy++ controller. My dream is, to arrive at that kind of programmability for that Megawin Controller too, for I really like that keyboard and dont want to build one myself.  I don't know too much about neither programming USB-Devices nor hacking machine code, so maybe that idea is absurd and out of reach. I am just trying to dream it up. What would it take, besides a profound understanding of how the controller is programmed?

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #57 on: Fri, 22 February 2013, 08:34:38 »
I'd have to look at sample source code of how other keyboard designers achieved it (wasn't included in the ergodox firmware last time I looked), but I'd expect that sending an Alt-Numpad sequence--or any sequential macro in general--would be a relatively complex bit of programming requiring a rewrite of not just the keymapping but the timer controls and keyboard I/O. That's well beyond the scope of what I had planned to do.

On the other hand, it shouldn't be particularly difficult to add modifier info to a layer map (e.g. press Fn-F1 and it sends Ctrl-C). Note, however, that that could potentially cause unexpected behaviour when two keys with different modifiers are pressed quickly enough to register as simultaneous (or when actual modifier keys have also been pressed). Although the USB HID spec lists codes for the basic modifier keys (left and right Shift, Ctrl, Alt, and "GUI"--which refers to the Windows/Option/Meta keys), these are only used internally by the keyboard and not sent to the PC. That info is instead sent as an 8-bit array that reports which modifiers are currently in use.

For the record, there is actually an example of this type of remap in the default TECK firmware: Fn-6 remaps to Ctrl-Break, overriding whatever other modifiers you have pressed at the time.


Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #58 on: Fri, 22 February 2013, 11:46:44 »

I'd have to look at sample source code of how other keyboard designers achieved it (wasn't included in the ergodox firmware last time I looked), but I'd expect that sending an Alt-Numpad sequence--or any sequential macro in general--would be a relatively complex bit of programming requiring a rewrite of not just the keymapping but the timer controls and keyboard I/O. That's well beyond the scope of what I had planned to do.

considering the difficulties you describe only too understandable :(
If you want to look at code of projects of a somehow of similar nature:
https://github.com/tmk/tmk_keyboard/blob/master/README.md
https://github.com/frobiac/adnw/blob/master/README.md
http://deskthority.net/workshop-f7/xt-at-ps2-terminal-to-usb-converter-with-nkro-t2510.html?sid=c8c61536fa9401ca6d13bf04c989e327

As far as I understand, it is probably not precisely the same thing as it is more about PS2 signals to USB via different controllers but maybe it helps some. All at least implement layer structures to organize keycodes.

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #59 on: Tue, 26 February 2013, 03:02:55 »
For the record, there is actually an example of this type of remap in the default TECK firmware: Fn-6 remaps to Ctrl-Break, overriding whatever other modifiers you have pressed at the time.
Yes, TE refers to it since recently on their homepage:
»Pause/Break
Pressing Fn 5% is equivalent as Windows key Pause which in turn opens "Windows System Properties".
Pressing Fn 6^ is equivalent as Ctrl Break.«

Also they deleted any hints of their intention to release any kind of reprogramming software, I think this project of TE is definitely dead now.

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #60 on: Tue, 26 February 2013, 03:15:07 »
On the other hand, it shouldn't be particularly difficult to add modifier info to a layer map (e.g. press Fn-F1 and it sends Ctrl-C).
[...]
For the record, there is actually an example of this type of remap in the default TECK firmware: Fn-6 remaps to Ctrl-Break, overriding whatever other modifiers you have pressed at the time.
I agree. I don't know if we can really talk about remapping in this case but perhaps, instead, about adding some layers (eg: Alt-Space send Tab) or about customising functions (eg: FN-LeftArrow send BrowserBack)... Indeed, this kind of "programmability" could be done without too much difficulty (but still a bit of work!).

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #61 on: Wed, 27 February 2013, 08:35:14 »
I agree. I don't know if we can really talk about remapping in this case but perhaps, instead, about adding some layers (eg: Alt-Space send Tab) or about customising functions (eg: FN-LeftArrow send BrowserBack)... Indeed, this kind of "programmability" could be done without too much difficulty (but still a bit of work!).
Well, I am quite happy with what you and Tezkat have achieved till now, it's a major improvement for the usability of the TECK, so many thanks to both of you!
Still I want to see the TECK becoming one day fully programmable as mentioned before, so I'll gladly go for anything you or anybody else hopefully will dig up about customizing it in the future. :D

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #62 on: Wed, 27 February 2013, 11:40:09 »
I agree. I don't know if we can really talk about remapping in this case but perhaps, instead, about adding some layers (eg: Alt-Space send Tab) or about customising functions (eg: FN-LeftArrow send BrowserBack)... Indeed, this kind of "programmability" could be done without too much difficulty (but still a bit of work!).

Hmm... I personally don't believe that altering the behaviour of things like Alt-Space should ever be the responsibility of the keyboard firmware. It's doable, sure, but somewhat complicated and much better suited for OS-side customization.

Anyways, my new TECK has arrived, so the old one is in full lab rat mode. It's kinda slow going working with uncommented, unlabled assembly code when your only debugging platform is a keyboard you need to rip open to reset, but I'm gradually gutting and rewriting all of the original keymapping routines. So far, I've implemented rudimentary support for temporary modifier key access to layers (of the Fn-Something sends SomethingElse type). Next, I plan to build a four layer design with with built-in support for Ctrl/Shift/Alt/GUI pre-modified keys.

I still haven't quite figured out how the media page special function keys are implemented on the TECK. The important stuff is mostly handled by the USB interrupts rather than the keymappers, and I don't really know what else the associated data table is for, so support for things like custom browser control keys is still a long ways off.



Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #63 on: Wed, 27 February 2013, 12:51:42 »
but I'm gradually gutting and rewriting all of the original keymapping routines. So far, I've implemented rudimentary support for temporary modifier key access to layers (of the Fn-Something sends SomethingElse type). Next, I plan to build a four layer design with with built-in support for Ctrl/Shift/Alt/GUI pre-modified keys.

Wow, this sounds great! I'm looking forward to see that when you're done. :p

Only thing I figured out so far with my own clumsy experiments is, that the NumLock Key[53] cannot be mapped into that big keytable. It must reside somewhere else. Other keys (that don't even show up there, like Europe 1[32]) or ScrollLock and Break [48] can be placed and moved, with NumLock that does't work.

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #64 on: Wed, 27 February 2013, 13:34:14 »
Only thing I figured out so far with my own clumsy experiments is, that the NumLock Key[53] cannot be mapped into that big keytable. It must reside somewhere else. Other keys (that don't even show up there, like Europe 1[32]) or ScrollLock and Break [48] can be placed and moved, with NumLock that does't work.

As of v2 of the firmware, the TECK uses a custom internal NumLock code (HID restricted code 0xEE) that isn't passed to the PC (or any other connected keyboards) and is only used to toggle the state of the NumLock on the TECK itself. As mentioned previously, all of that functionality is hardcoded into the keymappers instead of being sensibly implemented using layers.


Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #65 on: Wed, 27 February 2013, 17:28:08 »
The LED pins on the TECK live at:

B5 = Port 3.5 = Num Lock
B6 = Port 3.6 = Caps Lock
B7 = Port 3.7 = Scroll Lock

Tezkat, Tracer,
Did you figure out what the port 4.0 (pin #41) acts on ? Is there a fourth LED somewhere on the TE's PCB ?  :rolleyes:
« Last Edit: Wed, 27 February 2013, 17:39:43 by addwyn »

Offline Tezkat

  • Posts: 20
Re: Truly-Ergonomic’s keycodes remapping
« Reply #66 on: Fri, 01 March 2013, 02:14:20 »
As far as I know (though admittedly I failed to check last time I pulled out all my keycaps), there are only 3 LEDs on the TECK. Port 4.0 is however used internally by the firmware in a way very similar to the *Lock key indicators. I haven't yet taken the time to track it down, but it seems to have something to do with the keyboard being okay for input.

Offline zorglups

  • Posts: 25
Re: Truly-Ergonomic’s keycodes remapping
« Reply #67 on: Fri, 08 March 2013, 05:21:37 »
A big THANK YOU to the active geeks hacking this keyboard.
I actually like the keyboard quite a lot. I think it should have got other keys under the thumbs but this is off-topic.

I'm an heavy user of autohotkey for many years and do a lot of things with it. The only problem with AutoHotkey is that it won't work with VMWarePlayer and the likes. Anyhow, with AutoHotkey, I created a kind of second layer that gives me a numpad under my right hand when with my left thumb, I press the Enter key.
This is pretty cool as I don't have to move my hand to press the NumLock key. I could also add around my numpad symbols that I always use with numbers (like '.', '/', '\', ',', '-' and enter).

I found a really neat freeware that creates a second layer for your keyboard. This beauty is named TouchCursor found at http://touchcursor.sourceforge.net/
I did set the activator to be the left spacebar but it can be any key (on my regular keyboard, I did set it to the spacebar).
My layer activated by the left spacebar puts under my 2 hands all navigation stuffs and all characters usually reached by the Alt-Gr key (which I find difficult to reach on the TE):
j left
k down
l right
i up
h pgup
n pgdn
u home
o end
m del
; enter
s alt
d ctrl
f shift
x ctrl-x
c ctrl-c
v ctrl-v
z ctrl-z
a ctrl-a
...
and a few other.

The best thing is that it works even with VMWare.

I'm going to ask the author to allow more layout so I could have a second layout for the numpad and have it thumb activated.

I'll probably change slightly my TE firmware to remap a few keys and will be looking forward for all your discoveries.

I also think that making a soft that creates or modify the firmware would be really good for everyone but fully understand that people would be scared of developping this and risking to brick other's keyboard...

Thanks again to all !!!




Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #68 on: Mon, 27 May 2013, 17:22:36 »
(Attachment Link)

Truly Ergonomic released new firmware v3.

The keycodes addresses are changed (so, checksum codes are changed too) but their structure seem to be the same…



Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #69 on: Tue, 28 May 2013, 02:29:15 »


Thanks for the hint. The update seems to adress the wake up problems with some systems.   No major breaktrough towards full programmability yet.

Offline etatoby

  • Posts: 2
Re: Truly-Ergonomic’s keycodes remapping
« Reply #70 on: Thu, 06 June 2013, 15:17:15 »
While I always appreciate a good hex hack :cool: I need to ask: why aren't you just remapping the keys on the OS side?

For instance I use the Programmer Dvorak layout (on Mac, Win and Linux) and I wanted to swap a couple keys, plus adding my own palette of Unicode symbols to AltGr combinations. It didn't take long. There are visual layout editors for Mac and Windows, and you can edit the config files by hand on Linux.

So why are you hacking the firmware in the first place? Are you trying to tell apart two keys that produce the same scancode? (didn't look like that, sorry if I missed it) Because apart from that, I can't see why any other change can't be done, better and safer, in the OS. Even if you needed to work with legacy apps or games that look at the raw scancodes, I'm positive there are drivers or even user-space utilities to remap them.
« Last Edit: Thu, 06 June 2013, 15:27:16 by etatoby »

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #71 on: Fri, 07 June 2013, 01:14:11 »
While I always appreciate a good hex hack :cool: I need to ask: why aren't you just remapping the keys on the OS side?

Sure there are many ways of making a keyboard do what you expect it to do.

When I am using a non-standard keyboard like the Truly Ergonomic with a non-standand layout and that keyboard is supposed to be fully progammable then I’d prefer to program it once, so it works with my layout with the standard language settings for every OS on any machine I plug it in. Especially handy on systems where I don’t have admin rights and am not allowed to install drivers or change configs.

I am using a highly optimized layout to work with the standard German language settings with thumbs shift and a third layer for all special characters. (http://www.adnw.de/index.php?n=Main.OptimierungF%C3%BCrDieGeradeTastaturMitDaumen-Shift) (Sorry, German only). With the above hex hack I get at least part of that, exept the special characters layer which I still have to provide by software solutions or modifications of the standard language settings. So I am still dreaming of getting full programmability as it can be achieved with the Teensy controller for example used in the Ergo Dox project. It could also be done with the Megawin controller used by the TE, but I lack the skills to do it. Truly Ergonomic was promising full programmability but never delivered so far. The hex hack is a big step in the right direction though, improving the general usability of the TECK.

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #72 on: Fri, 07 June 2013, 12:39:06 »
While I always appreciate a good hex hack :cool: I need to ask: why aren't you just remapping the keys on the OS side?

I'd rather change the layout on the keyboard itself that way I can take the keyboard to various machines and have the layout I want, without needing to change anything on that machine's OS. I work with 4 different OSes on a regular basis, so changing layouts in the OS will be different for each OS. And there are machines that I can't change the OS, because I'm not the only one that work on them.

Also, I have found that layout changes in OS do not always make it across to other machines if I'm remoted into them, for various API reasons.
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #73 on: Fri, 07 June 2013, 12:54:25 »
Truly Ergonomic released new firmware v3.

The keycodes addresses are changed (so, checksum codes are changed too) but their structure seem to be the same...

Can we use the same OpenOffice spreadsheet to calculate the checksums? I want to apply the latest firmware on my 209, and I'm finally motivated enough to try to make some changes to the layout.
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #74 on: Fri, 07 June 2013, 15:41:40 »
Can we use the same OpenOffice spreadsheet to calculate the checksums? I want to apply the latest firmware on my 209, and I'm finally motivated enough to try to make some changes to the layout.

To answer my own question, I downloaded the original spreadsheet and updated it with the new address locations for the v3 firmware.

This one is for the v3 firmware:
* TrulyErgonomic_209_Keycodes_v3.ods (15.51 kB - downloaded 352 times.)

This one is for the v3 firmware with the control/shift swap:
* TrulyErgonomic_209CS_Keycodes_v3.ods (15.48 kB - downloaded 337 times.)
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #75 on: Fri, 07 June 2013, 19:46:11 »
Any chance someone can do a DVORAK layout for both the TECK 209 and 207? (DVORAK in firmware ;D )

I've created a Dvorak layout based on the 209CS_v3 firmware.
* nge-TrulyErgonomic_209CS_v3-20130607.hex (19.67 kB - downloaded 324 times.)

Since I don't plan on using the Mac layout (swapping control for command seems strange to me), I remapped that to Dvorak. Set DIP #2 to OFF to enable Dvorak.

I also made a few other tweaks, since the TECK layout doesn't quite map directly to Dvorak:

- Right Shift (home row) -> Dash(-).
- Quote(') -> Z.
- Left Space -> Backspace (DIP #3 -> OFF).
- Right Blank -> App/Context Menu.

This is the layout I've been using for over a year, but it used to be done completely on the OS side.
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline xiso

  • Posts: 8
Re: Truly-Ergonomic’s keycodes remapping
« Reply #76 on: Sun, 09 June 2013, 06:11:25 »
Does anybody know where are DIP switch #3 keycodes?

I usually use left thumb for space and wish to use right space for "Keyboard Lang 1" whose HID code is '90'.

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #77 on: Sun, 09 June 2013, 10:24:54 »
Does anybody know where are DIP switch #3 keycodes?

I usually use left thumb for space and wish to use right space for "Keyboard Lang 1" whose HID code is '90'.

In the v3 209 firmware, the code that deals with DIP #3 looks like this:
Code: [Select]
  088C 783C             MOV R0, #3Ch
  088E EF               MOV A, R7
  088F F6               MOV @R0, A              ;           keycode = R7;
  0890 20B208           JB P3.2, L0164          ;           if (not P3./DIP3) {
  0893 783C             MOV R0, #3Ch
  0895 E6               MOV A, @R0
  0896 B46502           CJNE A, #65h, L0164     ;               if (keycode == 0x65) // App
  0899 762C             MOV @R0, #2Ch           ;                   keycode = 0x2C; // Space
L0164:                                          ;           }
and duplicated:
Code: [Select]
  0CA9 783C             MOV R0, #3Ch
  0CAB EF               MOV A, R7
  0CAC F6               MOV @R0, A              ;           keycode = R7;
  0CAD 20B208           JB P3.2, L0199          ;           if (not P3./DIP3) {
  0CB0 783C             MOV R0, #3Ch
  0CB2 E6               MOV A, @R0
  0CB3 B46502           CJNE A, #65h, L0199     ;               if (keycode == 0x65) // App
  0CB6 762C             MOV @R0, #2Ch           ;                   keycode = 0x2C; // Space
L0199:                                          ;           }

However, you need to understand that the switch function is to conflate keys, not to differentiate them. The left thumb key is “born” with the App keycode, and the code above turns it into an additional Space.

So, if you just want to have a Space on your left thumb and a Keyboard Lang 1 (Hangul/English) on your right thumb, I suggest that you edit the primary keycode table (see first post; the base addresses in v3/209 are 072B for PC and 07BB for Mac mode) to replace 2C with 90 and 65 with 2C, and leave DIP #3 alone (since you no longer have an App key, it will not have any effect).

However, if you think wasting a DIP switch is a waste or if you want to make your new behavior configurable, you can additionally replace 65s in the above code with 90s, so setting DIP #3 to ON will turn your Hangul key into an additional space.

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #78 on: Sun, 09 June 2013, 11:19:13 »
I have been analyzing/hand-decompiling the v3/209 firmware, and what I have seen leads me to believe that this version nearly has macro programmability.

In the routine that handles new keypresses (the interesting part starts at 0322h), there is a call to a subroutine at 0B69h, which traverses a data structure assumed to be located at code/constants memory at address 2800h; but the stock firmware image does not have anything there. However, there is code that receives a 4K block over USB and flashes it at that address.

Studying the code at 0B69h (the routine that searches for a macro) and 043D (plays macro) reveals the layout of this block, which is roughly as follows.
  • At 2800h, we have a bit array of 20h bytes. A 0 in the bit N at address 2800+K indicates that the key with code N+8*K has macros. A 1 means to not bother looking for macros for this keycode.
  • At 2820h, there is a byte containing the number of macro bindings.
  • Immediately following at 2821h, macro bindings are located. Each binding is a 5-byte structure containing: the keycode, the modifiers bitmask (0x1 Ctrl, 0x2 Shift, 0x4 Alt; left and right not differentiated), a 2-byte absolute pointer to the macro body, and a byte-sized flag of unclear nature. Bindings with the same keycode (differing only by modifiers) must be stored contiguously.
  • Macro bodies also reside in the code/constants memory. The first byte is the number of events. Then, each event follows as a 10-byte structure: first 8 bytes of a HID report, then 2 bytes that specify in the low 12 bits the delay following this event, and the high 4 bytes are reserved for flags. The high bit flag specifies that after this event an empty HID report should be sent (all zeros, meaning release all keys).
  • A standard keyboard HID report contains in the first byte the modifier mask (0x01 LCtrl, 0x02 LShift, 0x04 LAlt, 0x08 LWin; 0x10 RCtrl, 0x20 RShift, 0x40 RAlt, 0x80 RWin), then a reserved byte, then 6 bytes of keycodes of keys that are pressed.
The macro processing code only runs in the mysterious Fn-less and NumLock-less mode activated by LShift+F12+F12.

Now for the sad part :) I said “nearly has” because of two things. Firstly, they aren’t (yet?) distributing a macro programming application. Secondly, in the macro playing code, there seems to be a the firmware puts 8 bytes in the USB transmit queue, but then tells the hardware to transmit 9. I don’t know what will happen in such conditions; the hardware might just freeze requiring a reset.

And, there are no traces of any on-the-fly macro programming. Meaning, it will be a standalone application, probably Windows. And since they are going the macro route, it seems that we geeks will have to resort to hex-hacking the firmware for basic key shuffling/relabeling.

Offline xiso

  • Posts: 8
Re: Truly-Ergonomic’s keycodes remapping
« Reply #79 on: Mon, 10 June 2013, 00:40:53 »
However, you need to understand that the switch function is to conflate keys, not to differentiate them. The left thumb key is “born” with the App keycode, and the code above turns it into an additional Space.

So, if you just want to have a Space on your left thumb and a Keyboard Lang 1 (Hangul/English) on your right thumb, I suggest that you edit the primary keycode table (see first post; the base addresses in v3/209 are 072B for PC and 07BB for Mac mode) to replace 2C with 90 and 65 with 2C, and leave DIP #3 alone (since you no longer have an App key, it will not have any effect).

However, if you think wasting a DIP switch is a waste or if you want to make your new behavior configurable, you can additionally replace 65s in the above code with 90s, so setting DIP #3 to ON will turn your Hangul key into an additional space.

It works perfectly.

Thanks a lot!!  ;D

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #80 on: Wed, 12 June 2013, 00:37:01 »
So, if you just want to have a Space on your left thumb and a Keyboard Lang 1 (Hangul/English) on your right thumb, I suggest that you edit the primary keycode table (see first post; the base addresses in v3/209 are 072B for PC and 07BB for Mac mode) to replace 2C with 90 and 65 with 2C, and leave DIP #3 alone (since you no longer have an App key, it will not have any effect).

This is exactly what I did with my Dvorak layout, to map backspace to the left spacebar.
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #81 on: Sat, 15 June 2013, 12:52:42 »
Teaser: I’m doing a series of presumably low-risk code changes to the firmware. (It’s all untested yet, I will make the results available as a downloadable .hex file after I actually flash it and confirm that it works. If you apply any of the changes detailed here, flash at your own risk.)

First, you may have noticed that the set of media keys (those that are sent by Fn+F1…F12 and Fn+Del) is wider than actually supported by the stock firmware. There is the 0C.1AE usage (AL Keyboard Layout) before the main array of Home|Email|…|Vol+|Eject, and five more after: 0C.B7 Stop, 0C.196 AL Internet Browser, 01.82 System Sleep, 01.81 System Power Down, 01.83 System Wake Up.

I strongly consider the latter three keys harmful (as keyboard keys). Additionally, since they are in a different HID usage page (01 General Desktop, as opposed to media keys in 0C Consumer), supporting them requires a whopping 29 bytes in the HID report descriptor (the data structure that tells the USB host about the mapping between keycodes on the wire and standard HID usage codes). By dropping these, we can extend the 0C part of the report descriptor, in two meaningful ways. First, we can pad the one-byte usages (Fn+F7 through Fn+Del and the unused Stop) to full 2-byte width, making them more customizable; this takes up 8 of the available bytes. The remaining 21 bytes allow for 7 more media keys. (And, luckily, the firmware internally represents media keys as usages 07.E8 and above, for a total of 24; we hit the space limit just one short of that.)

For the adventurous, here’s the changed portion (against v3/209):

:100D94000115012517750895010AAE010A23020AF7
:100DA4008A010A21020A94010A92010A83010AB6FD
:100DB400000ACD000AB5000AE2000AEA000AE900C6
:100DC4000AB8000AB7000A96010A99010A85010ABD
:100DD4009E010A9F010AA0010AB0010A91018160E3


The code that actually generates HID reports for these keys is the function at 0A76…0B68. On entry, it expects an internal code (0xE8…0xFA) at address 0x47. First it checks that the value is indeed in range; if not, writes 0x01 0x00 to addresses 0x48 0x49 and returns. Then there is a computed jump into a jump table that, depending on the value, transfers control into several little branches, all alike:

Code: [Select]
L0406:                                          ;   case 0xE8:
  0ACB 7848             MOV R0, #48h
  0ACD 7601             MOV @R0, #1h            ;       hid_report2[0] = 1;
  0ACF 08               INC R0
  0AD0 7601             MOV @R0, #1h            ;       hid_report2[1] = 1;
  0AD2 22               RET                     ;       return;
… and 18 more branches almost, but not entirely, identical to this …

What changes is the values written into #48 and #49; they represent the indexes into the usage lists in the HID report descriptor. Here is the correspondence between the input value and this second byte of the report:

in #47E8E9EAF7F8F9FAother
out #480101010102020201
out #490102031010111200

Since we removed the 02 report (which dealt with power management keys) and extended the 01 report (media keys), we will need to generate out values of 01 01 for E8 up to 01 18 for FE; and the simplest way is to just set #49 to #47 minus 0xE7 (after checking that #47 is at least 0xE8).

Code: [Select]
  0A79 C3               CLR C
  0A7A 94E8             SUBB A, 0xE8
  0A7C 4008             JC L9000                ;    if (media_keycode >= 0xE8) {
  0A7E 7848             MOV R0, #48h
  0A80 7601             MOV @R0, #1h            ;        hid_report2[0] = 1;
  0A82 08               INC R0
  0A83 04               INC A
  0A84 F6               MOV @R0, A              ;        hid_report2[1] = media_keycode - 0xE7;
  0A85 22               RET                     ;        return;
L9000:                                          ;    }
  0A86 7848             MOV R0, #48h
  0A88 7601             MOV @R0, #1h            ;    hid_report2[0] = 1;
  0A8A 08               INC R0
  0A8B E4               CLR A
  0A8C F6               MOV @R0, A              ;    hid_report2[1] = 0;
  0A8D 22               RET                     ;}

:100A76007847E6C394E84008784876010804F622E9
:100A86007848760108E4F622F0C58373020ACB02A1


We still don’t have any way to actually send these added media keys, but we’ve laid the groundwork. Additionally, we have saved 219 bytes of code space. We will put it to good use in a future hack.


Now, a bit of a public survey.
  • Have you noticed that pressing Fn affects keys you are holding down? E.g. hold down Caps Lock, press Fn; observe an Ins keypress is generated. (No, media keys don’t behave this way; only Esc, Caps, Num, 5%, 6^, ❖ and International-4 if you don’t turn it into a second Del with DIP #1.)
  • Does anyone actually press keys like this? I.e. is this a feature worth keeping? (If so, it actually mandates keycode-based Fn implementation rather than depending on physical key index.)
« Last Edit: Sun, 16 June 2013, 00:53:13 by Yuri Khan »

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #82 on: Sun, 16 June 2013, 04:52:41 »
In today’s installment, we will deal with the numeric keypad (NumLock mode), making it more configurable and revisiting the ergonomics of the keypad placement.

The data flow is as follows. The keyboard matrix consists of 18 columns, with up to 8 keys in each, allowing for a theoretical maximum of 144 keys (of which TECK uses only 88). The physical key index is the column number multiplied by 8, plus the index of key in the column. Here’s the layout as I believe it to be. (It has remnants of the Megawin reference keyboard design in some positions, incl. keypad codes; these are not used anywhere in the TECK firmware unless the wiring is physically modified.)

Col00Intl4 (Del)Euro2 (´¨)`~
Col01
Col02A2@Tab1!QZ
Col03RBlankCapsSpaceLCtrlRCtrl
Col04App
Col05LAltNumRAlt
Col06LShiftRShift
Col07FnLBlank
Col08
Col09WF1PgDnF2PgUpEscXS
Col10F3DelF4
Col11D3#E8*IK,<C
Col12G4$T5%RFBV
Col13J6^U7&YHMN
Col14\|F5EnterF6=+]}
Col15[{F7-_F89(O.>L
Col16'"F9F100);:P/?
Col17F11EndF12Home

Anyway, the key index (stored in data variable at #3B) is used with the PC and Mac keycode tables to yield a keycode (stored at #3C), which is then checked against 16 values, and if any matches, the corresponding keypad keycode is substituted instead. This all happens in the routine at 084B–095F.

The code that does the translation starts at 08AB and goes all the way through 094C, occupying 162 bytes. This gives me an idea…

Code: [Select]
  08AB 783B             MOV R0, #3Bh
  08AD E6               MOV A, @R0
  08AE 90xxxx           MOV DPTR, #xxxxh        ;               // to be filled later
  08B1 93               MOVC A, @A+DPTR         ;               byte num_keycode = num_keycodes[key_index];
  08B2 6002             JZ L9001                ;               if (num_keycode) {
  08B4 08               INC R0
  08B5 F2               MOV @R0, A              ;                   keycode = num_keycode;
L9001:                                          ;               }

The code to take a key index from #3B, fetch a keycode from a table and store it into the adjacent variable #3C takes 9 bytes; I also add a zero-check so that one table fits both PC and Mac modes, for a total of 11. Then I’m left with 151 bytes of free code space which will nicely accommodate the num_keycodes table. I’ll need to LJMP over it:

Code: [Select]
  08B6 02094D           LJMP L9002
num_keycodes:
  08B9                  DB 144 DUP (0)

CSEG AT 094D
L9002:

Now let’s see what this has gained us. Firstly, we are no longer keycode-dependent; we can remap both PC and Mac layouts and the numpad will stay its place. Secondly, we are not limited to 16 keys; if our heart so desires, we can add another keypad for the left hand, or add KP(, KP), KP=, and generally the whole block of keypad usage codes from B0 to DD. I won’t go into this, but I want to reconsider the placement.

The idea of embedded keypad comes from notebooks/laptops. Who was the first to come up with the idea that 7-8-9 stay in their usual place and other keypad keys are arranged around that I don’t know; but this has carried over to Truly Ergonomic without an ergonomics review.

When you use the keypad on a conventional keyboard, the home row position is 4-5-6; KP5 even has a tactile bump on it. However, on TECK in stock configuration, the home row produces 1-2-3; 4-5-6 are entered from the top row; and to type 7-8-9, you have to reach into the digit row.

I therefore propose that the keypad be shifted one row down. While we are at it, also move KP- and KP+ from their intuitive but remote place in the top right corner to somewhere around the main grid.

BeforeAfter
789 -+
456/
123*
0 .
/*-
789+
4560
123.

I have mixed feelings about the zero. If you are a left-spacer, you may want to put zero on the right space, as that’s where it is on the traditional keypad, under the right thumb. I myself am a right-spacer so I put zero on the remaining finger on the home row, as it is statistically the single most used digit.

:1008AB00783BE69008B993600208F202094D00000C
:1008BB00000000000000000000000000000000002D
:1008CB00000000000000000000000000000000001D
:1008DB00000000000000000000000000000000000D
:1008EB0000000000000000000000000000000000FD
:1008FB0000000000000000000000000000000000ED
:10090B0000000000000000000054605D5A00000071
:10091B000000000000005C005F6700005900000051
:10092B005800000000000000000055615B5E630092
:10093B000000566257000000000000000000783CE9


Again, I warn that this hack is untested (yet).
« Last Edit: Tue, 02 July 2013, 08:27:49 by Yuri Khan »

Offline djcybermyth

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #83 on: Sun, 16 June 2013, 12:38:42 »
Hey All,

Great work on the firmware hacking!  I'm super-excited about these developments and looking forward to permanently swapping the Ctrl and Alt keys for good!

I just did a quick search for an Intel Hex Checksum checker to help make sure that people are getting the correct checksums at the end of the records that they modify, and came up with some good links:

http://home.earthlink.net/~davesullins/software/

There are two perl scripts for checking Intel Hex files and one dissassembler program for creating 8051 Assembly from a hex file.

Hopefully, these can be useful in this effort!

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #84 on: Sun, 16 June 2013, 17:13:48 »
The code to take a key index from #3B, fetch a keycode from a table and store it into the adjacent variable #3C takes 9 bytes; I also add a zero-check so that one table fits both PC and Mac modes, for a total of 11. Then I’m left with 151 bytes of free code space which will nicely accommodate the num_keycodes table.
[…]
Firstly, we are no longer keycode-dependent; we can remap both PC and Mac layouts and the numpad will stay its place. Secondly, we are not limited to 16 keys

Wow ! That’s a great idea. Your code is concise effective and is giving much more flexibility than the original one.  :cool:
151 bytes freed to store a 144 bytes num_keycodes table without modifying any other piece of firmware. That’s cool !
I think I’ll give it a try soon…

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #85 on: Mon, 17 June 2013, 02:04:20 »
http://home.earthlink.net/~davesullins/software/

There are two perl scripts for checking Intel Hex files and one dissassembler program for creating 8051 Assembly from a hex file.

Yes, I actually started by using Dis51 to generate a listing file. (It has a quirk: when outputting in listing format (-l), it accepts both decimal and hex entry point values; but in plain disassembly, only decimal. And you do need to specify quite a few entry points, first for the interrupts, and then for each switch statement that happens to compile to a jump table. There are three of these, in the original v3/209.)

Plain disassembly proved to be nearly useless for modifications as, firstly, reassembly does not preserve the original .hex file section order nor even function addresses; and secondly, you just have to see the bytes of machine code if you want to fit in the original code size.

As for checksums, the spreadsheets in this topic and the Wikipedia article describe the algorithm just fine.

My workflow is: I have a master listing (obtained by disassembling the original .hex, annotated with the pseudo-C decompilation, with routine entry points renamed to sensible names and each variable briefly described at the top of file — address, size, data type, tentative name, and a list of functions where assigned and/or read). I modify a copy of that listing, first in pseudo-C, then in assembly, then in machine code. Then I do a diff of the modified listing against the master, and hand-type the differing bytes into a spreadsheet not unlike those posted in this thread. In that spreadsheet, I have a column that concatenates the source columns and the generated checksum into a single string. By copying cells from that column, I can generate the whole .hex or a portion of it.

To verify that I don’t screw up when reassembling, I check that the listing obtained by disassembling the modified .hex is equivalent to the listing with my modifications (up to renaming of the labels).

I am tempted to make the annotated master listing available somewhere for other geekhackers, but wonder what TrulyErgonomic’s lawyers might think of that. (Not that I did anything that another person couldn’t; but it did take me a couple weeks’ worth of evenings.)

Also, is there anyone out here who succeeded (or definitely failed, for that matter) in flashing the keyboard under Linux (without dual-booting into Windows)?

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #86 on: Wed, 26 June 2013, 08:00:27 »
I am in the works to replace the Fn key translation with a table-based lookup. (This way, I can move Fn to an easily accessible key and have a non-modal keypad (active when Fn is down, dismissed when I release Fn).) This has proved to be a not-so-low-risk hack, as I’m deleting lots of existing code, moving some code around, and otherwise messing with dangerous things :] Will report back when I get something working.

Meanwhile, a web-based keycode table editor. Assumes a sufficiently modern browser (current Firefox or Chrom{e|ium} should be OK), a font with decent Unicode coverage (for compact key labels) and a non-microscopic display (I’m fitting whole two keyboards there, after all).
« Last Edit: Fri, 28 June 2013, 01:30:11 by Yuri Khan »

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #87 on: Thu, 27 June 2013, 03:17:16 »

Meanwhile, a web-based keycode table editor.

That’s great. What took me days can be done now within minutes! Thanks a lot!

What do you think are the chances to arrive at a modifier activated third layer for special characters? Or is this too far off yet?

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #88 on: Thu, 27 June 2013, 10:34:49 »
What do you think are the chances to arrive at a modifier activated third layer for special characters? Or is this too far off yet?
This can be more easily achieved with your operating system’s facilities — XKB on X.org/GNU/Linux, MSKLC on Windows, and I believe there’s some solution for Mac, too. They mostly hijack your right Alt (or Option on Mac, or a modifier key of your choice on X) to give you two more character layers (in addition to normal and shifted, you get AltGr+ and Shift+AltGr+ layers).

The only advantage of implementing this at firmware level that I can think of is that it might work everywhere you plug in your keyboard, without reconfiguration of the operating system (as long as it supports HID devices that report page 0x10 (Unicode) usages).

I generally don’t lug my keyboard between computers I am not allowed to reconfigure, so this benefit does not appeal to me.

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #89 on: Thu, 27 June 2013, 10:54:43 »

The only advantage of implementing this at firmware level that I can think of is that it might work everywhere you plug in your keyboard, without reconfiguration of the operating system (as long as it supports HID devices that report page 0x10 (Unicode) usages).
Yes, I did this with MSKLC for Window and it works fine, but having an so called “programmable” keyboard it really would be nice to plug it into any machine and have my layout without fiddling with the standard Layout settings.  :(

btw: found a little error in your layout editor: the key for L should produce HID-code 0F not 1F (if I remember it right)

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #90 on: Thu, 27 June 2013, 13:50:02 »
Yes, I did this with MSKLC for Window and it works fine, but having an so called “programmable” keyboard it really would be nice to plug it into any machine and have my layout without fiddling with the standard Layout settings.  :(

Yes, but it’s really complicated to do in firmware, and every time you want to tweak your layout, you will have to reflash the firmware. For me, the reboot into Windows is so disconcerting, I haven’t yet even tested any of my changes I wrote about here.

btw: found a little error in your layout editor: the key for L should produce HID-code 0F not 1F (if I remember it right)
Sure. It’s fixed in the latest version, see changed link above.

And Truly Ergonomic have reported another bug to me, that I got the comma and period positions backwards. That’s fixed, too.

Offline dassuan

  • Posts: 15
Re: Truly-Ergonomic’s keycodes remapping
« Reply #91 on: Fri, 28 June 2013, 00:42:08 »
And Truly Ergonomic have reported another bug to me, that I got the comma and period positions backwards. That’s fixed, too.

Wow, does this mean Truly Ergonomic is interested in your work and supportive?

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #92 on: Fri, 28 June 2013, 01:36:49 »
They are, although their needs and mine are a little different.

I registered at JSFiddle so that I can fix bugs without having to update the link in my post. Here are the correct links to the latest version:

Truly Ergonomic keycode table editor
Edit in JSFiddle

Offline Nowaker

  • Posts: 3
  • Location: Gdańsk, Poland
    • AtlasHost - JIRA & Confluence hosting
Re: Truly-Ergonomic’s keycodes remapping
« Reply #93 on: Fri, 28 June 2013, 16:53:54 »
Thanks Yuri for providing this awesome JavaScript generator! I was able to flash my Truly successfully. :)

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #94 on: Sat, 29 June 2013, 04:33:33 »
Thanks Yuri for providing this awesome JavaScript generator! I was able to flash my Truly successfully. :)

And your Fn and Numlock combinations still work? TrulyErgonomic seems to be skeptical about that :)

Offline Nowaker

  • Posts: 3
  • Location: Gdańsk, Poland
    • AtlasHost - JIRA & Confluence hosting
Re: Truly-Ergonomic’s keycodes remapping
« Reply #95 on: Sat, 29 June 2013, 07:06:36 »
Yes, Fn works for me. I just hit Fn+F8 (play/pause) and my music stopped playing. :) I don’t care about Num Lock so I didn’t even bind it. I’ve got a small external numpad on the right as I don’t use a mouse (RollerMouse from Contour Design here).
« Last Edit: Sat, 29 June 2013, 07:10:59 by Nowaker »

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #96 on: Sat, 29 June 2013, 09:53:51 »
Oh. Now that’s a radical customization :) I assume you’re ok with not having PrtScr, then, or did you bind it directly?

Offline Nowaker

  • Posts: 3
  • Location: Gdańsk, Poland
    • AtlasHost - JIRA & Confluence hosting
Re: Truly-Ergonomic’s keycodes remapping
« Reply #97 on: Sun, 30 June 2013, 06:25:48 »
Yes, I bound Print Screen directly. No need for num lock or caps lock.

That's my layout, have a look :) The only customization I have now in xmodmap is swapping chars ? and |.

Code: [Select]
:10072B0000004C000035310000000000000000000C
:10073B00041F2A491E141D004D00E32C00E1340058
:10074B00274F002C52000000E00000460000004A3A
:10075B0000000000002B280000000000DFE000007C
:10076B0000000000000000001A3A4E3B4B291B16FC
:10077B00003C4C3D00000000072008250C0E3606FF
:10078B000A211722150905190D2318241C0B10110A
:10079B002B3EE63F2E302A502F402D412612370F8D
:1007AB00384251432733134A0044E2454D000000C1

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #98 on: Sun, 30 June 2013, 12:14:53 »
I am in the works to replace the Fn key translation with a table-based lookup.

OK, I got it done, tentatively. Meaning, I flashed it, it does report keys pressed, the reports aren’t complete and utter garbage, and it doesn’t freeze after a few presses :) (All of the above happened during debugging. Luckily, the code that reboots the keyboard in ISP mode was not affected, so I was able to reflash it without doing a hard reset which is complicated on this keyboard.)

Features:
  • Fn and Num Lock translation is now completely table-based and independent of the main layer. That is, if you move the Del key to bottom right and put Pause on the top right key, Eject will stay on Fn+Pause, not move with Del. The additional two layers can also be customized, up to every single key. Fn takes precedence over Num — if Num is on and Fn is down, the keys are interpreted according to the Fn layer.
  • Media keys are no longer confined to the Fn layer. You can have them in the main or Num layers, too. Keycodes E8h through FEh correspond to 23 different media keys (up from original 14 total).
  • Non-synchronized Num Lock has been extended to cover Num Lock-sensitive keys independent of the LED state. That is, if you press a key with keycode 59h (Keypad 1) through 63h (Keypad Dot) and the keyboard thinks your OS-level Num Lock is off, it will turn it on first, and turn off later when you stop typing. (In stock firmware, this behavior is tied to internal Num Lock status. But see Known bugs.)
  • Special pseudokeys Win+Pause and Ctrl+Break have been preserved. Keycodes ADh and AEh, respectively.
  • PC/Mac switch has been preserved. New keytables also have two versions each.
  • Other DIP switches (HenkanDelete, AppsSpace, Euro2Yen) no longer do anything. Ability to configure three keys was nice at the release of TECK, but is redundant when you can configure the whole thing.
  • Special keycode CFh (originally used for middle GUI key in Mac mode) was removed. It was necessary for differentiating between middle GUI which turns into Scroll Lock with Fn, and left GUI which doesn’t. With layer-based Fn translation, it is no longer relevant.
  • Special keycode EEh (originally non-synchronized Num Lock) changed to DEh, to free EEh for a media key.
  • And all this was achieved in smaller code space — my version has 10 holes ranging from 7 to 97 bytes :)
Known bugs:
  • Internal Num Lock keycode DEh leaks over USB. The host receives an unknown key press. This does not cause any problems but is a bit untidy.
  • Non-synchronized Num Lock may be too invasive — you won’t be able to play games that expect you to use the keypad in arrows mode.
I will test it for a day or so and then release the .hex, along with the addresses of keycode tables.

Offline bueller

  • MX baller
  • * Esteemed Elder
  • Posts: 3769
  • Location: Perth, Australia
  • Church of the Ergo Clear
Re: Truly-Ergonomic’s keycodes remapping
« Reply #99 on: Thu, 04 July 2013, 05:25:53 »
Just wanted to say a big thank you to all involved with this, currently typing this from my remapped 207!
It's a good width!  If it's half-width it's too narrow, and full-width is too wide. 

[WTT] bueller's trade thread - CLACKS WANTED

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #100 on: Sat, 06 July 2013, 03:31:31 »
OK, it’s been longer than I expected, but I also did more than I planned :)

Firstly, the bug with leaking 0xDE is fixed, as well as another bug I introduced. I have reflashed both my home and office keyboards and am pretty convinced they work as expected (for me).

Secondly, there is now a configurator for the modded firmware. Instead of requiring you to copy and paste lines of .hex, it now gives you a complete .hex file ready for flashing. You can test it here.

And lastly, I have set up a GitHub repository hosting the reverse-engineered firmware and my modifications, so that if someone wants to build on it, they don’t have to repeat my work. (You will still need to know i8051 assembly and hand-assemble your modifications to machine code.)

Offline addwyn

  • Thread Starter
  • Posts: 26
  • Location: Brest, France.
Re: Truly-Ergonomic’s keycodes remapping
« Reply #101 on: Sat, 06 July 2013, 07:33:41 »
Hi Yuri,

Very great work !  :cool:

May I ask you where you found the numbers of clocks cycles in the "micro_delay" function ?

Code: [Select]
micro_delay:                                    ;void micro_delay(byte __register(R7) iters) {
  1AA5 EF               MOV A, R7               ;   for (; iters >= 1; --iters) { // 1 clock
  1AA6 D3               SETB C                  ;                                 // 1 clock
  1AA7 9400             SUBB A, #0h             ;                                 // 1 clock
  1AA9 4004             JC L0017                ;                                 // 2 clocks
  1AAB 00               NOP                     ;                                 // 1 clock
  1AAC 1F               DEC R7                  ;                                 // 1 clock
  1AAD 80F6             SJMP micro_delay        ;   }                             // 2 clocks, total 9 = 0.75 microseconds per iter
L0017:
  1AAF 22               RET                     ;}

When I disassembled this part of the TE209-v3 firmware, I found 14 cycles (based on the Megawin’s doc "MG84FL54BD_A3.pdf"):

Code: [Select]
;--------------------------------------- -------------------------------------------------------------------------------
; Pause of R7 loops of NOP
;--------------------------------------- -------------------------------------------------------------------------------
;                                Clocks
L1AA5: MOV A,R7 1 ; Loop:
SETB C 1 ;   Carry=1
SUBB A,#000H 2 ;   A=A-Carry
JC L1AAF 3 ;   If Carry set (If R7==0) then RETURN
NOP 1 ;
DEC R7 3 ;   R7--
SJMP L1AA5 3 ; LoopEnd
;                        Total: 14      ; 1.16µs/loop = 291µs/250d = 583µs/500d = 875µs/750d = 1.166 ms/1000d
L1AAF: RET

Am-I wrong somewhere ? Is the "MG84FL54BD_A3.pdf" file erroneous ? Are the Keil’s 8051 instruction set descriptions more exact ? What is your opinion ?
« Last Edit: Sat, 06 July 2013, 17:23:25 by addwyn »

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #102 on: Sat, 06 July 2013, 11:03:01 »
OK, it’s been longer than I expected, but I also did more than I planned :)

Wow. This is awesome. Thank you for your great work on this!
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #103 on: Sat, 06 July 2013, 22:17:20 »
May I ask you where you found the numbers of clocks cycles in the "micro_delay" function ?
I took the timings from the Keil site.
Am-I wrong somewhere ? Is the "MG84FL54BD_A3.pdf" file erroneous ? Are the Keil’s 8051 instruction set descriptions more exact ? What is your opinion ?
I guess you’re right and the direct manufacturer knows their chip better. I did not pay much attention to the exact values of the time intervals; for understanding the logic, it was sufficient to know the order of magnitude (that one micro_delay iteration is close to 1 microsecond).

I will update the disassembly with timings from the datasheet.
« Last Edit: Sat, 06 July 2013, 22:18:51 by Yuri Khan »

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #104 on: Sun, 07 July 2013, 11:26:27 »
I have looked at the various versions of the firmware released by Truly Ergonomic for different models, and am pretty sure my mod will work on all of them, with changes only in the layout configuration. I therefore added a model selector on the configurator, and collected their factory default layouts on a wiki page.

If someone with 207 or 104/105 wants to test this hypothesis, please have a spare keyboard handy and use it to report any bugs you encounter ;)
« Last Edit: Sun, 07 July 2013, 12:06:14 by Yuri Khan »

Offline listboss

  • Posts: 22
Re: Truly-Ergonomic’s keycodes remapping
« Reply #105 on: Wed, 10 July 2013, 17:50:04 »
I have looked at the various versions of the firmware released by Truly Ergonomic for different models, and am pretty sure my mod will work on all of them, with changes only in the layout configuration. I therefore added a model selector on the configurator, and collected their factory default layouts on a wiki page.

If someone with 207 or 104/105 wants to test this hypothesis, please have a spare keyboard handy and use it to report any bugs you encounter ;)

Just wanted to say a great thank you for your great work. very appreciated.
Is it possible to use your configurator and add 'layer' functionality to TEK?
I am interested in getting TEK similar to ErgoDox, for example replace the LEFT ARROW key with FN key
« Last Edit: Wed, 10 July 2013, 17:53:50 by listboss »

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #106 on: Wed, 10 July 2013, 21:33:33 »
Is it possible to use your configurator and add 'layer' functionality to TEK?
I am interested in getting TEK similar to ErgoDox, for example replace the LEFT ARROW key with FN key

In the current version, you have three layers for each position of the DIP switch 2. Two of them are persistent (Main and Num) and switched with a key that you configure as T⇭ (TECK Num Lock). The Fn layer is transient and is activated when a key configured as Fn is held down. These switching keys can be placed on any of the 88 keys.

So yes, you can make your Left arrow a Fn key and then bind IJKL or HJKL in the Fn layer to arrows. Shortcuts like Shift+arrow will work, as long as you don’t override Shift in the Fn layer. But I imagine Ctrl+Alt+arrow shortcuts will not be very convenient to press.

Offline listboss

  • Posts: 22
Re: Truly-Ergonomic’s keycodes remapping
« Reply #107 on: Thu, 11 July 2013, 11:05:44 »
So yes, you can make your Left arrow a Fn key and then bind IJKL or HJKL in the Fn layer to arrows. Shortcuts like Shift+arrow will work, as long as you don’t override Shift in the Fn layer. But I imagine Ctrl+Alt+arrow shortcuts will not be very convenient to press.

That's great news however, I have a 207 model and I used the configurator to just change the layout
to Colemak (nothing fancy) using this file.
But after flashing the hex the layout is completely different/nuts  :eek:
For example this is what I get when I type 'yuri khan'  --> 'jlpu ehak'  :)
my dip switch is set as: 11010

Am I missing something here or this can be bug?

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #108 on: Thu, 11 July 2013, 11:28:09 »
I have a 207 model and I used the configurator to just change the layout
to Colemak (nothing fancy) using this file.
But after flashing the hex the layout is completely different/nuts  :eek:
For example this is what I get when I type 'yuri khan'  --> 'jlpu ehak'  :)
my dip switch is set as: 11010

Am I missing something here or this can be bug?

My crystal ball is a bit blurry but it suggests that you might have a case of double Colemak translation. This will happen if, on top of your keyboard remapped to Colemak, you also have the Colemak layout selected in your OS.

Choose one level where remapping happens. You can leave your keyboard QWERTY and use the Colemak layout in your OS (recommended), or you can remap the keyboard to Colemak and use the standard QWERTY layout at the OS level (only for users who want to use Colemak without having to, being able to or being allowed to configure the OS).

Also, in my book, in Colemak the top row goes QWFPG and the bottom row ZXCVB. Your link has G/B/V rotated, is that intentional?
« Last Edit: Thu, 11 July 2013, 11:49:56 by Yuri Khan »

Offline listboss

  • Posts: 22
Re: Truly-Ergonomic’s keycodes remapping
« Reply #109 on: Thu, 11 July 2013, 12:18:04 »
Also, in my btook, in Colemak the top row goes QWFPG and the bottom row ZXCVB. Your link has G/B/V rotated, is that intentional?
yes it is.

I have made sure the OS is set to qwerty, and no other input method is even active in control panel (win7)
I prefer the hardware solution since I take my keyboard with me to work/home and I don't wanna deal with
os settings, it's specially helpful when you are at login screens and the layout driver hasn't kicked in yet.

But I believe you are right that another software might be interfering, will update when I figure it out.

thanks

Offline tayot

  • Posts: 13
Re: Truly-Ergonomic’s keycodes remapping
« Reply #110 on: Sat, 13 July 2013, 18:15:04 »
[quote author=Yuri Khan link=topic=38943.msg953309#msg953309 date=1373214387
If someone with 207 or 104/105 wants to test this hypothesis, please have a spare keyboard handy and use it to report any bugs you encounter ;)
[/quote]

Yuri Khan - Just want to say thanks for your awesome work and express my appreciation. I have a 207  that was sitting in a box because I couldn't get used to the way some keys like Ctrl, Shft and Alt were placed. Even used Keytweak a while back. I just flashed it recently and have been enjoying it a lot. So far so good. My adjustments were pretty basic - but I'm a happy camper. I'll be ordering another TEK board now that I know I can reconfigure the keys. Once again thanks very much.

Offline xsar

  • Posts: 8
Re: Truly-Ergonomic’s keycodes remapping
« Reply #111 on: Wed, 31 July 2013, 13:01:03 »
thank you so much for your excellent work, yuri! typing on my newly flashed dvorak layout. what I didn't get to work though is the FN-xcv (cut-copy-paste commandz) though, I'm assuming the applications I tested it with don't support this command.
« Last Edit: Thu, 01 August 2013, 01:17:30 by xsar »

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #112 on: Wed, 31 July 2013, 13:48:31 »
Yes, it’s very possible that applications ignore AC Cut/Copy/Paste keys. If you are on Windows, maybe you can translate them to ordinary Ctrl+XCV with some thirdparty software — such as Microsoft IntelliType or AutoHotkey.

Do also be aware that, as you’ve rearranged keys form their normal positions, you won’t be able to use any international keyboard layouts. Additionally, playing games (such as those using WASD keys for motion) might be very uncomfortable :)

Offline sparhawk

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #113 on: Fri, 02 August 2013, 20:57:57 »
Hi,

I'm a little scared of flashing my firmware with a custom keymap, especially after Tracer's experience in bricking his/her keyboard. How dangerous do you think it is to use your firmware generator, Yuri Khan? Obviously there are no guarantees, etc., but what is your feeling for how safe this process is?

(I've been trying to mess around with xkb in Linux, but I'm finding it all a bit too complicated for me. I can find files to move alphanumeric keys, but am not sure where the shift keys, etc. are.)

Cheers.

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #114 on: Sat, 03 August 2013, 01:50:25 »
About as safe as crossing the street on a red light after a careful look at the sides.

Of course it’s dangerous. If power goes out while you’re flashing, or if USB connection drops due to a flaky cable or port, or another program starts swapping like crazy or locks up your computer, you can brick your keyboard. This is why Truly Ergonomic discourages flashing from a virtual machine, or with a USB hub in between your computer and keyboard, or having many other programs running — not because flashing definitely won’t work, but because it increases the probability of failure.

On the other hand, I have successfully reprogrammed my two keyboards from within VirtualBox (from Oracle repositories, with USB support) over an unpowered USB hub.

And on the third hand, unlike the street crossing analogy, I believe the worst you can get into is having to open up the keyboard and to issue a hard reset by shorting pins 1 and 36 while powered. (Of course, if you end up in this situation, there are more chances to screw up.)

Offline sparhawk

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #115 on: Sat, 03 August 2013, 02:28:53 »
Thanks Yuri. That's good to know. I do jaywalk, so it would be hypocritical of me not to reflash the firmware.  ;D

If the major potential problems are those that you mention, I'm happy to take the risk, I think. I was more afraid of some imperfect code getting into and bricking the keyboard (since it's reverse engineered). I presumed that was what happened with Tracer.

Also, my keyboard is still under warranty, so I didn't really want to break the sticker at the back. I still think there is a slim chance I might have to return it, as I still occasionally have issues with missed or repeating key presses, although it's definitely getting better. Thanks again for the advice (and software!).

Offline tekkendama

  • Posts: 4
Re: Truly-Ergonomic’s keycodes remapping
« Reply #116 on: Wed, 07 August 2013, 11:03:31 »
thank you so much, Yury.

It works a charm.

Offline sparhawk

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #117 on: Fri, 09 August 2013, 06:17:22 »
Huh… I was just about to sit down and create my layout with Yuri's script, when I spotted the official firmware reprogrammer, which must have just come out…

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #118 on: Fri, 09 August 2013, 08:46:27 »
Yay! We have a public release! :)

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #119 on: Fri, 09 August 2013, 13:59:49 »
Yay! We have a public release! :)

Is it based on your work? If so, congrats!
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #120 on: Fri, 09 August 2013, 14:05:32 »
Huh… I was just about to sit down and create my layout with Yuri's script, when I spotted the official firmware reprogrammer, which must have just come out…

Weird. I can't get that link to load at all. I can get the main page to load, but no other pages off of it.
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #121 on: Fri, 09 August 2013, 16:05:11 »
Nevermind. Looks like they were in the middle of updating their pages, and I was getting blank pages due to it. They're all working again.
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #122 on: Fri, 09 August 2013, 18:13:16 »
@Yuri, what are your thoughts of setting up macros via the firmware?

My thoughts are to use the Fn layer to map a bunch of common symbols used for programming. My inspiration in the "PunctPad" feature of the old Fingerworks Touchstream keyboards. The "PunctPad" modifier was all internal to the keyboard, so that, holding down the modifier on the left hand, on the right hand, you get the following outputs:

y -> //
u -> {
i -> }
o -> [
p -> ]
h -> ->
j -> -
k -> _
l -> (
; -> )
n -> !=
m -> +
, -> =
. -> |
/ -> \

Obviously this is with a QWERTY layout. The 2 character macros can't be replicated at this time, but some of the single key ones I can map to the Fn layer, and I can get the shifted versions by mapping the shift key to the Fn layer (I hope, I haven't actually tried it). But with support of 2 character macros, the shifted keys can also be supported.
« Last Edit: Fri, 09 August 2013, 18:15:32 by nomaded »
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #123 on: Fri, 09 August 2013, 19:03:03 »
Here's my Dvorak layout with "PunctPad" on the "main" layer. I have the QWERTY layout on the "alternate" layer. The programming symbols are on the Fn layer for both layouts. I'm still experimenting, but if I change things up, I'll update this post.

The Main (Dvorak) layer:
31743-0

The Alternate (QWERTY) layer:
31745-1

The Fn layer:
31747-2

Edit 20130810: updated the url because I forgot to move a key in the Alternate Fn layer.

Edit 20130814: I've update the url and the images to reflect the following:
-   I've put the tab key back in the center, on home row. I've been missing the tab key in the higher position a lot more than I would have expected.
-   I found that I was mistakenly hitting the LGUI key quite a bit when it was above the Enter key. I've moved LGUI to the key below it's normal position, because I wal also hitting it by accident when I lift my hands to touch type 5 or 6.
-   I have put the TECK Fn key above the Enter key for easy access to my "PunctPad". I also moved the LShift key in the Fn layer to follow the Fn key.
« Last Edit: Wed, 14 August 2013, 17:46:09 by nomaded »
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #124 on: Fri, 09 August 2013, 20:50:04 »
The firmware code contains a preliminary implementation of a macro facility, although, as far as I know, it never was released as a public feature. Notably, there is no macro programming application available. The protocol for uploading macros into a working keyboard is also not quite clear to me.

I believe it should be possible to set up macros by including them into the firmware image (possibly extending the layout configurator).

That said, I see no possibility of actually writing a macro that will always produce e.g. ->, in all applications on all operating systems, no matter whichever language layout is active:
  • Straightforward keypresses (-_, LShift down, .>, LShift up). This is limited to US English QWERTY or a sufficiently similar layout.
  • Windows/DOS Alt+nnnn codes (turn on Num Lock if needed, LAlt down, K0, K4, K5, LAlt up, LAlt down, K0, K6, K2, LAlt up, restore Num Lock). Works only in Windows and only for characters included in the ANSI and/or OEM code page. (There is also a Unicode method that involves the K+ prefix and a registry key.)
  • Linux: simulate a Ctrl+Shift+U press/release, then simulate entering the Unicode hex code, then Enter. Only Linux and only in most but not all applications, depending on the GUI library used.
Therefore, such macros will have to be personal and tailored to each user’s particular needs. Not going to be as easy as “enter a string to be ‘typed’”.

Offline sparhawk

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #125 on: Fri, 09 August 2013, 23:32:29 »
Hi Yuri, I was wondering if it were possible to remap keys to control brightness. (Currently, in xmodmap, I have Fn+F5 and Fn+F6 mapped to XF86MonBrightnessDown and XF86MonBrightnessUp.) I couldn't find anything in the default keys, so I looked for the HID codes, but it seems like these are not covered by page 07 or 0C. If I am reading it correctly, the codes are 0x0070 and 0x006F. These won't work in the configurator. Does this mean it's not possible to map them?

Thanks again for the script and all your comments. Cheers.

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #126 on: Sun, 11 August 2013, 03:19:48 »
There does not seem to be any HID usage codes for brightness. Also, searching the sources of the Linux HID driver for “brightness” only yields a few places for specific Apple and Chicony keyboards.

I do not know where you got 0x6F and 0x70 from. The Linux kernel codes are 224 (E0h) and 225 (E1h), the evdev-style XKB key codes are 232 and 233, and the XF86 keysym codes are 0x1008FF02 0x1008FF03, but none of these are usable in the configurator which only deals with usage codes.

I believe your solution of mapping XF86MonBrightness* by means of XKB configuration is optimal. (Apple and Chicony can get away with a driver quirk because their keyboards are mass-produced. Your configuration, on the other hand, is unique.)

Offline sparhawk

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #127 on: Sun, 11 August 2013, 06:53:09 »
There does not seem to be any HID usage codes for brightness.

Thanks again. I may have misinterpreted the page, but I followed your link to the HID Usage Tables and then clicked on the link saying Review Request 41:  Display Brightness Controls.

I'm not sure if it's relevant, but the internal keyboard of my Dell laptop has brightness-modifying keys that work out-of-the-box. I suppose there are non-HID ways to send keystrokes…

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #128 on: Sun, 11 August 2013, 07:43:40 »
Nice. This review request is marked as “Approved”; this means the new usage codes will likely be in the next version of the HID Usage Tables.

Still, they have this disclaimer:

Quote
Please note that the creation of a new Usage does not imply support for that Usage by any USB HID Host vendor.

In case of Linux, this means that someone needs to submit a patch that adds such support.
« Last Edit: Sun, 11 August 2013, 07:53:41 by Yuri Khan »

Offline sparhawk

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #129 on: Sun, 11 August 2013, 08:10:02 »
In case of Linux, this means that someone needs to submit a patch that adds such support.

Does the fact that my laptop's inbuilt keys work suggest that Linux already supports them?

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #130 on: Sun, 11 August 2013, 09:01:10 »
Sorry to disappoint you. I have checked the driver source and there is no code to handle these new usages. Your laptop probably uses some other mechanism to control monitor brightness — maybe ACPI events. And no, I don’t think you can generate those from your Truly Ergonomic keyboard without significant changes to the firmware.

Offline nomaded

  • Posts: 197
  • Location: Andover, MA
Re: Truly-Ergonomic’s keycodes remapping
« Reply #131 on: Wed, 14 August 2013, 17:47:56 »
Some additional alternate layouts have been posted to TECK's website.

I've also made some small changes to my alternate Dvorak layout.
« Last Edit: Wed, 14 August 2013, 17:50:04 by nomaded »
Dvorak
ErgoDox fullhand (MX Clears) w/Nuclear Green Data SA || Infinity ErgoDox (Zealios 78g tactile) w/SA Retro || Atreus62 (MX Clears) w/Chocolatier || TECK 209 (MX Browns) || TouchStream ST
Kensington Slimblade Trackball || Logitech Cordless Optical Trackman || Apple Magic Trackpad
Current Dvorak-based ErgoDox layout || Current Dvorak-based TECK layout

Offline sparhawk

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #132 on: Thu, 15 August 2013, 06:42:27 »
Sorry to disappoint you. I have checked the driver source and there is no code to handle these new usages. Your laptop probably uses some other mechanism to control monitor brightness — maybe ACPI events. And no, I don’t think you can generate those from your Truly Ergonomic keyboard without significant changes to the firmware.

Thanks very much for checking anyway, Yuri.

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #133 on: Sun, 14 December 2014, 18:03:34 »
Hi
I am considering whether to buy a TE, and have been looking at the online layout creator.

I have a very simple (maybe stupid) question about which I asked TE but got no reply.
When you drag a key into a location on a layout, the shifted and unshifted characters travel together.

For example,  ] and } are always together on a key.
Does this mean that you always need to press SHIFT to get a } character? So if the key is on the fn layer, you would need to press fn+SHIFT+} to get a } character?

How do you specify to the mapper that you want the shifted character?



Offline Sc0tTy

  • Posts: 167
  • Location: Netherlands
  • Ergo enthousiast
Re: Truly-Ergonomic’s keycodes remapping
« Reply #134 on: Sun, 14 December 2014, 18:30:49 »
Hi
I am considering whether to buy a TE, and have been looking at the online layout creator.

I have a very simple (maybe stupid) question about which I asked TE but got no reply.
When you drag a key into a location on a layout, the shifted and unshifted characters travel together.

For example,  ] and } are always together on a key.
Does this mean that you always need to press SHIFT to get a } character? So if the key is on the fn layer, you would need to press fn+SHIFT+} to get a } character?

How do you specify to the mapper that you want the shifted character?

Yeah they are together. You are just moving around normal keys. Sadly you cant do what you are thinking of, I would love for that to be added. Same goes for combo's. Maybe in the future this will be added but I guess only time will tell.

1x ErgoDox EZ
2x Truly Ergonomic Keyboard 229
2x Kinesis Freestyle V3-VIP
2x Bamboo Pen & Touch (Mouse replacement)
2x Salli Swing
1x Herman Miller Aeron

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #135 on: Sun, 14 December 2014, 20:41:27 »
When you drag a key into a location on a layout, the shifted and unshifted characters travel together.
Does this mean that you always need to press SHIFT to get a } character? So if the key is on the fn layer, you would need to press fn+SHIFT+} to get a } character?

Yes and no.

When you press a key or an Fn+key combination, the keyboard sends a key code to the computer. It is then the operating system’s concern to translate that code into characters.

The TECK configurator deals with the first of these two steps only: you choose which key sends which key code, and for your convenience the key codes are displayed as the characters they are mapped to in the standard PC US keyboard layout. So if that’s the layout you use, you get a pretty accurate representation of what you get.

On the other hand, many users (myself included) use other layouts. They (we) are expected to know the mapping between US QWERTY and their (our) layouts. So on a standard Russian layout the [{ keycode maps to the letter Х (that’s Cyrillic Letter Ha, not Latin Letter X).

The configurator is primarily meant to customize the placement of editing keys such as Enter, Backspace, Shift/Ctrl/Alt, Ins, Del and such; and a few punctuation keys. If you want to customize your layout at the shift state level, you had better use the facility provided by your OS — xkb in Linux, Ukelele on OS X and MSKLC on Windows.

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #136 on: Sun, 14 December 2014, 23:25:02 »
I think I understand, thanks.

It would be much nicer though if the keyboard itself could store a default shift state (and other modifiers) for each mapped key, and prefix the appropriate modifier codes before sending the mapped keycode. That way, you would get the same result on any computer, and you would not have to futz with both the keyboard and mapping software on the os.

(Where modifier keys were pressed, that would reverse the defaults for each modifier)

Offline Sc0tTy

  • Posts: 167
  • Location: Netherlands
  • Ergo enthousiast
Re: Truly-Ergonomic’s keycodes remapping
« Reply #137 on: Mon, 15 December 2014, 03:14:22 »
Yeah. I still need to look at manually configuring keycodes on the board. Apparently it should be possible to do this but I haven't tried it yet.
1x ErgoDox EZ
2x Truly Ergonomic Keyboard 229
2x Kinesis Freestyle V3-VIP
2x Bamboo Pen & Touch (Mouse replacement)
2x Salli Swing
1x Herman Miller Aeron

Offline Sc0tTy

  • Posts: 167
  • Location: Netherlands
  • Ergo enthousiast
Re: Truly-Ergonomic’s keycodes remapping
« Reply #138 on: Wed, 17 December 2014, 13:32:12 »
Yeah looks like we'll have to use AHK or some other solution..

Hopefully they or Yuri can add this in the future.
I would love to have dedicated CTRL+C and { keys!
1x ErgoDox EZ
2x Truly Ergonomic Keyboard 229
2x Kinesis Freestyle V3-VIP
2x Bamboo Pen & Touch (Mouse replacement)
2x Salli Swing
1x Herman Miller Aeron

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #139 on: Wed, 18 February 2015, 00:05:01 »
Hi again
Just received my TEK today, and looking more closely at mapping options.

I intend to use remapping software on my machine in addition to remapping, as Yuri suggests, to get the desired effect.

So I started out intending to use T_FN on the left space key. However, a quick experiment showed me that T_FN is purely internal to the TEK and does not transmit a modifier key. (Interestingly, on the Mac, the Fn key *does* transmit a code, but I cannot find a corresponding code on Yuri's mapper, nor in the USB HID tables).

Without a modifier present, I have no way to remap the keys in software. Eg I want to put the 9( key produced when I hit T_FN+Y, and then map this to the shifted version ( in software.

With a normal keyboard I could use R_CTRL or R_ALT for this purpose, and not use them for their normal role, but the non-orthogonal TEK layout does not lend itself to pressing a left modifier while pressing a left handed key with the right hand, so I'd like to keep these modifiers in their usual role for now.

Is the only option use T_FN to produce a codes not normally used, like the numpad keys, than remap those to unrelated keys in software?

Also, is there a way for T_NL to function like a shift key (ie not locking, but just accessing the number keys while the T_NL is held down)

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #140 on: Wed, 18 February 2015, 00:45:04 »
Hello pw,

if you find out which HID usage code the Mac Fn key transmits, you can click any key on the configurator and just enter it as a hexadecimal number followed by the letter h. E.g. 2Ch is the code for Space. (The case is not significant.) Otherwise, maybe you can persuade your remapping software to react to a keycode of your own choice, such as F13.

As for a non-locking Num modifier, I actually put the T_FN (not T_NL!) on my middle bottom key and put keypad keys in the Fn layer. I’ve got mixed feelings about the utility of that; most of the time, I just reach for the digit row.

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #141 on: Wed, 18 February 2015, 01:56:16 »
Thanks Yuri
Do you know of a quick and dirty way of dumping the HID codes? A quick search found python library python-libusb1 which will probably do it for me, but Id rather not go down any rabbit holes I can avoid.

Yes, I was thinking of the same with the T_FN, but I wanted mainly punctuation on the fn layer, not leaving enough for the numbers too.

PS Have you hand-assembled the 8051 code to modify the existing TE code? Do you know if (eg) the MCU 8051 IDE could be used to develop in C instead?

« Last Edit: Wed, 18 February 2015, 02:00:44 by pw »

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #142 on: Wed, 18 February 2015, 01:57:08 »
Thanks Yuri
Do you know of a quick and dirty way of dumping the HID codes? A quick search found python library python-libusb1 which will probably do it for me, but Id rather not go down any rabbit holes I can avoid.

Yes, I was thinking of the same with the T_FN, but I wanted mainly punctuation on the fn layer, not leaving enough for the numbers too.

PS Have you hand-assembled the 8051 code to modify the existing TE code? Do you know if (eg) the MCU 8051 IDE could be used to develop in C instead?


Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #143 on: Wed, 18 February 2015, 03:22:48 »
I believe the quickest and dirtiest would be to use a slightly modified hid_listen tool from the PJRC Teensy kit. (You’d need to modify the VID:PID of the device to which it connects.) Alternatively, you might be able to use wireshark.

Yes, all the modifications I have done to the TE firmware are hand-assembled. I have done a few experiments and am fairly convinced the SDCC compiler (which is used by MCU 8051 IDE) can be used to program the TECK. I plan to implement a firmware providing at least all the features of the existing one, plus freedom to tinker with.

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #144 on: Wed, 18 February 2015, 03:41:40 »
>I plan to implement a firmware providing at least all the features of the existing one, plus freedom to tinker with.

Wow! I look forward to tinkering.
I hope that it works out for you Yuri, and that TE is recompensing you for your efforts.



Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #145 on: Sat, 21 February 2015, 05:09:32 »
Ive been experimenting with a few layouts, think I found a small problem with the keypad digits. Instead of transmitting just K1 etc, six HID codes are transmitted for each key press. Pressing K1 will give

clear/num lock down (47)
clear/num lock up
K1 down (53)
K1 up
clear/num lock down
clear/num lock up

Maybe this represents a workaround of some sort, but while it does give digit chars in a word processor, it wont work in a calculator because the number is immediately cleared.

I will put in the normal keyboard digits instead, but the keypad digits are more useful because you can use Karabiner etc to default to symbols on the keyboard, then use the keypad to enter numbers without having to press shift in addition to T_FN.

paul


Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #146 on: Sat, 21 February 2015, 05:59:43 »
Yes. This is what Truly Ergonomic calls “non-synchronized Num Lock”. Basically, when you press T_NL, the keyboard lights up the Num Lock LED but tells nothing to the OS, so that the OS thinks Num Lock is off. When you press a key, the keyboard tells the OS “hey, the user pressed and released Num Lock to turn it on, then pressed and released End/1, then pressed and released Num Lock to turn it back off”. As a result, the OS should produce a 1 digit. (This logic only kicks in if the OS-reported Num Lock status is off; if on, each keypress generates a single key up/down pair.)

This feature was introduced in version 2 of the firmware, AFAIR. The motivation was that otherwise TECK would be controlled by the Num Lock status sent by the OS. And some PC BIOSes turn on Num Lock at boot, which makes typing on TECK 1 very inconvenient.

Why does your calculator clear the number when Num Lock is turned off?

Oh wait. Macs do not have a notion of Num Lock mode and call the key with that keycode Clear? D’oh.

Is there a way to cause a Mac to tell the keyboard that Num Lock is on so it won’t try to turn it on and off each time?

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #147 on: Sat, 21 February 2015, 07:16:16 »
Erggh, thanks Yuri
I figured it was something like that, but it still doesn't make much sense to me.
I can see how you would need that if you were always transmitting a 'j' so the os needed to interpret the character as 'j' or '1' depending on its own numlock state. But in our case a unique code for k1 is transmitted, so shouldn't it work regardless of the os numlock state?
Also, if the os numlock state is initially set wrong on some machines, and correct number entry does depend (somehow) on having the correct os numlock state, even when sending unique codes, then wouldn't the first character be lost, because the first sent num lock would turn the os numlock state to off?

 Anyhow, the is a setting in Karabiner to disable num lock for the logitech N305 which appears to do the trick.

Thanks again.

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #148 on: Sat, 21 February 2015, 07:40:10 »
More info:
The numpad number keys do seem to behave correctly in the numpad layer itself; I was using them in the fn layer.

Offline Yuri Khan

  • Posts: 31
  • Location: Novosibirsk, Russia
Re: Truly-Ergonomic’s keycodes remapping
« Reply #149 on: Sat, 21 February 2015, 07:43:15 »
On PCs, the code 59h is interpreted as Keypad 1 and produces the digit 1 only when OS Num Lock is on. Otherwise, it gets interpreted as Keypad End and moves the cursor. Therefore:
  • if OS Num Lock is off, the keyboard turns it on by sending a 53h down and up, then the actual key, and then restores OS Num Lock back after key activity pauses;
  • if OS Num Lock is on, the keyboard only sends the actual key.
This is how the firmware currently works.

On Macs, there is no Num Lock; keypad keys always generate digits (as far as I understand). Additionally, the key code 53h is interpreted as Clear. So:
  • on Mac, the keyboard should only send the actual Keypad key code without any Num Lock keypresses.
Problem is, the keyboard has no means of automatically knowing it is connected to a Mac.

Cross-platform development is hard. I will need to remember this particular gotcha for the C firmware project.

Offline Azteca

  • Posts: 29
Re: Truly-Ergonomic’s keycodes remapping
« Reply #150 on: Sat, 21 February 2015, 20:02:20 »
Basically the firmware Keypad codes works OK for PC  :thumb:
but it has a gotcha for Macs.

So for Macs, I tested setting hex code 59h directly into the layout designer, by typing “59h”, but it gets immediately translated by the layout designer into Keypad 1.

Is it possible to type another code that will just send hex 59h without getting translated into Keypad 1?

Is it possible to use/set one of the "23 special codes" like Media Control (MC) keys, so that the firmware will only send hex 59h without getting translated into Keypad 1 or without sending 53h (NumLock)?

Offline m-ou-se

  • Posts: 2
Re: Truly-Ergonomic’s keycodes remapping
« Reply #151 on: Sat, 07 March 2015, 15:45:45 »
If you're a Linux user: I made a command-line tool that can upload firmware to the keyboard: https://github.com/m-ou-se/teck-programmer

Offline caseyandgina

  • Posts: 54
Re: Truly-Ergonomic’s keycodes remapping
« Reply #152 on: Thu, 02 April 2015, 22:38:24 »
If you're a Linux user: I made a command-line tool that can upload firmware to the keyboard: https://github.com/m-ou-se/teck-programmer

Thank you, it works great!

Offline m-ou-se

  • Posts: 2
Re: Truly-Ergonomic’s keycodes remapping
« Reply #153 on: Thu, 16 April 2015, 12:58:08 »
If you're a Linux user: I made a command-line tool that can upload firmware to the keyboard: https://github.com/m-ou-se/teck-programmer

It also works on Mac now.

Offline caseyandgina

  • Posts: 54
Re: Truly-Ergonomic’s keycodes remapping
« Reply #154 on: Mon, 20 April 2015, 11:51:26 »
If you're a Linux user: I made a command-line tool that can upload firmware to the keyboard: https://github.com/m-ou-se/teck-programmer

It also works on Mac now.

So it does, awesome!  I am going to have to seriously consider using Node.JS for my own scripting...

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #155 on: Sun, 10 July 2016, 08:12:43 »
I've spent some time working on the 8051 source files that Yuri provided, and have implemented the changes I really wanted:
* default modifiers for each layer, so you can (eg) put punctation symbols in the fn layer without needing to press shift as well.
* and a non-locking access to the num layer, so it can be used like the function layer (no numlock).

To use it (at your own risk, of course!!),
* edit the file 229_keymap.a51 to map your keys and modifiers
* assemble to hex using ASEM51 (I included the windows executable as its very small):
      >asemw main
* burn to keyboard as usual

I've only just finished, so it may contain bugs still. Please let me know if you find any. I've never had to hard-reset my TE keyboard, so it should be safe from that angle.
« Last Edit: Sun, 10 July 2016, 19:27:32 by pw »

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #156 on: Sun, 10 July 2016, 22:25:02 »
And now the bad news, I've just bricked my keyboard :-(.

This morning, in a relaxed frame of mind I set about actually creating a map for myself.
Without thinking to much, I 'cleaned up' a few lines in main.a51, which was open in the editor.

I moved a code file to the top, and trashed the interrupt vectors.
So I wont be doing any more on this unless I decide to buy another TE. Arghh!

Offline Darkshado

  • Posts: 79
  • Location: Montréal
Re: Truly-Ergonomic’s keycodes remapping
« Reply #157 on: Mon, 11 July 2016, 00:53:28 »
Are there some provisions for in-circuit programming on that thing?

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #158 on: Mon, 11 July 2016, 01:23:59 »
Whew, I'm back in business! Id assumed that the hard reset relied at least on the interrupt vectors, but it loads a bootstrap ISP code from a different portion of ROM altogether, untouched by usual ISP. Lucky me.

To clarify the instructions given in previous posts, and on the TE site the hard reset/ISP requires:
1) Dip switch 5 in PROTECTED mode through all steps (ie NOT in the usual posn for ISP)
2) Plug in and keep in the USB port (it doesnt flash a bootstrap to the main ROM, it just waits for reprogramming)
3) Short the Reset pin to Vdda described by TE support or the posts above.
4) Burn firmware as usual, but KEEPING DS5 in the protected position.


« Last Edit: Mon, 11 July 2016, 02:29:00 by pw »

Offline zorglups

  • Posts: 25
Re: Truly-Ergonomic’s keycodes remapping
« Reply #159 on: Tue, 17 January 2017, 20:40:45 »
Dear pw,

Having a non locking numlock would be awesome for me.
My keyboard is a TECK 209 (instead of a 229).

What should I change before compiling it?

Does your code make the _TENUM not locking by default or should this be configured somehow?

Thanks.

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #160 on: Wed, 18 January 2017, 18:34:05 »
I have not touched this for quite a while, but from memory:

* Yes I believe I made _TENUM non-locking by default.
* I don't believe there was any intrinsic difference for the 209, other than that the obvious one that the keyboard mapping itself is different. I think there were a couple of differences beyond the extra keys of the 229, too. So if you want the standard 209 mapping, you need to carefully check the differences, and carefully create another mapping in tabular format like the 229_keymap.a51. I think the remapper javascript code made the differences most apparent, or you could check the default key maps side-by-side on the TE remapper tool. But I think you could burn the 229 map as-is to your 209 just to test it's going to work for you, then modify progressively.



Offline zorglups

  • Posts: 25
Re: Truly-Ergonomic’s keycodes remapping
« Reply #161 on: Thu, 19 January 2017, 08:41:23 »
Thanks. I may give it a try.
I was afraid to screw up my TECK by uploading the wrong firmware on it.

I thought that the only difference between the 209 and 229 was that the 209 was featuring Cherry switches.
I'll check it carefully with the configurator.

Have a nice day.

Offline SnowBoy

  • Posts: 1
  • Location: Austria
Re: Truly-Ergonomic’s keycodes remapping
« Reply #162 on: Mon, 16 October 2017, 00:36:41 »
Hi!

I've took the hacked firmware from 'pw' and tried to use it for my needs.
For who will need this, and if it's not clear, there're several layers in the 229_keymap.a51. For each of them 'pw' made a main layer and a mod layer, that contains the modifier keys that will be sent together with the key pressed in the main layer.
So, given the two layers PCTOP and PCTOPMOD, if I want to send just the key for the number 2 I would write _2 in PCTOP; if instead I want to send the @, that's 2 with shift, I would write _2 in PCTOP and 0010B in PCTOPMOD for the same row of the key that I want to modify. The organization of the keys is obvious, every row of keys of the Tek is grouped in a contiguous block.
The modifier keys, when used in the *MOD layer are:
 - 0001B for CTRL
 - 0010B for SHIFT
 - 0100B for ALT
 - 1000B for GUI
This are NOT the same codes that the keyboard uses for the mod keys, because the way they work I suppose it's different.

At the end, for my needs (don't have to press the shift key in the Fn layer to send special keys) this hack works.
Thanks PW.

Offline pw

  • Posts: 21
Re: Truly-Ergonomic’s keycodes remapping
« Reply #163 on: Thu, 03 October 2019, 21:35:56 »

This may be too late to be of interest, but I have recently put together a start on C firmware for the TEK using SDCC. This uses usb code from the Megawin development kit, and a version of their EasyPod library (which they kindly provided me upon request!) which provides the code for device firmware upgrade. It has basic layers and another feature I wanted, dual-function combination keys. But it does not have working media keys, mac/PC layers, or even lights as yet. Ill probably do a bit more over the next week or two, but it would be great if others could provide more.

See https://github.com/Paul-Wray/tek

 

Offline clickclack123

  • Posts: 357
  • Location: Australia, Mate!
Re: Truly-Ergonomic’s keycodes remapping
« Reply #164 on: Tue, 08 March 2022, 17:45:37 »
I really want to have a key to minimize the current window in Windows 10, using Fn+a keypress.

I've tried the "AC Minimize" key from "Application Control - Window" in Yuri Khan's configurator https://yurikhan.github.io/teck/, but the key doesn't seem to do anything.

At work I use a TECK, but unfortunately I can't install ahk or autoit.

On my mouse I have a macro for Alt-Space then N, but I don't see a way to set a macro like this on the TECK.

Anyone have any ideas how I can have a single key to minimize the current window?