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

0 Members and 1 Guest 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 915 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 670 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 723 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 591 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...