updated notes for zmk to do
This commit is contained in:
KemoNine
parent
28aeffaa6c
commit
a98f7a0910
|
|
@ -1,3 +1,61 @@
|
|||
# Test notes
|
||||
|
||||
cd app
|
||||
west test tests/to-layer/normal
|
||||
|
||||
add to app/tests/[folder]
|
||||
|
||||
fill in behavior_keymap.dtsi with appropriate keymap for testing
|
||||
setup native_posix.keymap for the order of events you want to run (these will spit out events that become the test case)
|
||||
fill in keycode_events.snapshot with the proper values after running the native_posix.keymap with appropriate output for the events expected
|
||||
remove the "+" prefix from the lines in the snapshot (should read like kp_pressed: and kp_released: on each line)
|
||||
you need a new line at the end of the snapshot file
|
||||
|
||||
|
||||
# ItsyBitsy Bring Up
|
||||
|
||||
https://github.com/nuxiom/zmk/tree/60split
|
||||
|
||||
# Sleep / Blank
|
||||
|
||||
Also apply to underglow if Pete doesn't get there first
|
||||
|
||||
# Local github CI actions run
|
||||
|
||||
See https://github.com/nektos/act as a potential way to run local GH actions ahead of opening a PR
|
||||
|
||||
# Documentation ideas
|
||||
|
||||
Container tests
|
||||
- west update
|
||||
- git status
|
||||
- nano -w .git/config
|
||||
- cd docs
|
||||
- npm ci
|
||||
- npm run prettier:format
|
||||
- npm run prettier:check
|
||||
- npm run lint
|
||||
- npm run build
|
||||
- npm run start # Verify this works with http://localhost:3000
|
||||
- cd ../app
|
||||
- clang-format -i app/**/*.c
|
||||
- clang-format -i app/**/*.h
|
||||
- west build --board nice_nano -- -DSHIELD=tidbit -DZMK_CONFIG=/workspaces/zmk-config/keyboards/zmk-config/config
|
||||
- west build -d build/ -t rom_report
|
||||
- west build -d build/ -t ram_report
|
||||
- west build -t menuconfig
|
||||
|
||||
# Keycode for setting hsv of underglow
|
||||
|
||||
Prior to dynamic layers, implement a behavior that can set the hsv values for underglow
|
||||
|
||||
&rgb_ug sethsv (h,s,v) # this is the general behavior format
|
||||
|
||||
see bt behavior definitions for how to fake / fudge the optional 2nd parm
|
||||
|
||||
sethsv and sethsb defines so they are the same to end users
|
||||
https://discord.com/channels/719497620560543766/719565084208398406/786814476048400424
|
||||
|
||||
# Dyanmic Layer Actions
|
||||
|
||||
- look at hold tap implementation for inspiration (keymap file poprtion)
|
||||
|
|
@ -8,6 +66,16 @@
|
|||
- fire key press
|
||||
|
||||
|
||||
keymap {
|
||||
compatible = "zmk,keymap";
|
||||
|
||||
default_layer {
|
||||
activate-behaviors = <
|
||||
&rgb_ug sethsv (128, 255, 64) &kp NUM_LOCK
|
||||
>;
|
||||
};
|
||||
};
|
||||
|
||||
# Mouse Keys
|
||||
|
||||
- see keymap for codes
|
||||
|
|
@ -19,3 +87,150 @@
|
|||
- 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
|
||||
Loading…
Reference in a new issue