Split Keyboard FAQ / Notes

TRRS IS DANGEROUS IF BOTH HALVES HAVE BATTERIES
- TRRS will provide power to peripheral half and that can cause battery overheats, failures, fires
BOTH HALVES SHOULD BE POWERED INDEPENDENTLY
Halves communicate via ble
Both halves should be powered independently of each other
ONLY the central half should be paired to a computer via BT
Central half is the only half that has to be plugged into usb for usb hid support

Dyanmic Layer Actions

look at hold tap implementation for inspiration (keymap file poprtion)
hooks for BOTH activate and de-activate
change underglow color

fire key press

keymap { compatible = "zmk,keymap";

  default_layer {
  	activate-behaviors = <
          &rgb_ug sethsv (128, 255, 64) &kp NUM_LOCK
  	>;
  };

};

Hardware To Do / Notes

Tidbit

Setup to use oled same way as original
Setup to use nice!nano same way as original
Setup to use 14500 same way as original

Pocket Type

Nice!Nano + magnetic usb-c
110mAh LiPo under MCU
Add OLED somehow
Add neopixel on spare pins (if present)

Mini mouse pad / track pad

Adafruit itsybitsy nrf
- https://github.com/nuxiom/zmk/tree/60split
ItsyBitsy lipo backpack
- pins like nice!nano for quick swap of battery / removal of battery
110mAh battery
- soldered to short mill max socket for hot swap / removal from lipo backpack
Largest trackpad ordered
Blue led indicate charging status (same as nice!nano)
Dotstar red if unpaired
Dotstar yellow if disconnected
Dotstar green if connected
Dotstar blue if pairing
Push and hold button to clear BT profile
Tap button to connect to default BT profile

Generating settings reset images

west build --board nice_nano -d build/settings_reset -- -DSHIELD=settings_reset

VS Code Documentation

Command Pallet -> Run Task -> npm -> Shows list of npm build tasks for the docs
code @ the container command line will open a file directly within code on the main machine

Workspace documentation

finalize devcontainer-setupworkspace branch, may have existing PR open

Mouse Keys

see keymap for codes
constant movement / accellerated option
default accel mode (standard if unspecified)
default speed mode (standard if unspcified)
key code for changing accel mode (slow/standard/fast)
key code for changing speed mode (slow/standard/fast)
constant speed code that will momentarily activate constant speed motion
accell speed code that will momentarily activate accell speed motion
toggle to flip between constant and accell modes

3:51 AM ] fischkopp : @innovaker what would it take to add mouse keys? [ 5:36 AM ] innovaker : Hi @fischkopp, I don't believe we've spoken before?

Implement a mouse report (I've already done some groundwork for that).
Determine appropriate behaviours and implement them.
Investigate into whether the current peripheral-to-central communication channels provide the necessary prerequisites, and if not, improve it.
Probably need to implement a system that sits in-between the behavior and the reports which caters for inputs from multiple sources and amalgamates them. I've been told this is a vital aspect that can be easily overlooked. It's fairly easy to hack out a proof-of-concept for this, but trickier to engineer the system(s) we should be aiming for. Are you looking to get involved? [ 5:37 AM ] fischkopp : Yeah I'm interested in that [ 5:38 AM ] fischkopp : but i'm actually not sure I understand what makes mouse key implementation so complex [ 5:38 AM ] innovaker : Most of the steps require consideration of the big picture (because this is effectively a new type of input that we haven't built around yet, so we consider how it all fits together), but if you want to get a head start and make a prototype that would be really useful. [ 5:39 AM ] fischkopp : (not really usually doing much embedded work besides getting android to run on platforms) [ 5:39 AM ] innovaker : my understanding is that it's the multiple inputs to single output + acceleration which are the complicating factors [ 5:39 AM ] innovaker : there's only one pointer output - with axes X and Y [ 5:40 AM ] innovaker : but there could be numerous inputs to that, both sensors (controls) and keys which could need unifying [ 5:40 AM ] innovaker : and you're doing binary to linear conversion using a stateful system that requires "natural" acceleration to feel right [ 5:40 AM ] innovaker : so effectively a curve (perhaps even with a degree of hysteresis? I don't know) [ 5:40 AM ] innovaker : none of which is currently supported by ZMK [ 5:42 AM ] innovaker : if we had a working prototype to iterate on, it would make it easier to nail down those aspects and design/implement the necessary prerequisites into ZMK. [ 5:42 AM ] innovaker : I just haven't got onto it yet (there's other priorities at the moment). [ 5:42 AM ] innovaker : You're most welcome to get it kick started tho! [ 5:43 AM ] innovaker : and trail blaze it if you're capable [ 5:44 AM ] innovaker : I doubt the naive solution of "hold UP to make Y increase at a constant rate" would be practical from what others have told me, but that's probably the first objective/target to shoot for. It would give us a better vantage point for moving forward. [ 5:49 AM ] innovaker : any thoughts on that @fischkopp? [ 5:50 AM ] fischkopp : i don't know I personally like the constant rate more

[ 5:50 AM ] innovaker : as I say, that's the first goal post/marker, you're welcome to implement it [ 5:50 AM ] fischkopp : I'll just need to add support for my keyboard mcu first [ 5:50 AM ] innovaker : just keep in mind the big picture as you make design choices [ 5:52 AM ] innovaker : there are also others interested in this area, so if you break ground then I'll give them a shout so that they can be involved if they want to be

5.7 KiB Raw Blame History