change CPI by keypress

[rain vine]

I want to add a feature to change the CPI when a key is pressed in the repository https://github.com/inorichi/zmk-pmw3610-driver. However, I’m a complete beginner and unsure of where to start. I understand that there is a function like set_cpi in the driver, and that I need to call it in response to a keypress, but I’m not sure which file to modify or how to define the keycodes. I would appreciate any hints on how to proceed.

[feral mural]

It's not really trivial, check the new behavior guide under development docs

Here is a relatively barebones example of adding a behavior to a module https://github.com/caksoylar/zmk-rgbled-widget/commit/e3ed07a367e2f90871b99c8b955df2e07b2d6284

But read through the guide

[rain vine]

thank you
I will read docs and examples

[rain vine]

I tried writing it based on examples like this,
https://github.com/kumamuk-git/zmk-pmw3610-driver/commit/50d510b987d13c88c91b1f9223693121d36831c9
but I'm not sure how to handle the YAML part. I already have a YAML file, but should I create a separate YAML for the behavior? Also, could you check if there are any unnatural points in what I've written?

[feral mural]

• Your compatible values in the dtsi need to match what's on the first line in the source. i.e. change it to zmk,behavior-pmw3610
• You need a new yaml file zmk,behavior-pmw3610.yml in a special location for the behavior, yes. It's separate from the driver
• Add the necessary Kconfig to set the symbol like in my commit
• Compile the .c conditionally in the CMakeLists.txt using above symbol

[solid shell]

Here is another example to call an implemented sensor_driver_api in a zephyr driver.

[rain vine]

Thank you for the accurate advice. However, when I press the keys assigned to &cpi_i200 or &cpi_d200, the system freezes. After pressing those keys, no logs are output in the USB log either. What could be the cause?
https://github.com/kumamuk-git/zmk-pmw3610-driver/blob/change_cpi/src/behaviors/begavior_pmw3610.c

[rain vine]

The fact that no logs are appearing—could it mean that the line

const struct device *dev = binding->behavior_dev;
is not working properly?

[rain vine]

@feral mural @solid shell
after some modification, it no longer freezes.
but cpi won't be changed by keypress.
According to the log, this line may be the cause.
If you come up with any ideas for modifications, I'd be glad to hear them?
https://github.com/kumamuk-git/zmk-pmw3610-driver/blob/8e667f4a620b4b03ce0da402d1d79979c7215f7d/src/behaviors/begavior_pmw3610.c#L35

[solid shell]

the dev you got in pressed callback is the behavior you just created, it is not referencing to the 3610 sensor device. you might find a property namedtb6612fng_dev in my above example, it is the pattern you could follow.

[rain vine]

thank you!
like this?https://github.com/kumamuk-git/zmk-pmw3610-driver/commit/f1c3b706975d595734237f426ac385bae75ec899

[rain vine]

https://github.com/kumamuk-git/zmk-config-test/blob/w/o_dongle/config/Test.keymap
ERROR: /behaviors/cpi_d200 POST_KERNEL 1 < /soc/spi@40003000/trackball@0 POST_KERNEL 33
ERROR: /behaviors/cpi_i200 POST_KERNEL 2 < /soc/spi@40003000/trackball@0 POST_KERNEL 33

I wrote in the keymap file to tie pixart_dev to trackball like this, but it fails due to build priority(?)

BEHAVIOR_DT_INST_DEFINE(n, behavior_cpi_init, NULL, NULL, &behavior_cpi_config_##n,            \
                        POST_KERNEL, 34,                      \
                        &behavior_cpi_driver_api);

Specifying 34 did not change the result.

[solid shell]

on zephyr prespective, there is 2 devices. you gonna need to sort out the initial sequence by yourself. see example.

[rain vine]

thank you!

The trackball is implemented on the right side, and “trackball” is defined in the right overlay file.
Naturally, the left overlay does not define “trackball”, so an error occurs and only the left one does not pass the build.
Is there a workaround?

[solid shell]

just put something else as the device. in case, you dont trigger the behavior on peripheral side.

[rain vine]

Meaning that the left overlay defines an empty device named "trackball"?

[solid shell]

no. put any device can do. you can makeup another dummy behavior of yours. it wil compile but definitly will crash if its triggerered (but it will never happening)

[rain vine]

I'm sorry. I didn't understand.
Are you saying that it doesn't have to be &trackball that is specified in the keymap? Wouldn't that make it impossible to get the sensor information?

If you have an example using the example driver and behavior(tb6612fng) with a split keyboard, please show me the keymap file.

[solid shell]

the keymap is the common config while compiling both shield roles. in youe case, there is no trackball on the peripheral , so it need a dummy device to pass the dts check. dummy device can be any node which zephyr thinks that is a device. you might get the idea from the readme of input-replay-module,

[rain vine]

/ {
trackball: dummy_trackball {
compatible = "zmk,virtual-input";
};
};

thank you
I added this,then compiling was successful.
but when press &cpi_i200, keyboard was freezed with no logs....

[solid shell]

you forget to swap in the sensor device pointer in your press callback