qmk_firmware VS TPMouse

It is in Keychron fork of QMK, not in QMK proper. And note that it is in the branch "bluetooth_playground".

It's essentially the same layout as the Q1 Pro, which is on Keychron's QMK Github repo, but considering this is the first one with 2.4GHz support I'm not sure if this is a good way to go. There's also the same layout on OnePlus 81 Pro, also on Github, but this seems like a replication of the original Q1 Pro firmware.

It may have to be created from the source code.

https://github.com/Keychron/qmk_firmware/blob/master/keyboar...

...you just need to map keys. It was very easy, so now fn-arrow and fn-return work as a mouse on anything I've attached it to so far. I got an rpi recently, only connected this, and was able to navigate the startup ui with no mouse.

Doing a little more digging, I found that these source files are in fact in Keychron's own fork of QMK, and is located in a separate branch : https://github.com/Keychron/qmk_firmware/tree/bluetooth_playground/keyboards/keychron

The source code is located at https://github.com/Keychron/qmk_firmware/tree/playground. The keychron specific bits are located in keyboards/keychron folder. Keychron supports QMK. But, it doesn't support you modifying the code. You have to figure it out yourself. There is a qmk documnetation site at https://docs.qmk.fm/#/ but it is likely to overwhelm you with information. This information is from the Keychron V1 web pages and using google seatch for qmk documentation.

Github repo for Bluetooth Keychron Keyboard : link. Note that Bluetooth keyboards are in the "bluetooth_playground" branch and not in the master. So, when you fork the qmk_firmware repo, make sure to select include all branches and not only the master. Then, when using the QMK MSYS CLI, make sure to switch to the bluetooth_playground branch.

git clone https://github.com/Keychron/qmk_firmware.git

https://docs.qmk.fm/#/feature_layers?id=switching-and-toggling-layers

And for Windows, my https://github.com/esporttoys/TPMouse was inspired by warpd itself but focuses more on the intuitive usability of direct cursor control via inertia/momentum.

You may be interested in how I did my Windows script for adding three-finger drag[0].

Basically, it is an independent subscriber to RawInput messages that only keeps track of whether or not to send three-finger drag, and posts emulated mouse messages using SendInput. I have a few other scripts that each run as independent userland processes that only monitors their own trigger and nothing else.

Tangentially, not sure if this might serve for some inspiration, but my TPMouse[1] script implemented inertia in a framerate-independent way so that it uses very little resource while having perfect simulation stability.

A previous discussion where I explained the analytic derivation for this low-resource exact-solution damped inertia can be seen in [10]

[0] https://github.com/EsportToys/PrecisionThreeFingerDrag/blob/...

[1] https://github.com/EsportToys/TPMouse

[10] https://old.reddit.com/r/Trackballs/comments/ym9q2t/tpmouse_...

With the TPMouse script I implemented the activation shortcut as LShift+RShift+ which I felt had a nice balance between deliberateness and easy-to-reach (since you are using it with your hands on homerow).

Though because some keyboards have key rollover issues with using both Shifts, Capslock+ is also allowed as an alternative activation shortcut.

[0] https://github.com/EsportToys/TPMouse

I personally use AutoIt a ton as a super fast way to quickly prototype GUIs. It's basically a really simple entrypoint for WinAPI.

Shameless plug: my script for emulating a trackball with your keyboard [0], and my tray app for quickly tweaking your cursor speed (usually for when I'm drawing something)[1]

  [0] https://github.com/EsportToys/TPMouse