zmkfirmware
Pixart PMW33XX driver implementation
Driver seems to function. 3389 srom must be included out of tree if you use it as we don't yet have permission to include it in zmk, however this driver should also work with the 3360 whose firmware we can include.
I used this repo for reference as it was an mit licensed 33xx implementation.
Maybe this helps you: Nordic implemented a PMW3360 driver in their nrf-connect SDK which is based on Zephyr. As far as I've used it, the PMW3389 is quite similar to the PMW3360 so maybe most of the work has already been done?
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/drivers/pmw3360.html https://github.com/nrfconnect/sdk-nrf/tree/main/drivers/sensor/pmw3360
Maybe this helps you: Nordic implemented a PMW3360 driver in their nrf-connect SDK which is based on Zephyr. As far as I've used it, the PMW3389 is quite similar to the PMW3360 so maybe most of the work has already been done?
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/drivers/pmw3360.html https://github.com/nrfconnect/sdk-nrf/tree/main/drivers/sensor/pmw3360
That license is not compatible with ZMK, anyone looking to contribute drivers to ZMK should avoid reviewing/referencing anything in NCS.
Maybe this helps you: Nordic implemented a PMW3360 driver in their nrf-connect SDK which is based on Zephyr. As far as I've used it, the PMW3389 is quite similar to the PMW3360 so maybe most of the work has already been done?
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/drivers/pmw3360.html https://github.com/nrfconnect/sdk-nrf/tree/main/drivers/sensor/pmw3360
That license is not compatible with ZMK, anyone looking to contribute drivers to ZMK should avoid reviewing/referencing anything in NCS.
Yeah exactly this. That's why I'm writing a clean room implementation. I'll probably make some progress on it this weekend. Been busy with other things.
Ah sorry, the old licensing pitfall... sad that chip vendors always use such licensing terms for such usefull stuff - when I used the pmw3389 it was really hard to find a satisfying implementation...
The driver is working in both polling and interrupt driven mode with a pmw3389, but i want to wait until my 3360 hardware comes in so i can test it with the one we actually have permissions to use the srom prior to resolving the WIP status. I guess we probably actually want to merge this into the mouse pr when we do merge it.
Tested with both the pmw3389 and the pmw3360. Thanks @Nicell for at least getting us permission for the 3360 srom.
Thanks @Nicell for at least getting us permission for the 3360 srom.
For reference, here is an unsigned version of the consent letter between PixArt and me (Nice Technologies/Nice Keyboards).
3360-SROM-Consent-Letter-Unsigned.docx.pdf
I have the signed copy on file. If a signed copy is required, please contact me directly.
Hello, I'm curious why this PR has been in limbo for nearly nine months?
Can someone review this PR. I'm really interested in this feature
There's a whole world of pointer work that's in limbo. I am not really interested in merging additional drivers that add more maintenance work (for things like Zephyr upgrades) until the core pointer infrastructure (HID, event structure, etc) is ready. That work I'll hopefully poke at here and there soon
Searching code over github gave me some examples by @UniqueDing one and @ALpotato another. Using @theninj4 rebased branch after some imports and names fixes, I've managed to get my pmw3360 successfuly initialized (product and firmware id passed and there is red light now), but there are a lot of questions about motswk-gpios and callbacks. Is motswk=Motion pmw3360 pin? If so callbacks never fired, even after my Motion pin goes low after motion :(
@meteozond I'm interested in this as well. Did you get it to work or was it just compiled without problems?
@sommerper huh - I've spent a lot of time getting it work: I've managed to fix and compile rebased @theninj4's version. Even sensor firmware was successfully flashed. That it is all, callback never fired :(
I've tried @ALpotato's fork - but it gets some fatal errors at startup + reboot loop with my gpio configuration :(
I've recently tried circuitpython + kmk + pmw3360 driver and it worked! Unfortunately it doesn't use motion callback so will drain you battery fast.
@sommerper huh - I've spent a lot of time getting it work: I've managed to fix and compile rebased @theninj4's version. Even sensor firmware was successfully flashed. That it is all, callback never fired :(
I've tried @ALpotato's fork - but it gets some fatal errors at startup + reboot loop with my gpio configuration :(
I've recently tried circuitpython + kmk + pmw3360 driver and it worked! Unfortunately it doesn't use motion callback so will drain you battery fast.
You probably want to switch to using bullwinkle3000's module.
Note that since ZMK is now based on Zephyr 3.5, you no longer need to follow the instructions to update the build.yml workflow.
@meteozond Thanks for letting me and other know! That saved me a lot of time knowing now that it doesn't work. Kinda sad though that I might have to switch to qmk now that I have refined my zmk setup over a few years!
@lesshonor The readme states Important to note that the PMW3360 is very power hungry compared to the PMW3610. If going fully wireless, you'll need big batteries and, even then, your battery life won't be great.
Wouldn't that be the same result that @meteozond achieved using KMK? As I understand it the module will never sleep but send data continuously?
Wouldn't that be the same result that meteozond achieved using KMK? As I understand it the module will never sleep but send data continuously?
...You'd need to ask someone who knows anything about this hardware.
FWIW, bullwinkle3000's driver implements interrupt pin(s), so my uneducated guess is that PMW3360 is just inherently more power-hungry than PMW3610.
Good news! I've just managed to run my pmw3360 with George Norton's driver despite some problems with smooth scrolling feature (it jumps to start/end only) - works like a charm.
PS: I've got bullwinkle3000's driver initialized and started getting some information from sensor - but pointer stacks in a left bottom conner :( I guess there are some interpretation problems.