feat(kscan): Add config to control int trigger

[petejohanson]

• Allow using either level or edge interrupts for matrix/direct kscan drivers.

This came up while working on the XIAO MG24 and found that the gecko GPIO driver (and the platform itself) does not support "level" interrupts, only edge interrupts, so this adds a set of Kconfig choices/configs to select which interrupt type to use for matrix/direct kscan drivers.

PR check-list

• Branch has a clean commit history
• Additional tests are included, if changing behaviors/core code that is testable.
• Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
• Pre-commit used to check formatting of files, commit messages, etc.

[Nick-Munnich]

Am I wrong, or is there no default being applied currently? I think we're probably happy for this flag to be set/overwritten designer-side so no need for a Kconfig.defaults, but I think we should have the default choice set in the Kconfig already.

I'm not entirely sure we need different Kconfig flags for the different Kscans. How would this interact if the XIAO MG24 or an alternative MCU that this applies to is using a GPIO expander? If there is a case for different flags for different Kscans, then the Charlieplex driver also needs one.

[petejohanson]

Am I wrong, or is there no default being applied currently? I think we're probably happy for this flag to be set/overwritten designer-side so no need for a Kconfig.defaults, but I think we should have the default choice set in the Kconfig already.

For choices, if no default is explicitly set, then the first choice is defaulted. This avoids needing to worry about ordering, and allows a default to be set elsewhere if needed

I'm not entirely sure we need different Kconfig flags for the different Kscans. How would this interact if the XIAO MG24 or an alternative MCU that this applies to is using a GPIO expander? If there is a case for different flags for different Kscans, then the Charlieplex driver also needs one.

I was on the fence on this. I am open to changing it, but I'm always wary of starting with something more limited/shared without seriously considering implications/edge cases.

[Nick-Munnich]

I was on the fence on this. I am open to changing it, but I'm always wary of starting with something more limited/shared without seriously considering implications/edge cases.

I think if you want to be certain that all edge cases are covered, then it should be a kscan property.

The case for having them be different flags is if you have a composite kscan and you want different interrupts for different child scans. I can't think of a scenario when you'd actually want that.