Author Topic: Truly-Ergonomicís keycodes remapping  (Read 13995 times)

0 Members and 1 Guest are viewing this topic.

Offline addwyn

  • Thread Starter
  • Posts: 25
  • 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: 25
  • 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: 6
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: 25
  • 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: 3
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: 87
  • 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 | TECK 209 (browns) | ErgoDox (clears) | TouchStream ST
Logitech Cordless Optical Trackman
Current Dvorak-based ErgoDox layout | Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 87
  • 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 | TECK 209 (browns) | ErgoDox (clears) | TouchStream ST
Logitech Cordless Optical Trackman
Current Dvorak-based ErgoDox layout | Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 87
  • 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 36 times.)

This one is for the v3 firmware with the control/shift swap:
* TrulyErgonomic_209CS_Keycodes_v3.ods (15.48 kB - downloaded 32 times.)
Dvorak | TECK 209 (browns) | ErgoDox (clears) | TouchStream ST
Logitech Cordless Optical Trackman
Current Dvorak-based ErgoDox layout | Current Dvorak-based TECK layout

Offline nomaded

  • Posts: 87
  • 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 24 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 | TECK 209 (browns) | ErgoDox (clears) | TouchStream ST
Logitech Cordless Optical Trackman
Current Dvorak-based ErgoDox layout | Current Dvorak-based TECK layout

Offline xiso

  • Posts: 7
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: 25
  • 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: 25
  • 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: 7
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: 87
  • 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 | TECK 209 (browns) | ErgoDox (clears) | TouchStream ST
Logitech Cordless Optical Trackman
Current Dvorak-based ErgoDox layout | Current Dvorak-based TECK layout

Offline Yuri Khan

  • Posts: 25
  • 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 #47E8E9EAÖF7F8F9FAother
out #48010101Ö0102020201
out #49010203Ö1010111200

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: 25
  • 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: 22
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: 25
  • 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: 25
  • 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: 25
  • 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: 25
  • 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)