kinx-project / kint Goto Github PK

I've been using the set_single_persistent_default_layer function to switch base layers but the changes aren't persisted to EEPROM. I've also wired up a small LED strip and my understanding is that changes to RGB lights are persisted to EEPROM by QMK, but that's not working either. I believe QMK doesn't understand how to use the Teensy 3.6's EEPROM.

I have a KB500USB (I guess I have a non-USB one in storage).

The PCB's for the thumbs are connected directly to the board. Is it possible to cut them and connect to the molex connectors on the kinT board?

This is my first project. So apologies for the noob questions:

I picked up the Teeny 4.1 with headers: https://www.digikey.com/en/products/detail/sparkfun-electronics/DEV-16996/13158152

Is this going to be a problem? should I have ordered it without?

I've had a close look at the k500, I think I can probably unsolder the directly soldered connections for the thumb keys. You've kindly provided pin headers on your board, but is there some nice way to have a connector, not directly solder things together?
Thanks for any help with these questions ;)

Aisler recently introduced a new, cheaper tier: https://aisler.net/blog/introducing-budget-manufacturing-the-most-economic-choice-on-the-planet

Our current artifacts (v2020-06-30) show up on the aisler web interface as “complex”, which makes it not qualify for this new, cheap tier:

See https://aisler.net/help/design-rules-and-specifications/design-rules for aisler’s design rules.

AFAICT, we fulfill 2 of 4 criterions: our minimal drill diameter is 0.4mm, and we have 2 layers.

Is the problem plated slots? The milling tool size? Something else entirely?

If we can, it would be nice to make our design qualify as a simple design.

Hi,

first of all thank you very much for your great work and support on the kint project.

I have two kinesis advantages 2 and have built three kint pcbs in total. Two of them with Teensy 4.1.
My advantage with the cherry mx quiet red switches works totally fine and I could develop a bone like layout (close to neo) for it.

But when I use the same firmware build on my second advantage with cherry browns, I get a weird behavior when typing mostly on my pinkies and ring fingers.

1 out of 10 I see two key inputs with a single key press. Seems to be related to the 'bump' of the tactile switches.

Is there a way to increase the debounce time? Or is there another way to fix this?
This behavior is really disturbing, but I cannot use the native kinesis controller with the bone layout.

greetings
Tim

Whats the possibility of a slightly more complicated board (may require a multiplexer) with bluetooth support and lipo charging through the usb port? The adafruit feather has a nice through port lipo charging feature (though I think I did a pincount on the feather w/ bluetooth and found that a multiplexer would be required.

Other features that would be awesome, support of the built in LED windows, maybe with rgb leds.

As an aside, I'm super happy to see this rev to the old stapleberg board, I've got two modded advantage 1s and they make me very happy.

I've soldered the resistors and LEDs in as follows, caps-lock does light the led in a second attached keyboard, but not in the one I built:
The SMD LEDs have a small bar on the back, I oriented that in the same direction as the bar of the diode symbol is on the silkscreen.
Is there a way to light up all the LEDs, for testing? How would I best debug this?

Very cool project, I'm looking forward to building at least 2-3 of these, I've been thinking about doing this for some time, but couldn't have managed as well as you did!

Do you have a good solution on how to use the original USB cable that comes with the keyboard, and connect it to the teensy internally? I have a couple of old Kinesis Advantage (1), it seems that the USB cable goes to a brown connector internally, could I somehow "forward" those wires into a micro-USB plug and plug that into the teensy?

Thanks for any help with this, I hope I didn't overlook an existing answer to this :-/

I've been using a kint with a teensy 3.6 on an Advantage 500 for a few years now (pretty much starting a few months after you made this available) and haven't had any issues till today. Out of nowhere, the keyboard has started randomly inputting characters. The problem seems isolated to roughly the top half of the keyboard based on the characters I see appear, so it's the function row, numbers row and QWERTY row, both halves.

I opened it up and blew away any dirt/crumbs that had accumulated, but that didn't fix it. My soldering work from back then wasn't perfect, but I don't see any bridged pins. Any ideas what might be causing this? Could the controller just be dying?

See e.g. https://twitter.com/kinesisergo/status/1397335511694381058?s=21

That keyboard is not yet released, but I’m filing this issue anyway so that people can contribute details or subscribe for status updates

Not an issue as such! Just a couple of questions!
If they are inappropriate here please tell where else to look for answers.

1. Is there a way/are there plans to teach kint make "clicks" on key presses? I noticed when the sound was off I almost never bottomed out. I miss that.
2. One of my Kinesis Contoured keyboards had 5 extra buttons (I simply drilled holes and added buttons). Is it possible to pull the same trick here?

Intro

Thanks for your amazing work on this project!

My background: I'm using a kinesis Advantage 2 (KB600-SE), and I have previously built a Dactyl-ManuForm with arduino + QMK, but beyond that I don't have any electrical engineering experience and thus zero kicad/pcb work, thus my following questions below.

1. USB hub?

The only function I miss in my Kinesis 2, is a USB-hub (ports both for internal and external use), so I'd be very interested in how/if there is any possibility to add that to the kinT?

I know you experimented with this a few years ago, for the older board (kinx) you were working on then. I think you came to the conclusion that the sum of connected USB-devices must be below 500 mA. Would that still be a limiting factor if it were to be re-implemented on this board? Is there space on the board for it?

2. Speaker?

The factory board comes with a piezo buzzer, to give audio feedback, possibly to make up for the switches not being clicky, I guess. I find I actually use it now that we're all working from home (thus not disturbing my colleagues), I also used it when learning to touch type when I was new to the kinesis. Are there any free pins on the teensy for adding this, and could the traces be added for this on the board?

3. Github discussion?

I saw github recently launched a discussion page, which can be enabled, if you prefer to keep issue tracker devoted to only bugs/issues, and discussions/forum type posts elsewhere

Conclusion

I'm half itching to make this board (for QMK and green LEDs > blue LEDs!), but I want to hear your thoughts on my questions above, if you have time to answer them.

Cheers!

Hi Michael,

First off, thanks so much for this project - as a beginner it has been a lot of fun to experiment and mess around with.

I recently compiled some changes to my configuration using the QMK configurator, but when I attempt to flash the firmware onto my keyboard my keyboard becomes unresponsive. The orange LED on the teensy does not light up, and the 4 blue keyboard LEDs stay permanently lit. The teensy loader does not seem to indicate any issue (neither does the verbose logging).

I suspect that this is an issue with the QMK software and how it is compiling the firmware, but to be honest, I'm not sure where to begin in diagnosing this problem. It's worth mentioning that I have tested this using the web UI for QMK configurator, as well as the qmk cli tool on both Mac and Windows (same behavior across interface/platform).

For what it's worth, the pre-built tested firmware that you have linked on the readme here works fine, but the QMK Configurator link you have listed in the same table does not work for me anymore (it did previously).

I'm happy to create an issue on the QMK repo, but I'd appreciate some insight or direction on how I can dive in to this more.

Thanks!

I'm setting up KinT with a Kinesis Advantage 2 and a Teensy 3.6. I soldered everything and flashed the Teensy with this hex file.

When I plug everything in, the LEDs go on as expected, but keys are clearly malfunctioning: some keys aren't registering at all and some are registering as other keys or groups of keys (I'm using qmk configurator to test keypresses).

Any ideas on how to best to debug? I didn't do the best job soldering, but I'm not sure how to determine whether it's something there or software issue.

Hello ;)
Just finished building one (kb500 with kint36). I left the thumb pads disconnected, but connected everything else, cloned your firmware branch, flashed it. The keyboard shows up, however pressing any button does nothing at all. Is there some way to debug this?
[working on arch linux, everything current. avr-gcc is 10 (which qmk warns about), but I don't think I have an older one to install :-/]
The device itself shows up fine in xinput and dmesg.
Thanks for any help!

Description

I put together a Teensy 4.1 kinT keyboard controller a few months ago and it has been working amazingly up until this morning. The keys don't all work correctly any more, some seem to work for a while and then just stop, sometimes random strings are outputted and sometimes space or a key is held so it outputs something like "tttttttttttt" continuously. It seems to have gotten worse over the course of the day in the sense that no key presses seem to work correctly any more.

I last flashed the firmware about 2 months ago and I don't move the keyboard around, so there hasn't been any physical knocks or anything.

Debugging

1. I flashed the board hoping the qmk firmware somehow degraded over night, that didn't work.
2. I flashed with the standard stapelberg keymap, thinking maybe my map was somehow corrupt and qmk wasn't picking it up, that didn't work.
3. I made sure the physical connections on the board were all tight and nothing had somehow become a bit loose. Everything was fitted correctly and nothing changed when I tried to use the board again.

I'm not sure what else to try? Have you heard of an issue like this before? Do you have any suggestions?

I am a current user of the KB600 + foot pedal. Foot pedal helps me avoid typing chords, so it includes layer switch, shift and control.

I would be very interested in teaming up to implement support for this. I can see in Issue #9 that the foot pedal connector comes out with the standard plug / original USB cable and is well labelled there.

In an ideal world, I would love some help to modify the PCB so that:

• It includes a plug to re-use the original cable
• exposes pins so one can craft a small microUSB cable (or other option) for the Teensy
• takes the pins from the foot pedal switch (currently 4 = ground+1 per switch) and aggregates them with diodes so that only two pins of the teensy are needed.
• connect those two pins to the teensy so they can be used as normal keys within QMK.

Notes:

• I don't have a KB500 to see how the inside/plug is setup
• I don't necessarily need the three switches, but at least one would help a lot.
• A foot pedal is very easy to build using an easily available electric piano pedal (<10 bucks online) a 6.3mm female plug + RJ11 plug.
• I am planning to use a Teensy 4.1, so can happily use the extra pins and avoid disrupting the current pinout.

Ideas and feedback welcomed.

Hi,

thanks for your work, i would love the Idea to have qmk running on my Kinesis ADV 500.

I was following your guides for set up the Teensy 4.1 as straight as possible.
Now I see me in a similar situation as landakram in issue 16
COL_3 troubles me, it is so hard that the Teensy is sometimes reset and I have to flash it again. It prints out 1000nds of characters.

I was thinking, "ok, lets check the connections", I used an USB Power Brick, so no OS driver in charge and hooked up my Ozi

I check "20" and G,

• it shows no difference if any key is connected or not, a straight line for 3V. Which is OK for me.
• it doesnt care if i press the upper 2 character lines, great.
• If a press keys in the bottom row (z-v;n-?) it shows this behavior: A sign of the matrix scan I assume?
  
• Buf if I press "b" it locks like this, which looks not ok:
  

Any advice how to proceed? Any other measurements you suggest?

I'm doing a custom keyboard and I'd like to use QMK with a Teensy 3.6. This config seems to be real close to what I need, but I'm a little confused on the pin mapping.

/kinesis/kint36/config.h has the following lines:

#define MATRIX_ROW_PINS { D3, C3, C4, C6, D2, B0, D7, A12, A13, B17, B16, D0, B1, C2, D6 }
#define MATRIX_COL_PINS { B3, D1, C0, D5, C1, B2, D4 }

These don't really make any sense to me in the context of a Teensy 3.6 or with the pins that are wired out on the kinT board itself (eg ROW_0 is tied to Teensy pin 0, which for a 3.6 is PTB16).

Sorry if this is more of a QMK-specific question, but I'm new to all this and it's proving to be an absolute jungle.

I use the default keymap and kinesis/kint36 keyboard of the upstream qmk firmware.

The keyboard works fine until I press caps lock, scroll lock or num lock.
The LEDs light up, but there are no more key inputs possible. The keyboard is unresponsive.

I need to deactivate all locks with a 2nd keyboard and need unplug + reconnect the keyboard, to make it work again.

If I replug with an active lock state, it will not work.

Hey!

Both my kint41 and my kint36 do not work properly with the recent windows 10 update (weather thingy in the task bar).
I noticed following issues:

• keyboard detection failed from time to time
• input is delayed/laggy
• 'fast' typing results in spamming the same key endlessly. Keyboard is freezed and needs to be re-plugged.

I built them from upstream https://github.com/qmk/qmk_firmware/tree/34de7ca224d613e1ae19a45860e27c15d40254dd.

Current state is unusable in windows. I checked it on two machines. The kints worked fine until the recent windows update.
I have no issues on my linux machine.

Would be nice if you could take a look or check it on a windows machine.
Which information can I provide to help solving this issue?

Greetings!

Hey Michael,
first of all let me thank you for this project. It's amazing! I ordered all parts and the boards and have already build one. What a pleasurable and fun experience - it just works!

However I'd like to set my LEDs manually to create a Knight Rider effect (light scrolls left to right).
Ideally I'd like to have a function that I can all anywhere to turn on (or off) the light of a certain led.
I've found your initialization code inside kint36.c and played around with it, but I just can't turn on manually any of the led lights. Could you guide me a little into the right direction?

As suggested in https://twitter.com/deBaer/status/1387823539273801729

Looks like https://octopart.com/2686-adafruit+industries-68087195?r=sp is the corresponding part.

Changing the layout would make the kint36 and kint41 builds 4.5 USD more expensive, but add LED capability to the kint40.

I wonder if a hybrid layout is possible…

As title says, I'm wondering if there is any technical reason to pick the teensy 3.6 vs 4.1 in terms of performance or functionality?

I want to make my keyboard wireless and battery powered. If there isn't a substantial difference in performance or functionality between the two, I should pick whichever uses less power.

Thanks!

Hello! Thanks for putting this together, I'm building my first kit now. I decided it would be a good resting place for my old Teensy++ 2.0, and thus have a question about docs - is the Kinesis 5V tolerant (or perhaps 5V originally?) I just want to make sure I don't break anything by plugging in an unmodified 5V Teensy++ 2.0, because the only mention of voltage in the README was the LED voltage at 3.3V.

Thanks!

I've recently run into the following problem:

Error: %s: %s ('ImportError', ImportError("cannot import name 'format_ansi' from 'milc' (/usr/lib/python3.9/site-packages/milc/__init__.py)"))
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/qmk_cli/script_qmk.py", line 74, in main
    import qmk.cli  # noqa
  File "/home/nex/qmk_firmware/lib/python/qmk/cli/__init__.py", line 13, in <module>
    from . import doctor
  File "/home/nex/qmk_firmware/lib/python/qmk/cli/doctor.py", line 13, in <module>
    from qmk.questions import yesno
  File "/home/nex/qmk_firmware/lib/python/qmk/questions.py", line 4, in <module>
    from milc import cli, format_ansi
ImportError: cannot import name 'format_ansi' from 'milc' (/usr/lib/python3.9/site-packages/milc/__init__.py)

This seems to be a problem with recent versions of milc, which upstream has fixed. I've not been successful in trying to get the kint36 working by copying things into upstream QMK.

Is there any chance of either updating this fork to current upstream, or even better, getting kint36 merged into QMK proper?

Thanks for any help with this!

I've built the board with a Teensy 4.1 and used the firmware form your qmk_firmware fork (https://github.com/kinx-project/qmk_firmware) and kint41 branch (e2f82ab2dac).
I've used the exact components from the guide.

Mostly stuff seems to work but none of the LEDs do.

I've done some measurements and I'm a bit confused by the results:

• I've got 3.3V on the 3V3_2 pin of the cross row. I also didn't forget to solder it.
• I've got 3.3V on all anodes
• I checked that I have no shorts between the LED Pins 12, 24, 25, 26
• All measurements were done with several ground pins (GND, GND mounting pad, GND 3)
• Can't make the LEDs light up with my multimeter (weirdly shows .0L in forward and reverse bias. I use a Brymen BM257s which IIRC has a 1V range for diode testing which might be the reason). But I can make them all light up with some help from a 3V battery
• Checked the resistors, all measure 10k.

Here's where it becomes strange:

• As said above I can always measure 3.3V on the anode
• But I also can always measure 0.9V on the cathode. Regardless of CAPS_LOCK being on or off for example.
• I can also measure the 0.9V before and after the resistor.
• I also got the 0.9V on the LED Pins 12, 24, 25, 26.
• During those measurements the LED lights up a tiny bit (barely visible)

The rest of the keyboard seems to work fine as I'm typing this issue on it.
The only thing that doesn't work is waking up my mac from sleep with this keyboard, but I'm guessing this is more of a firmware thing.

Any idea what could be wrong?

Status

• milestone: light up LED
• milestone: print debug messages on the serial port
• milestone: light up a LED from ChibiOS
• milestone: print debug messages on the serial port from ChibiOS
• ChibiOS tests are passing successfully!
• milestone: USB stack used successfully from ChibiOS

USB

• the Teensy 4.1 has two USB 2.0 OTG controllers
• I’m trying to make controller USB1 (base address 0x402E0000) work (eval board: the USB port right next to the ethernet port, called “USB OTG” in the documentation, teensy 4.1: the main and only USB port)
• There are 5 different USB implementations I know of:
  1. NXP SDK (usb_device_dci.c)
     • supports KHCI (USB Full Speed)
     • supports EHCI (USB High speed, what the Teensy 4.1 uses)
     • supports LPC USB IP3511 FS
     • supports LPC USB IP3511 HS
  2. Paul Stoffregen’s official Arduino Teensy 4 core (usb.c)
     • Uses the EHCI interface, but also uses the teensy register macros, not NXP’s CMSIS.
  3. ChibiOS-Contrib Kinetis (hal_usb_lld.c)
     • The KINETIS hal_usb_lld.c uses the KHCI interface, which is not available on the Teensy 4.1 anymore.
     • Maybe we need to create a hal_usb_lld.c that uses the EHCI interface.
  4. The stack in libgreat is more readable/descriptive, but not 100% sure about correctness—might be better to prefer the NXP stack for now.
  5. Tamago’s USB stack: https://github.com/f-secure-foundry/tamago/tree/master/soc/imx6/usb

Building

• You need ChibiOS/ChibiOS@3249070 or newer (fixes the interrupt vector table alignment for teensy 4.1)
• My ChibiOS-Contrib WIP branch can be found at https://github.com/stapelberg/ChibiOS-Contrib/commits/teensy41

Wiring/testing

1. Connect a USB-to-serial adapter to teensy 4.1 pins G (GND), 16 (RX) and 17 (TX).
2. Build and flash the ChibiOS-Contrib teensy 4.1 demo:

   cd ChibiOS-Contrib/demos/MIMXRT1062/RT-TEENSY4_1
   make
   teensy-loader-cli -w -v --mcu=TEENSY40 build/ch.hex
   

3. After turning on the teensy 4.1, you should see debug messages on the serial console, followed by the ChibiOS test suites.

See also #16 (comment)

It seems that the Teensy 3.6 version of this controller might behave weirdly on MacOS:

• Some keys are not detected properly (For example the thumb keys for delete, enter, etc.)
• Keys are only activated if another key close to it is pressed (same column?)

Is there somebody who uses the teensy 3.6 variant of this controller with a mac successfully?

I sourced some PCBs from JLC PCB using the zip file in this repository and built the kint today for my KB500 using the Teensy 4.1. I pretested and preflashed the Teensy before assembling the rest of the board. I soldered the LEDs first and pretested again and when I toggled capslock, numlock, scroll lock on my other keyboard the lights on the kint turned on and off so it appeared to be working.

Unfortunately after I had everything re-assembled it did not work. Pressing a key on the left keywell (e.g. Q) would cause random modifier keys to be pressed. I thought it might be an issue with the thumb cluster since I had to hand rewire those for the KB500, so I disconnected it but the issue still persisted. I tried only connecting the top row function keys and qmk tester register the key presses but also registers a bunch of LCTRL, LALT and LOS.

I visually inspected the board and didn't see any issues with soldering but probing with the multimeter I saw that pin 6 on the teensy was shorted with ground. I'm pretty sure this should not be the case, but I am not sure how this is possible. There doesn't appear to be any ground pins near any of the pin 6 connections.

Since col 6 is related to the left thumb cluster this makes me suspect it might be the issue. Do you have any suggestions or tips on how I should try to debug the issue further? Thanks.

QMK’s quantum/audio/driver_chibios_dac_basic.c is tied to the STM32 DAC implementation.

To make audio work on the Teensy 3.6, we’d need to update that file to work with whichever ADC/DAC hardware is available on the MK66F18, which likely also requires a ChibiOS-Contrib contribution.

I have no use for audio so I don’t plan to work on this myself. Contributions welcome!

Not entirely investigated yet, but filing for tracking.

I've modded my Advantage 1 with a Teensy 3.6 and the RESET quantum keycode doesn't seem to work. When I run qmk flash and qmk is at Waiting for Teensy device... (hint: press the reset button), sending the RESET keycode with a keypress doesn't put the board in bootloader mode and I have to press the physical button to allow flashing to proceed.

Hi, I want to emulate the original firmware's keypad behaviour and light the keypad LED when the NUMPAD layer is active.

Sadly, the code below in keymap.c doesn't work:

layer_state_t layer_state_set_user(layer_state_t state) {
  printf("layer_state_set_user running\n");
  switch (get_highest_layer(state)) {
    case NUMPAD:
      writePin(C3, 0);
      break;
    default:
      writePin(C3, 1);
      break;
  }
  return state;
}

The LED doesn't change on layer change, nor is there output in the console.

I even tried putting this into kint2pp.c, as it seems to be missing, but it also changes nothing:

layer_state_t layer_state_set_kb(layer_state_t state) {
    layer_state_set_user(state);
    return state;
}

Any idea what might be wrong here?

Got a report about this issue, haven’t tried to reproduce yet.

Not sure if this is a QMK issue, or specific to the kinT.

If I enable auto shift keys in rules.mk, I get compilation errors:

 | 
 | /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld:rules_memory.ld:285: warning: memory region `flash4' not declared
 | /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld:rules_memory.ld:293: warning: memory region `flash5' not declared
 | /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld:rules_memory.ld:301: warning: memory region `flash6' not declared
 | /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld:rules_memory.ld:310: warning: memory region `flash7' not declared
 | /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libg.a(lib_a-abort.o): in function `abort':
 | abort.c:(.text.abort+0xa): undefined reference to `_exit'
 | /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libg.a(lib_a-signalr.o): in function `_kill_r':
 | signalr.c:(.text._kill_r+0x12): undefined reference to `_kill'
 | /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libg.a(lib_a-signalr.o): in function `_getpid_r':
 | signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
 | collect2: error: ld returned 1 exit status
 | 
make[1]: *** [tmk_core/rules.mk:306: .build/kinesis_kint36_default.elf] Error 1

It seems that auto_shift_keys link in something that might be in error?

Hello @stapelberg,

Thank you publishing this, this actually is such an improvement because the board is actually positioned properly. I've been using a variant of your board and it needs to get soldered in backwards which is so weird (Also wondering if this is why my boards have been dying so frequently. I've lost about 3 of them - they just randomly stop working).

Question: I have an older teensy++ 2.0 and wanted to clarify with you the positioning before I started soldering:

I wanted to know if this was where the teensy++ should sit. I'll also follow your directions below once done.

Soldering instructions for the Teensy++ 2.0
Follow the instructions for the Teensy 3.x or 4.x above, but:

Do not connect pin 7, pin 15 and pin 16. These are marked with an x on the kinT.

An easy way to do this is to remove the corresponding pins from your pin header with pliers.
Close the solder jumpers JP1, JP2, JP3. These will remap pin 7, pin 15 and pin 16 onto pins that can be used with the Teensy++ 2.0.

Afterwards once this is confirmed.

Thank you!

I have gotten two questions regarding compatibility with the older kinesis advantage classic (KB333), which predates the KB500 and KB600 models.

The brief answer is that the kinT is currently not compatible with the older classic version.

The long answer is:

Electrically it is compatible, mechanically it is not compatible. The biggest difference are the connectors to the left and right key wells. Newer kinesis revisions use FFC connectors (FFC = flat form factor cables), but in the older revisions, the key well PCBs are directly connected into the controller (no cable).

Unfortunately I don’t know the part number for the required connector. In the humblehacker blog article, the author says they de-soldered the original connector from the original controller. (So if the keyboard is broken and you’re feeling adventurous, that might be an option.)

If you can figure out which part number one needs, you only need to replace it in the kinT controller design. The footprint should be identical or similar.

The only bit that’s worrying me is the physical position on the controller. With the FFC connectors you have a little wiggle room, but I think when connecting the PCBs directly, everything needs to fit much more precisely. Possibly you need to move the connector to the left or right in the kinT controller design, but that might require moving traces as well…

I hope this gives an impression of the kind and amount of work required to make it work

I purchased a v2020-06-30 kinT on ebay, and unfortunately it does not have the annotations specifying to see soldering instructions, or that the jumpers are for teensy++ compat. I have already soldered every pin of a teensy 2.0++.

I'm not confident in my ability to desolder the teensy in order to remove the pins and resolder. What will go wrong if I try to use it with these pins also soldered? Simply not working at all? Can I just cut the traces to these pins instead?

Thanks!

This is a cosmetic issue only, but we should fix it nevertheless, just to make the PCB check pass and not raise unnecessary doubts.

I just got a new KA2 w/ a kinT41 (w/ teensy 4.0). I have macOS and, for some reason, I cannot wake my laptop up from sleep using the kinT41. It worked fine with my old KA2 + stapleberg. This is my firmware: https://github.com/aaronjensen/qmk_firmware/tree/aaron/keyboards/kinesis/keymaps/aaronjensen which, aside from mapping, doesn't really have anything custom afaik.

Is this a common thing, or is there anything else that I should look at for this type of issue? Thanks!

The following features are either known to not work, or have not yet been successfully tested yet:

• EEPROM, for persistent settings
• Audio
• RGB LED lighting

I see the Teensy-LC has pin 24 and 25 which seem unused. Can these be routed to control two more leds?

i'm using

commit 0a9e18fae13654ab6d8d85a9867fc10a4261103f (HEAD, origin-primary/develop)
Merge: 924b9fcf0 eb7e668eb
Author: QMK Bot <[email protected]>
Date:   Sun Apr 18 22:40:16 2021 +0000

and heres what status prints:

Keyboard> kinesis/kint36
Keymap> kzar
Layout> DVORAK
Thumb keys mode> MAC
NKRO> Enabled
Debug> Disabled

some questions:

1. why cant i persist the mapping /layer state? 2) failing that, how do i patch the code from that commit to start with the mac layer being the intitial one?

thankx :)

I want to build a split keyboard which daisy-chains (eg. computer---kb_left---kb_right---mouse) and I would like to use mainline-qmk (python3 -m pip install --user qmk).

For that I would like to use 2 x Teensy 4.1. For each side one Teensy. Is it possible to use the internal usb-port of T4.1 with kint? That would be my main-concern. I guess the compilation / installation will be ok, but what are your thoughts about the usb-port of the T4.1? Is there any chance to daisy-chain?