# User Behaviors Needs documentation, see pockettype and mdk dongle for ideas -- specifically the LED code and CMakeLists.txt # LEDs Generic behavior for led on/off via gpio (see pocket type / mdk personal sources for ideas) # Peripheral Over USB Figure out how to setup the code to allow the peripheral half of a board to work over USB Per Pete Johnson : Mostly build tweaks # 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 ## MDK Dongle Submit to upstream zephyr ## Dongles - Remove need to have kscan defined for the dongle portion of a build - Setup user buttons via user code to trip boot loader / other things - Can do `zmk-config/config/boards/shields/CMakeLists.txt` - Setup dedicated mdk dongle shield - Remove local tg4x / pockettype dongle configs - Part of readme shows the necessary conf tweaks/items that need to be added to zmk-config for a board ## 40% - Reconcile against main zmk repo and submit appropriate PRs - Figure out underglow ## 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 ## 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 # 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? 1. Implement a mouse report (I've already done some groundwork for that). 2. Determine appropriate behaviours and implement them. 3. Investigate into whether the current peripheral-to-central communication channels provide the necessary prerequisites, and if not, improve it. 4. 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