My custom ergonomic Suka-style

[Ray]

Hi everyone, this is me unlurking

Firstly, a big thank you to Suka for the thread http://deskthority.net/workshop-f7/my-d ... t2534.html, which was inpiring me. Also thanks to Hasu for the firmware which made at least one step in the process go fast.

Secondly, pics, since I heard they say over 9000 words.

wiring of left half

links_matrix.jpg (226.25 KiB) Viewed 5911 times

As you can see, I am too ghetto for having a shop make a lasercut for me. For a rev2 I would definately change that, since it took a LOT of time (like 3-4 hours for each half) and I had to superglue some of the switches. Also it is time for a minor thanks for Matteo for his guides with nice pics of how to wire stuff.

wiring of right half

rechts_matrix.jpg (219.85 KiB) Viewed 5911 times

On this one I didn't cut the sheet of aluminium up front and decided to bend it into a makeshift "case". The white stuff for the feet is Oogoo - not the best choice since it does not stick and the keyboard keeps sliding under my hands.

front view

front_view.jpg (132.68 KiB) Viewed 5911 times

The Handrest on the right was not a planned feature but may actually stay, haven't decided on that one yet.
I also bent the thumbkeys on the left after setting everything up, after I recognised the right half was way more comfortable. That's a benefit of the not-lasercut plate - I don't care if it turns out ugly, since it started ugly. But I managed to break the plate holding one switch, so the switch on the right to Alt is epoxied in.

left half

left_half.jpg (184.86 KiB) Viewed 5911 times

The legends on the keys are true except for the tab being left of Q, and left to Shift is backspace, but the feel of the lying numberrow is good. The inverted Shift on the right is FN1 for Arrows and special characters. Also doubles as Esc on tap.

right half

right_half.jpg (178.76 KiB) Viewed 5911 times

The lying 9 is FN2 for Numpad. Also Paus was used first for entering bootloader on the teensy until I changed it to Bspc. Now that key is not used at all.
I tried another switch in that hole, but I just move everything when trying to press it. And it would be the only key in a new row or column, so it got removed.
That piece of aluminum standing on the left will be bent down after teensy and trackpoint (more on that following) have their final places.

Is it ergonomic?
Well, I am not at all used to mechanical keys. If I did this again, i would not use MX-blacks again (bought a cheep donor on Ebay). Probably reds or maybe browns. Or try Mattias switches first.
I am so used to type on my laptop pc where my palms removed the paint years ago, that I will probalby need a palmrest at about 3cm height for this thing. Also for now, this thing moves to the back when I type, especially on thumbkeys. Something has to be done about that one, since it makes me "foxdevilswild" - here you go, I am german.
Also the non-staggered design is a little problem for my left hand. On the right hand side it works out super intuitively since I turn the halves a little bit and the layout on the right is pretty close to a normal stagger. On the left it isn't. But I blame the stupid normal stagger for the left hand. I always type 'c' with my indexfinger and don't use the middle finger on bottom row at all. Now that becomes a problem, since the indexfinger doesn't reach that key easily. So I guess i learn to touchtype properly, but for now it makes me type horribly slow.
Also I'm not used to the thumbkeys. When you have to think about every shift or backspace, typing becomes the speed of a snail.


What comes next: I really want an integrated trackpoint on this thing. Probably below z and u, Suka-style as well. So I got an used Thinkpad keyboard and scrapped the touchpad. Turns out it is one of these: https://geekhack.org/index.php?topic=8971.0 and I found no answer to that question.

crappy pic of the trackpoint controller

tp_controller.jpg (44.62 KiB) Viewed 5905 times

I hoped it is this pinout, since pin 4 (or 7 if you count from other side) has a lot of connections on the pcb.

Code: Select all

Board pinout    TPM754            
---------------------------------  
1   RST         RST(5)            
2   EX.DATA     RXD(1)            
3   TP_DATA     TXD(2)            
4   VCC                            
5   TP_CLK      INT0(24)          
6   EX.CKL      INT1(4)            
7   GND                            
8   BUTTON0     P3.0(25)            
9   BUTTON1     P3.1(26)          
10  BUTTON2     P3.2(27)

Guessed it to be GND, and yesterday wired everything up, compiled the onekey-firmware, flashed it - nothing. Except I noticed it was generating heat. The amount of heat that is not good for small ICs...
So I unplugged it and called it a day. Today I tried it again, what if that pin was Vcc, give it a shot.
But this time I was prepared - kinda. So instead of wiring everything up up front I start with Vcc and GND and add stuff later. And check the current on Vcc through my multimeter. It beeps, showing zero current. This is me using it for current the first time. So... going up from mA to A? I try that and measure a whopping 1.2A (or something along it) and think to myself "wow, it doesn't turn hot... oh it does, crap!" and unplug it. If that 1A did flow yesterday all the time when I uploaded the firmware and tested the trackpoint, it is probably fried, but I give it another go, switching Vcc and GND once again. Measure 34mA which is higher than I would guess the TP would need but not frying the chip at least. So I add stuff and try to find out where it went wrong yesterday. Adding all up still means 34mA and a non-functioning trackpoint.

What's your guess on it? Did I fry it?
Anyone got such a trackpoint to work? Mine is from a E520.

[Dilettant]

This looks very inspiring! Makes me want to make progress with a not so unsimilar project.

Concerning the trackpoint: I tested a trackpoint from a ThinkPad T30 donor by directly connecting it to a PS/2 cable, which worked. There might be fewer sources of error in such a simplified setup compared to one using a Teensy (that is, if you have access to a computer with a PS/2 port). I assume that the pins to connect are 3 (data), 4 (Vcc), 5 (clock), and 7 (ground).

I bought a batch of old ThinkPad keyboards because I expect I'll ruin some of them when experimenting. If your trackpoint is indeed fried, I could ship you, say, two, for a few Euros within Germany.

[scottc]

Seems like a cool project. Very good content for your unlurkening!

I need to get my hands on a few trackpoints for some upcoming projects too. My HyperMicro and qHACK will need some for sure...

[Ray]

Thank you. Right now I have no machine around with native PS/2.

Sadly I am sick in bed this weekend, but my next step is connecting the Trackpoint and Teensy to a breadboard, where I can make connections faster and get access with the multimeter more easily.
After that I might come back to your offer Dilettant.

[Ray]

well, I don't know anymore. The trackpoint doesn't seem to be dead, it has signs of life. But I cannot make it move my curser...

Equipped with only a breadboard and an multimeter I figured I can get something out of TP_CLK what seems to be a ~30% to 50% (varied when I tried reproducing) duty cycle signal (i.e. pulled low to 2.5 - 3.x V on my DMM) for several seconds so I can measure it.
But I am not able to measure anything on TP_DATA. For one, the teensy pulls the data-line low constantly after about 1 to 2 seconds after I plug it in. And if I disconnect the data-line between teens and the trackpoint, the trackpoint does not pull it down (in a way I can register).

And the teensy has problems with registering keypresses on that one key the onekey-firmware can see. I have to press it down for longer than just a regular tap (but still less than a second) for it to register that keypress. This is true for most cases, like the connections done that I guess are correct - or the data and clk lines from the teensy not connected to the trackpoint. But for some cases, like connecting data and clk on the teensy to each other (stupid case but an example), that key registers just fine.

So yes, I was trying to debug something when I don't know if the hardware is broken, I am not 100% shure about the pinouts of that hardware, with not the tools to do anything precisely... I am at a point where I think I am wasting my time.

I only have one idea, that might be worth following: what if my firmware does not send the signals over USB. All I did to the onekey-firmware was to adjust the pins to that one key and uncomment the ps/2-mouse and usart lines in the makefile; and changed the bootloader size to 512 for teensy in the makefile.
data is soldered to D2, clk to D5, the resistors and the elko-cap are soldered fine as well.
That should be all I need for a regular trackpoint to work, isn't it?

[eldorange]

This looks way better than ergodox when finished.

[Ray]

thanks eldorange. But it is like comparing apples to pears. The Ergodox has not only different thumbkeys, but another row above the alphas. It is 66 keys (if I count correctly) against my 48. But thanks again, I need some positive words right now

[scottc]

If you're finding the MX Black switches fatiguing, you could consider simply buying replacement springs for them. For something like 10 euro, you can get lighter springs that make the MX black switches feel more like MX reds.

[Ray]

thanks for the idea scott, but I am afraid I will have a hard time now opening the switches. Most of them don't have the extra space needed on the mounting plate. And if I press them a bit out of the mounting plate I would have to worry about the solderpoints and re-glue some of them again...

But this reminds me that Q and I think B were sticky at some point, and I don't know why.
On another note: Ctrl and an Fn-key were both bridged in the beginning due to bad wireing. Really had a hard time figuring out what was wrong. For a first matrix-test I would advice not implementing any modifier-keys

[scottc]

Ah, I didn't think of them being glued in. That'd be a bit of a pain then. It might be worth considering if you make another in the future, at least!

[Ray]

okay, got a pm-reply from hasu. His advice was to find out my pinout first...
So, I tried the multimeter in beep-mode again. And guess what: I found another trace is connected multiple times to the MCU. I really don't know how I could miss that one before. I just don't...

so most importantly: IT IS ALIVE!
I got the pinout pretty fast, because of my setup with easy access (hm, easy access so sexy). Here's it is:

1. not connected
2. not connected
3. Vcc
4. Gnd
5. TP_CLK
6. dunno
7. dunno
8. dunno
9. probably reset
10. TP_DATA

So it really isn't one of the two usual pinouts.
But now in my enthusiasm I broke the connection of TP_DATA and I call it a day.

[Ray]

Here is a pic where I try to figure out which key is doing what.

breadboard_skills.jpg (159.03 KiB) Viewed 5512 times

turns out, the pinout of the trackpoint is indeed what I had said in the last post, and I found on geekhack an identical one, which I didn't take into consideration, because it only had 8 pins... when mine had 10 with 2 of them not connected. The remaining three are probably mousebuttons, but I don't care about mousebuttons on the trackpoint.

The thinnest wire I had lying around, was from an old el cheapo pair of earphones, so I used that to solder to the small connections on the trackpoint.

my soldering and mounting skills.

hinten_trackpoint.jpg (280.93 KiB) Viewed 5512 times

The insulating tape is partly for insulation, strain relief and tidying stuff up a little.
That pin is epoxied to the normal red rubber cap, not to the plastic itself. Minimal movement of the pinhead results in tremendous mousemovement, I will probably change that in software.
I epoxied three 1cm metal standoffs to the plate, to which I nutted the module. Apart from epoxying in some more switches, this looks quite pro.

rechts_mit_tp.jpg (123.04 KiB) Viewed 5512 times

I am typing on this right now, and sometimes I accidentally touch the pin, which - due to my miserable hacking skills - activates another layer with k,l and i as mousebuttons. If I then hit 'i', linux pastes from the clipboard which becomes a real mess.
I did have it work with drag and drop at some point, but my auto-layer hack did break that hack. If only hasu's code was better documented, would make my progress faster and cleaner...

[wlhlm]

I am typing on this right now, and sometimes I accidentally touch the pin, which - due to my miserable hacking skills - activates another layer with k,l and i as mousebuttons.

That is a clever idea.

Maybe it'll work better if you delay the layer activation. Let's say you hit the trackpoint and it activates a timer (500ms for example). After it ran down you check again if the trackpoint is still in use and then you activate the layer.

[suka]

I am typing on this right now, and sometimes I accidentally touch the pin, which - due to my miserable hacking skills - activates another layer with k,l and i as mousebuttons.

That is a clever idea.

Maybe it'll work better if you delay the layer activation. Let's say you hit the trackpoint and it activates a timer (500ms for example). After it ran down you check again if the trackpoint is still in use and then you activate the layer.

I did it the other way round: any trackpoint event activates the layer with mouse button mappings. while any of these are pressed the timeout to return to normal is reset continuously. If it times out after 1s or any non-mousebutton key is pressed the normal layer is activated again.

[Ray]

did that both for hasu's firmware, and most of it is clean enough to share:
action.c

Code: Select all

...
/* Key and Mods */
        case ACT_LMODS:
        case ACT_RMODS:
            {
                uint8_t mods = (action.kind.id == ACT_LMODS) ?  action.key.mods :
                                                                action.key.mods<<4;
                if (event.pressed) {
                    if (mods) {
                        add_weak_mods(mods);
                        send_keyboard_report();
                    } else {
                        layer_off(MOUSE_LAYER);
                    }
                    register_code(action.key.code);
                } else {

...

#ifdef MOUSEKEY_ENABLE
        /* Mouse key */
        /*case ACT_MOUSEKEY:
            if (event.pressed) {
                mousekey_on(action.key.code);
                mousekey_send();
            } else {
                mousekey_off(action.key.code);
                mousekey_send();
            }
            break;*/
        case ACT_MOUSEKEY:
            if (event.pressed) {
                switch (action.key.code)
                {
                    case KC_MS_BTN1:
                        /* tp_buttons is global variable and processed in
                         * ps2_mouse.c */
                        tp_buttons |= (1<<PS2_MOUSE_BTN_LEFT);
                        break;
                    case KC_MS_BTN2:
                        tp_buttons |= (1<<PS2_MOUSE_BTN_RIGHT);
                        break;
                    case KC_MS_BTN3:
                        tp_buttons |= (1<<PS2_MOUSE_BTN_MIDDLE);
                        break;
                    default:
                        mousekey_on(action.key.code);
                        mousekey_send();
                }
            } else {
                switch (action.key.code)
                {
                    case KC_MS_BTN1:
                        tp_buttons &= ~(1<<PS2_MOUSE_BTN_LEFT);
                        break;
                    case KC_MS_BTN2:
                        tp_buttons &= ~(1<<PS2_MOUSE_BTN_RIGHT);
                        break;
                    case KC_MS_BTN3:
                        tp_buttons &= ~(1<<PS2_MOUSE_BTN_MIDDLE);
                        break;
                    default:
                        mousekey_off(action.key.code);
                        mousekey_send();
                }
            }
            break;
#endif

...

ps2_mouse.c

Code: Select all

...
void ps2_mouse_task(void)
{
    static uint16_t mouse_layer_timer = 1;
    typedef enum {ML_UNSET, ML_STARTUP, ML_SET} mlh_t;
    static mlh_t  mouse_layer_helper = ML_UNSET;
...
    if (rcv == PS2_ACK) {
        mouse_report.buttons = ps2_host_recv_response();
        mouse_report.x = ps2_host_recv_response();
        mouse_report.y = ps2_host_recv_response();
        mouse_report.buttons |= tp_buttons;
    } else {
...
    /*if trackpad is moved or buttons are pressed, for auto-layer-switching*/
    if (mouse_report.x || mouse_report.y ||
            (mouse_report.buttons & PS2_MOUSE_BTN_MASK)) {
        switch (mouse_layer_helper){
            /* if mouselayer not set and trackpoint movement */
            case ML_UNSET:
                mouse_layer_timer = timer_read();
                mouse_layer_helper = ML_STARTUP;
                break;

            /* during startup phase */
            case ML_STARTUP:
                /* if xxxms passed (with tp movement), turn on mouselayer */
                if(TIMER_DIFF_16(timer_read(), mouse_layer_timer) >150){
                    layer_on(MOUSE_LAYER);
                    mouse_layer_helper = ML_SET;
                    mouse_layer_timer = timer_read();
                }
                break;

            /* if mouselayer already set, just update timer */
            case ML_SET:
                mouse_layer_timer = timer_read();
                break;
        }
    }

    /* reset mouse layer when unused
     * when startup time exceeds */
    if (mouse_layer_helper == ML_STARTUP &&
            (TIMER_DIFF_16(timer_read(), mouse_layer_timer) > 200)){
        mouse_layer_helper = ML_UNSET;
    }
    /* when mouselayer is on, but no mouseactions done for some time */
    if (mouse_layer_helper == ML_SET &&
            (TIMER_DIFF_16(timer_read(), mouse_layer_timer) > 800)){
        mouse_layer_helper = ML_UNSET;
        layer_off(MOUSE_LAYER);
    }
...

some of the code (the hacky implemented one with global variable) is stolen from https://geekhack.org/index.php?topic=50176.30

[jonlorusso]

and most of it is clean enough to share

thank you!!!

[Dilettant]

To all you trackpoint hackers: What do you think about assembling a list of known trackpoint controller types and their pinouts on the Wiki? I destroyed one from a T30, which matched the first one linked in this geekhack post, and I could successfully test it without substantial problems. Now I have two other types (one might be from an X31, one from an R60). So far, I didn't find photographs and pinouts of any of those two.

If we could assemble a list of verified pinouts, not everybody would have to go through the same painful steps to figure out the pinout of an unknown controller. Certainly, logical deduction, a multimeter and systematic tries can get you there (if the systematic tries don't fry the controller), but it's still tedious and error prone.

Any supporters of that idea out there?

[Ray]

That's a good idea, I myself would have liked to have that. That said, I am not much in the mood of setting up a new wiki-page, where one should think about how to sort the trackpoints (pinouts, controller's used, devices scavenged of or something else).
But I would definately support it as far as adding the trackpoint I used, if someone else does the setting up.

[Ray]

Here's an update to the hardware after I finished the case.
After adding the rubber feet it became quite comfortable typing on. But not without a ~4cm handrest.

Still working on the firmware, though, i.e. if i get the muse to do so.