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

0 Members and 1 Guest are viewing this topic.

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