-
-
Notifications
You must be signed in to change notification settings - Fork 150
feat: PMW3360 and PMW3389 input devices #689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Binary Size Reportuse_config/nrf52832_bleDiffuse_config/nrf52840_bleDiffuse_config/nrf52840_ble_splitDiffCentral DiffPeripheral Diffuse_rust/nrf52840_ble_splitDiffCentral DiffPeripheral Diffuse_config/pi_pico_w_bleDiffuse_config/pi_pico_w_ble_splitDiffCentral DiffPeripheral Diffuse_rust/pi_pico_w_ble_splitDiffCentral DiffPeripheral Diffuse_config/rp2040Diffuse_config/rp2040_splitDiffCentral DiffPeripheral Diffuse_rust/rp2040_splitDiffCentral DiffPeripheral Diffuse_config/stm32f1Diffuse_config/stm32f4Diffuse_config/stm32h7Diff |
|
This builds on NRF52xy, STM32 and RP2040 at least. I am lacking hardware right now to test out if the sensor really works on the NRF52 chips and STM32. |
|
@whitelynx Maybe you can test the PMW3389 support when your mouse is ready. I am lacking the hardware and that sensor is too expensive for me to buy it just to test that out. |
See also HaoboGu/rmk#689 Using BlockingAsync for the PMW33xx sensors requires the dependency
See also HaoboGu/rmk#689 Using BlockingAsync for the PMW33xx sensors requires the dependency
|
I think the PointingDevices should be able to set the resolution and rotational transform angle at runtime. For this I would implement Controller for the PointingDevice, and the new functions of PointingDevice would require an ID for the sensor. Then I would like to add to the keyboardevents(?) the event Keyboardevents::PointingSetResolution((u8, i16)). Is this the best way to do it? I'm not sure if this should be in keyboardevents or if pointing devices should get their own events enum. |
Yeah, the simplest way is to add a I think it still needs some design. The main issues of the current event system are
|
|
I solved the ID thing, at least for Pointing devices, and with your other PR we solve the thing with custom processors. |
|
It isn't a big problem, it's just not very elegant -- having unnecessary variants wastes some RAM I'm thinking about introducing some feature gates, but if we want users to add their own event, the current event enum should be revised maybe? |
See also HaoboGu/rmk#689 Using BlockingAsync for the PMW33xx sensors requires the dependency
Inplemented InputDevice for PMW3360 and PMW3389 optical mouse sensors. The driver is based on the existing PWM3610 driver in RMK and Zephyr's implementation.
Please note that this needs HaoboGu/rmk-template#18 in order for new projects from rmkit to work. (At least for RP2040 and STM32). Otherwise users need to do
cargo add embassy-embedded-hal. Users of RP2040 and STM32 also need to add embassy-embedded-hal to their keyboardsCargo.tomlto use the PMW33xx sensor.BREAKING: PointingDevice and PointingProcessor replace Pmw3610Device and Pmw3610Processor. For the Pmw3610 the calls of ::new() for these stay the same, only the name changes. If using Rust to configure the keyboard change the calls, if using Toml nothing needs to be done.
Example Usage
Todos
Verify working with nRF52840
Verify working with RP2040
Verify working with STM32
Documentation
Changelog
Testing
Test PMW3389 sensor
merge PR add embassy-embedded-hal to dependencies for stm32 / rp2040 rmk-template#18
In the future, refactoring is needed to share implementation with JoyStick/ PWM3610 sensor or to handle SPI/I2C configs or generic processing like input transformation for pointing devices.